README.md opens with Status: M0 — scaffold and configuration domain on an M1/M2/M3-complete tree, and its setup section never says the position assignment binds by name

Two README.md corrections from the dogfood pass (#45), both about the first thing a stranger reads. Neither is a decision; both are factual drift. ⛔ Not a decision card.

1. The status line is three milestones stale

README.md opens with:

Status: M0 — scaffold and configuration domain

On origin/main @ a7b7db5, M1, M2 and M3 are all complete: 11 objects, the full permission model, intake and the approval ladder, signature and execution formalities, the whole post-signature reminder layer (11 flows), four datasets, three dashboards, and both locale bundles. Only M4 (cards 12 · 13 · 14) is outstanding.

A first-time reader is told this is a scaffold. They then find 820 seeded rows and three working dashboards. Either the sentence or their trust goes.

Fix: state what is actually complete, and name M4 as what remains. ⚠️ ⛔ Do not write a milestone table that will drift again the same way — one line naming the current milestone, or a pointer to DESIGN.md §11, ages better than a checklist nobody updates.

2. The setup section names the positions but never says the assignment binds by name

README.md:72 reads:

create accounts in Setup → Users and assign the seven positions

followed by a table keyed clm_legal_counsel, clm_finance_controller, clm_records_manager, … — i.e. by name.

For an operator clicking through Setup → Users, that is enough. For anyone automating the setup — a script, a CI fixture, an agent — it is not: the instruction says nothing about the wire shape, and sys_user_position.position is the one field on that row without an _id suffix while its neighbour user_id has one, and the analogous sys_user_permission_set.permission_set_id is genuinely id-typed.

The dogfood run reached for an id by analogy, got 201 with no diagnostic on all eight rows, and consequently reported — wrongly — that the platform's whole position mechanism was broken. The platform's silent acceptance is the upstream half (evidence added to objectstack-ai/objectstack#16712); this half is ours: the README could have said which spelling.

Fix: state that the assignment binds by the position's name, and show the one-line shape for anyone scripting it.

⚠️ Do not write that name-spelling is verified to work on 17.4.0 — ⛔ nobody has measured it yet. The decisive test (write {"user_id":"…","position":"clm_legal_counsel"}, re-run POST /api/v1/security/explain, check whether permissionSets gains the app's set) is going to a separate dispatch. Sequence this card after that measurement, or write only what the UI path supports and leave the scripted shape out until it is confirmed.

Why these are one card

Same file, same reader, same defect class — prose that was true once and stopped being true. Two edits, no code, no behaviour change.

⚠️ ⛔ Do not fold this into a PR that also touches DESIGN.md §01–§04: that is a governed surface and would drag a README typo onto the human-merge path. README.md is not governed.

Session: session_01R3n3GGzobdegM4HUzah1iR
Branch: claude/issue-46-readme-status-and-binding
Worktree: hotclm-issue-46 (dedicated, off origin/main @ d34b225)
Domain: repo:hotclm (single-lane repo — no domain:* axis)
File surface: README.md only (stop on breach; explain in the report)
Container & model: S, mode:subagent, model: default judgement tier — two prose edits, but both are statements a stranger will act on, and one of them is the repo's own history of stale claims, so ⛔ not the floor tier.
Clause-②: no — correcting a README's own statements changes no acceptance set and no published surface.
Thread-read: none (no comments on this card at claim time, 2026-09-10T07:3xZ)
Serial constraints cleared: #48 (src/dashboards/legal.dashboard.ts) is the only card in flight — disjoint. Zero open PRs.

✅ Both blockers this card was held on are now cleared

① The hot-file hold is released. This card was deliberately kept out of round 4 because #47 was permitted to touch README.md's operator table, and two branches editing that file is a conflict ordering avoids. #47 merged as d34b225 — and it did touch that table (+31/−19), adding the two clm_legal_counsel accounts its deal names. ⇒ Branch off d34b225, ⛔ not off the tree this card was written against; the operator table you will read is already newer than the card's description of it.

② The unmeasured fact is now measured, and the card's ⚠️ warning is spent. The card says ⛔ do not write that name-spelling is verified on 17.4.0 because nobody had measured it. #50's declared rider measured it (card closed, investigation complete):

A name-spelled sys_user_position row does resolve on 17.4.0. Writing {"user_id":"…","position":"clm_legal_counsel"} moved permissionSets from the three baseline entries to include clm_legal and clm_requester — the second because bind-position-sets.ts binds every position to that set as well — attributed by explain as permission_set / direct grant.
Negative control: the id-spelled row also returns 201 with no diagnostic, is stored verbatim, appears in positions as a raw id string as though it were a name, matches nothing, and does not gain clm_legal.

⇒ The scripted shape may now be documented, and it is name. That is the whole reason this card was sequenced last.

⚠️ One correction the card does not carry, from the same measurement: POST /api/v1/security/explain requires object and operation — a body of only userId answers 400 VALIDATION_FAILED. If the README shows anyone how to verify their own setup, that is the shape.

Generated by Claude Code

os-dev-report

{
  "issue": 46,
  "status": "done",
  "branch": "claude/issue-46-readme-status-and-binding",
  "pr": "https://github.com/objectstack-ai/hotclm/pull/56",
  "premise_still_valid": true,
  "summary": "Both passages the card names are still exactly as it describes them on d34b225 — the status line still read `Status: M0 — scaffold and configuration domain`, and the setup instruction is still on README.md:72 — so #55 (issue #47) moved the operator table without touching either. Edit 1 replaces the M0 line with one line naming the current state plus pointers to DESIGN.md §11 and backlog cards 12·13·14, deliberately not a milestone checklist. Edit 2 adds a `### Assigning a position from a script` subsection after the dev-admin paragraph: the assignment binds by the position's NAME, the POST shape, the set a name-spelled row actually grants, the explain call that reads it back (object + operation required), and the silent id acceptance described as open upstream (objectstack#16712). README.md is the only file in the diff (+38/−2); #55's tables are untouched. No changeset (per dispatch), no label, no browser run.",
  "tests": "Four gates, each redirected to a file with $? read immediately after — no pipe between command and exit code. `EXITS validate=0 lint=0 typecheck=0 i18n=0`. Run under the shared verify lock (OS_VERIFY_LOCK_SLOT=hotclm-issue-46, ACQUIRED after 0s, held 22s). Tails: pnpm lint → `21 warning(s), 5 suggestion(s) (1249ms)`; pnpm typecheck → silent tsc --noEmit; pnpm lint:i18n-gate → `✓ i18n gate · 0 missing keys across 2 locale(s)` over 1541 expected keys; pnpm validate → 0 with the tree's pre-existing carrier-only-field warnings. None of the four moved, and none could: tsconfig `include` is only objectstack.config.ts + src/**/*, validate/lint walk the stack metadata graph, and scripts/check-lint-i18n-gate.mjs never reads README.md (its one `README` hit is a comment about DESIGN.md). No ablation and no reverse verification: a prose-only diff has no gate to make fail. No browser: the diff changes no runnable surface — no object, view, page, app, flow or action — so there is nothing to drive, and the PR says so explicitly.",
  "mcp_calls": "3 — create_pull_request, pull_request_read (PR body read-back), add_issue_comment (this report). The card, its claim comment and its labels were read from the public web page's embedded JSON payload, not over MCP.",
  "readings_behind_each_claim": {
    "edit_1_M1_M3_are_in": [
      "the model: `ls src/objects/*.object.ts` = 11",
      "permission layer: src/profiles/ = 5 sets (clm_admin, clm_finance, clm_legal, clm_records, clm_requester); src/sharing/positions.ts = 7 definePosition entries; contract.sharing.ts + FLS present",
      "intake / approval ladder / signing and formalities: src/flows/ carries F1 (contract-intake), F5 (contract-approval), F7 (signature-record); src/flows/index.ts registers 12 flows in allFlows, consumed at objectstack.config.ts:191",
      "post-signature reminder layer: legal-review-sla (F3), turn-stalled (F4), obligation-due (F10), payment-overdue (F11), renewal-notice (F12), expiration-sweep (F13) plus _daily-sweep.ts",
      "analytics: src/datasets/ = 4 (contract, cycle-time, obligation, payment); src/dashboards/ = 3 (executive, finance, legal)",
      "both locale bundles: src/translations/en + zh-CN; the i18n gate reports 0 missing keys across 2 locales"
    ],
    "edit_1_M4_is_what_remains": [
      "src/flows/index.ts header comment: 'F8 (e-signature) and F15 (CRM hand-off) arrive with cards 12 and 13' — neither flow file exists",
      "src/skills/ does not exist (S1–S6, card 13)",
      "content/ does not exist (docs site, card 14); src/mappings/ does not exist",
      "docs/backlog/README.md milestone column: 12, 13, 14 are the only M4 rows"
    ],
    "edit_2_binds_by_name": [
      "@objectstack/plugin-security@17.4.0 dist/index.mjs, sys_user_position: `position: Field.text({ label: 'Position', required: true, maxLength: 100, description: 'Position machine name (references sys_position.name).' })` — plain text, no lookup",
      "same object description: 'Assigns a position (sys_position.name) to a user. Platform-owned (ADR-0057 D4, ADR-0090 D3).'",
      "same object: `user_id: Field.lookup('sys_user', …)` — the neighbour with the _id suffix is a genuine lookup",
      "same dist, sys_user_permission_set: `permission_set_id: Field.lookup('sys_permission_set', …)` — the analogy the card warns about is genuinely id-typed"
    ],
    "edit_2_wire_shape": [
      "@objectstack/client@17.4.0 dist/index.mjs: `create: async (object, data) => fetch(baseUrl + getRoute('data') + '/' + object, { method: 'POST', body: JSON.stringify(data) })`",
      "same dist route defaults: `data: '/api/v1/data'` — hence POST /api/v1/data/sys_user_position",
      "sys_user_position declares `managedBy: 'system-data'` with the note 'the bucket default is full CRUD' — the row is writable over the data API"
    ],
    "edit_2_what_a_name_spelled_row_grants": [
      "src/security/bind-position-sets.ts BINDINGS: each position paired with its own set, then `...Object.values(CLM_POSITION).map((position) => [position, RequesterSet.name])` — every position also binds clm_requester",
      "src/profiles/legal.profile.ts:50 `name: 'clm_legal'`; src/profiles/requester.profile.ts:60 `name: 'clm_requester'`"
    ],
    "edit_2_explain_requires_object_and_operation": [
      "@objectstack/spec@17.4.0 dist/tenancy-posture-Dy-pbL79.d.ts:244 ExplainRequestSchema — `object: z.ZodString`, `operation: z.ZodEnum{create,read,update,delete,restore,purge,export,transfer}` both non-optional; `recordId`, `recordIds`, `userId` all z.ZodOptional. A body of only userId therefore fails validation."
    ],
    "edit_2_silent_id_acceptance": [
      "STATIC HALF, mine on this tree: `position` is a text column with maxLength 100 and no reference resolution, so an id-shaped string cannot be refused on write; bind-position-sets.ts looks positions up by name (`where: { name }` on sys_position), so a stored id matches no position row and joins to no permission set.",
      "RUNTIME HALF, NOT measured by me: the 201-with-no-diagnostic and the absent clm_legal come from #50's rider, handed down with this dispatch as established fact. I did not boot the app — see deviations. The README sentence is phrased so the static half carries it and the measured half only sharpens it.",
      "still open upstream: written as tracked-and-open (objectstack-ai/objectstack#16712), never as fixed."
    ]
  },
  "deviations": [
    "The one runtime claim (id spelling answers 201 with no diagnostic and grants nothing) rests on #50's measurement, not on a boot of my own. The dispatch said no browser is needed and the static reading of the field type independently supports the sentence, so I did not stand up the app for a prose-only PR. If the PM wants that half first-hand, it is a separate short run.",
    "Edit 2 is placed after the dev-admin/reviewer paragraphs rather than immediately after the position table, so the operator narrative #55 just rewrote stays contiguous and untouched. The new text refers to 'the state the dev admin is in above', which only reads correctly in that position."
  ],
  "files_changed": ["README.md"],
  "open_questions": [],
  "out_of_scope_findings": [
    "noted, not filed: the dispatch and the card both say '11 flows'; allFlows in src/flows/index.ts registers 12 (SignatureRecordOnCreateFlow and RenewalStartFlow are the two extra exports behind ten flow files). Nothing in README.md states a flow count, so the new status line names the reminder layer without a number and the discrepancy costs the reader nothing. Successor: none in the tree — this is a correction to the dispatch's own list, which is why it is in the report rather than in a card.",
    "noted, not filed: README.md says 'assign the seven positions' over a table of seven rows, but one row is '(business requesters)' — the default clm_requester permission set, not a position — while the seventh real position, clm_admin (src/sharing/positions.ts), is absent from the table. DESIGN.md §11 disagrees with itself on the same count: its layout block says '7 position' and its M1 row says '8 position / 6 set'. Not filed: a missing member is not a copy-this-and-it-fails defect, the passage is #55's table which this card is told not to reorganise, and the DESIGN.md half is off this card's file surface. Successor: none queued — no open card names either passage, so this needs the PM to decide whether it earns one."
  ]
}

Generated by Claude Code

REWORK — PR #56, one clause in Edit 2

CI is green on 6a86e41 (two Validate runs, both success), the diff is README.md only (+38/−2), no governed surface, and every other claim in the PR body holds up. I re-ran the one reading the whole subsection turns on, against the exact version this tree depends on — the published @objectstack/plugin-security@17.4.0 tarball, dist/index.js, SysUserPosition — and one clause is false.

The clause

sys_user_position.position is a plain text column carrying a sys_position.name — the one field on that row without an _id suffix, while its neighbour user_id is a real lookup

The reading

sys_user_position at 17.4.0, every field with its declared builder:

field	builder
`id`	`Field.text`
`user_id`	`Field.lookup("sys_user")`
`position`	`Field.text({ maxLength: 100 })`
`business_unit_id`	`Field.lookup("sys_business_unit")`
`organization_id`	`Field.lookup("sys_organization")`
`granted_by`	`Field.lookup("sys_user")`
`valid_from`	`Field.datetime`
`valid_until`	`Field.datetime`
`reason`	`Field.text`
`delegated_from`	`Field.lookup("sys_user")`
`last_certified_at`	`Field.datetime`
`certified_by`	`Field.lookup("sys_user")`
`created_at`	`Field.datetime`
`updated_at`	`Field.datetime`

It is false twice:

position is not "the one field without an _id suffix." Eleven of the fourteen fields carry no _id suffix.
The tell the sentence teaches is falsified on this very object. granted_by, delegated_from and certified_by are all Field.lookup("sys_user") with no _id suffix. "No _id ⇒ plain text ⇒ spell the name" is not a rule that holds here, and an operator who generalises it from this paragraph onto granted_by will spell a name into a genuine lookup and get the mirror-image of the bug this subsection exists to prevent.

That is the card's own failure mode. #46 was opened because the README carried prose that read authoritative and had stopped being true; shipping a new sentence that reads authoritative and never was true would trade one for the other. The rest of Edit 2 is right and stays.

What the fix is

Drop the naming heuristic, keep the reason that actually holds. The load-bearing evidence is the field's own declaration, which the PR already quotes:

position: Field.text({ maxLength: 100, description: "Position machine name (references sys_position.name)." }) — a text column, and its own description names what it carries.
user_id: Field.lookup("sys_user") right beside it, so the object genuinely mixes both kinds — that contrast is worth keeping, just not as a spelling rule.
The sys_user_permission_set.permission_set_id analogy stays: that one is Field.lookup("sys_permission_set"), and the point is that the sibling API you'd reach for by analogy takes an id while this one does not.

One clause, no restructuring, no new sections. Everything else in the PR is accepted as written — including the deliberate decision to put Edit 2 after the dev-admin paragraphs, and the explicit flag that the runtime half of the id-acceptance claim is inherited from #50 rather than measured here.

Not charged to you, and not yours to fix here

Both out_of_scope_findings are correct calls, and one of them I am acting on separately:

The "11 flows" figure was my error in the dispatch; allFlows registers 12. Naming the reminder layer without a number was the right handling.
The "assign the seven positions" / (business requesters) / missing clm_admin discrepancy, plus DESIGN.md §11 disagreeing with itself, is real — I confirmed src/sharing/positions.ts defines seven positions with clm_admin among them. It gets its own card. Do not touch it here.

Generated by Claude Code

os-dev-report

{
  "issue": 46,
  "status": "done",
  "branch": "claude/issue-46-readme-status-and-binding",
  "pr": "https://github.com/objectstack-ai/hotclm/pull/56",
  "premise_still_valid": true,
  "summary": "REWORK addressed in 0a9c340, one paragraph, nothing else touched. The false clause — `position` being \"the one field on that row without an `_id` suffix\" — is gone. I re-derived the adjudication myself before editing: enumerating the `fields` block of `sys_user_position` in @objectstack/plugin-security@17.4.0 gives fourteen fields, of which only three (`user_id`, `business_unit_id`, `organization_id`) carry an `_id` suffix, and `granted_by`, `delegated_from` and `certified_by` are each `Field.lookup(\"sys_user\")` with no suffix — so the tell I wrote was falsified three times on its own object. The paragraph is rebuilt on the field's own declaration (`text`, description \"Position machine name (references sys_position.name)\") and now states explicitly that the field name tells you nothing here because the object mixes both kinds; the `sys_user_permission_set.permission_set_id` contrast is kept verbatim as the reason the wrong guess is tempting. Edit 1, the wire shape, the explain note, the id-acceptance warning, the placement after the dev-admin paragraph and #55's tables are all unchanged. PR body carries a `## Rework` section owning the error, and a new reading row with all fourteen fields enumerated.",
  "tests": "Same method as the first run — each gate redirected to a file, `$?` read immediately after, no pipe between command and exit code. On 0a9c340 under the shared verify lock (OS_VERIFY_LOCK_SLOT=hotclm-issue-46, ACQUIRED after 0s, held 20s): `EXITS validate=0 lint=0 typecheck=0 i18n=0`. Verdict lines identical to the 6a86e41 run — pnpm lint `21 warning(s), 5 suggestion(s)` (979ms vs 1249ms, shared box), pnpm typecheck silent, pnpm lint:i18n-gate `✓ i18n gate · 0 missing keys across 2 locale(s)` over the same 1541 expected keys, pnpm validate 0 with the same pre-existing carrier-only-field warnings. That identity across two prose commits is the measurement behind the claim that a README-only diff cannot move them; the input-surface argument still stands beside it (tsconfig `include` is objectstack.config.ts + src/**/*, validate/lint walk the metadata graph, scripts/check-lint-i18n-gate.mjs never reads README.md). No browser: still no runnable surface in the diff.",
  "mcp_calls": "6 cumulative for the whole card — first pass: create_pull_request, pull_request_read, add_issue_comment. Rework: update_pull_request, pull_request_read (body read-back), add_issue_comment (this report). The card, the claim and the adjudication comment were all read from the public page's embedded JSON payload, not over MCP.",
  "rework_verification": {
    "adjudication_reproduced_first_hand": "Yes — before editing I walked the brace-balanced `fields: {` block of sys_user_position out of node_modules/.pnpm/@objectstack+plugin-security@17.4.0/.../dist/index.mjs and printed every field with its builder. Result matches the coordinator's table field for field: id text · user_id lookup(sys_user) · position text · business_unit_id lookup(sys_business_unit) · organization_id lookup(sys_organization) · granted_by lookup(sys_user) · valid_from datetime · valid_until datetime · reason text · delegated_from lookup(sys_user) · last_certified_at datetime · certified_by lookup(sys_user) · created_at datetime · updated_at datetime.",
    "counts_now_in_the_readme": "fourteen fields total, three with an `_id` suffix, eleven without — both numbers read off that enumeration, not off the dispatch or the adjudication.",
    "how_the_error_happened": "I verified `position`, `user_id` and `sys_user_permission_set.permission_set_id` individually and each of those readings was correct, then carried the dispatch's and the card's \"the one field without an `_id` suffix\" framing into the README without enumerating the remaining eleven fields. Zone 1 said every factual statement needs a reading behind it; that clause had a reading behind three of its words and an inherited framing behind the rest. The unit of verification has to be the sentence, not the identifier."
  },
  "deviations": [
    "Two beyond-the-clause touches, both to keep the record honest rather than to change the diff: the PR body gained a `## Rework` section owning the error and a reading row enumerating all fourteen fields, and its gate block now cites the 0a9c340 re-run. README.md itself changed in exactly the one paragraph the adjudication named (git diff vs the previous head: 8 insertions, 4 deletions, all inside it).",
    "Carried forward from the first pass and still true: the runtime half of the id-acceptance claim (201, no diagnostic, no clm_legal) is #50's measurement, not a boot of my own."
  ],
  "files_changed": ["README.md"],
  "open_questions": [],
  "out_of_scope_findings": [
    "filed by the PM, not by me: the 'assign the seven positions' / '(business requesters)' / missing clm_admin discrepancy, plus DESIGN.md §11 disagreeing with itself on the count. Confirmed by the coordinator and getting its own card; untouched here.",
    "noted, not filed: the dispatch's '11 flows' figure — allFlows registers 12. The coordinator has accepted this as its own error, and naming the reminder layer without a number as the right handling. Nothing left to do."
  ]
}

Generated by Claude Code

ACCEPT — PR #56 after the rework

CI green on head 0a9c340 (two Validate runs, both success), mergeable_state: clean, README.md is still the only file (+42/−2), no governed surface. First REWORK round, so the seat may merge under AGENTS.md. Squash-merging.

The clause is fixed, and fixed on the right evidence

The new paragraph reads:

Read that off the declaration, not off the field name — sys_user_position.position is declared text, and its own description says what it carries: "Position machine name (references sys_position.name)." The field name tells you nothing here, because this object mixes both kinds freely: user_id, granted_by, delegated_from and certified_by are all genuine lookups, and only three of its fourteen fields carry an _id suffix at all.

Checked against my own enumeration: fourteen fields, three with an _id suffix (user_id, business_unit_id, organization_id), and granted_by / delegated_from / certified_by each Field.lookup("sys_user") with no suffix. Every number and every field name in that sentence is right.

More to the point, it now teaches the opposite of what it taught before — read the declaration, the name tells you nothing — which is the durable lesson, and it keeps the permission_set_id contrast as the reason the wrong guess is tempting rather than as a rule. That is a better paragraph than the one I asked for.

On how the error happened

Your own account of it is the part worth keeping:

I had verified position, user_id and permission_set_id individually and each of those readings was correct, then carried the dispatch's and the card's framing into the README without enumerating the remaining eleven fields. … The unit of verification has to be the sentence, not the identifier.

That is exactly right, and it is worth noting that the false framing came from the card and the dispatch — mine. You inherited it from me and it survived three correct spot-readings. A clause can be assembled out of true readings and still be false; per-identifier verification does not compose into per-sentence verification. Recorded for the seat, not charged to you.

Everything else, accepted as written

Both re-runs of the four gates verdict-identical across two prose commits — that identity is a better argument for "a prose diff cannot move them" than the input-surface reasoning alone, and you kept both. The no-browser justification is correct and scoped. The one claim you did not measure first-hand (the runtime half of the id acceptance, inherited from #50) stayed flagged as inherited through both pushes.

Follow-ups now routed, neither yours

The position-census discrepancy you found is filed as docs: the position census disagrees with itself in three places — README says seven over a table of six, DESIGN.md §11 says both 7 and 8 #58, queued behind PR Record four maintainer rulings in DESIGN.md §03, §06 and §09 #40 so two branches never touch DESIGN.md at once.
The "11 flows" figure was my error; nothing left to do.

Generated by Claude Code

docs(readme): state the real milestone, and that positions bind by na…

Navigation Menu

Repository navigation

`README.md` opens with `Status: M0 — scaffold and configuration domain` on an M1/M2/M3-complete tree, and its setup section never says the position assignment binds by name #46

1. The status line is three milestones stale

2. The setup section names the positions but never says the assignment binds by name

Why these are one card

Related

✅ Both blockers this card was held on are now cleared

REWORK — PR #56, one clause in Edit 2

The clause

The reading

What the fix is

Not charged to you, and not yours to fix here

ACCEPT — PR #56 after the rework

The clause is fixed, and fixed on the right evidence

On how the error happened

Everything else, accepted as written

Follow-ups now routed, neither yours

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

README.md opens with Status: M0 — scaffold and configuration domain on an M1/M2/M3-complete tree, and its setup section never says the position assignment binds by name #46

Description

1. The status line is three milestones stale

2. The setup section names the positions but never says the assignment binds by name

Why these are one card

Related

Activity

zhuangjianguo commented on Sep 10, 2026

✅ Both blockers this card was held on are now cleared

zhuangjianguo commented on Sep 10, 2026

zhuangjianguo commented on Sep 10, 2026

REWORK — PR #56, one clause in Edit 2

The clause

The reading

What the fix is

Not charged to you, and not yours to fix here

zhuangjianguo commented on Sep 10, 2026

zhuangjianguo commented on Sep 10, 2026

ACCEPT — PR #56 after the rework

The clause is fixed, and fixed on the right evidence

On how the error happened

Everything else, accepted as written

Follow-ups now routed, neither yours

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`README.md` opens with `Status: M0 — scaffold and configuration domain` on an M1/M2/M3-complete tree, and its setup section never says the position assignment binds by name #46