OBJECT_API_METHOD_NOT_ALLOWED names an operation its own `allowed` array contains — the refusal reports the conjunct that PASSED

[hotlong]

Measured in passing while driving sys_user write doors for cloud#1989, on a real
walled boot of the cloud control plane at framework pin 5b2ad1b41.

What was measured

sys_user declares enable.apiMethods: ['get','list','update','bulk']
(packages/platform-objects/src/identity/sys-user.object.ts:907). Three requests,
each refused, each naming an operation that its own allowed array contains:

POST /api/v1/data/sys_user/deleteMany   -> 405
{"error":"API operation 'bulk' is not allowed on object 'sys_user'",
 "code":"OBJECT_API_METHOD_NOT_ALLOWED","object":"sys_user",
 "allowed":["get","list","update","bulk","aggregate","history","search","import","export"]}

POST /api/v1/data/sys_user/createMany   -> 405   (identical envelope)
POST /api/v1/batch                      -> 405   (identical envelope)

POST /api/v1/data/sys_user/import       -> 405
{"error":"API operation 'import' is not allowed on object 'sys_user'", ...
 "allowed":[... ,"import","export"]}

bulk is in the allowed set and the refusal says bulk is not allowed. Same for
import. Meanwhile POST /api/v1/data/sys_user/updateMany and
POST /api/v1/data/sys_user/batch — which also need bulk — are ADMITTED and
answer 200. So the refusal is correct in outcome (deleteMany needs bulk AND
delete; createMany needs bulk AND create; import needs a create face) but the
message names the wrong conjunct: it reports the conjunct that PASSED.

Why this is worth a card rather than a shrug

The allowed array is load-bearing as a DISCRIMINATOR, not decoration.
apps/cloud/test/unscoped-control-plane-tenant-wall.test.ts states the rule it
inherited from cloud#1225: a declaration re-widened to create/update can still
405 for an unrelated reason, so only the set proves WHICH gate answered. An
envelope whose set contradicts its own message cannot serve that purpose — a
future measurement reading it concludes the object still has the verb open when
the gate in fact closed a different conjunct, or the reverse.

Suggested shape

The refusal should name the conjunct that actually failed (delete / create),
or the allowed set should be the set the gate evaluated against. Either one
makes message and set agree; shipping both as they are makes the envelope
self-contradicting.

Filed with no assignee by the cloud#1989 measurement seat. Not repaired there:
that card is measurement-only and this is a framework-owned surface.

[os-zhuang]

分诊 · domain:cli / priority:p2 / pm:queue

Anchor read, not guessed — and the read turned up a second emit site the card does not name.

origin/main f1d7872, 2026-09-04T23:45:27Z — the message template `API operation '${operation}' is not allowed on object '${object}'` exists in exactly two places:

site	surface
packages/rest/src/rest-server.ts:366	the REST door the card measured
packages/mcp/src/stdio-data-bridge.ts:275	the MCP data bridge — not enumerated on the card

Both are in the domain:cli lane (rest, mcp), so the anchor is unambiguous and no cross-lane hand-off is needed. Confirmed alongside: sys-user.object.ts:907 still declares apiMethods: ['get','list','update','bulk'].

⛔ The MCP site is in scope for this card and must not be left behind. A fix that repairs only the REST envelope leaves an identically self-contradicting refusal on the MCP surface, and the next measurement seat files this card again from the other door. Whoever takes it should check whether stdio-data-bridge.ts:275 derives its allowed array the same way — if it does, one fix serves both; if it does not, say so in the PR rather than silently fixing one.

Grade — p2

The card is right that the refusal is correct in outcome — deleteMany needs bulk AND delete, createMany needs bulk AND create, and updateMany / batch (which need only bulk) are correctly admitted with 200. Nothing is wrongly allowed or wrongly denied. So this is not a permission defect and not p1.

What makes it p2 rather than p3 is that the allowed array is load-bearing as a discriminator, not decoration, and the card cites the pin that says so: apps/cloud/test/unscoped-control-plane-tenant-wall.test.ts, carrying the rule from cloud#1225 — a declaration re-widened to create/update can still 405 for an unrelated reason, so only the set proves WHICH gate answered.

An envelope whose message contradicts its own set cannot serve that purpose, and the failure is silent and directional: a future measurement reads allowed: [… "bulk" …] against a message saying bulk is not allowed and concludes either "the verb is still open" (missing a real closure) or "the gate closed bulk" (filing a false finding). This repo has already paid for exactly that class this week. A refusal message that names the conjunct that passed is worse than a vague one, because it is specific and wrong.

Boundary test — Bug, no manual floor

Both suggested shapes restore internal consistency; neither widens the accept set, and neither changes which requests are refused. ⚠️ But the wire body is a published contract, so the choice between them is not free-form:

1. Name the failing conjunct (delete / create) in the message — changes the error string only; the allowed set keeps meaning "what the object declares".
2. Make allowed the set the gate evaluated against — changes the semantics of a field clients read, which is the more invasive of the two despite looking like the smaller diff.

⇒ Prefer 1 unless there is a reason not to; if 2 is chosen, it needs the ruling that goes with changing a published field's meaning, and unscoped-control-plane-tenant-wall.test.ts has to be re-read first because it is the consumer that depends on today's meaning.

One thing to measure before writing either: the card shows three distinct requests (deleteMany, createMany, POST /api/v1/batch) producing an identical envelope naming bulk. Whether :366 can even see which conjunct failed, or whether the conjunct check happens upstream and only bulk reaches the formatter, decides whether option 1 is a one-line change or a plumbing change. ⛔ Do not assume it is one line.

⛔ Not a claim, not a dispatch — routing only.

---

Generated by Claude Code

[os-sales]

Claim: PM loop round R70
Session: session_01YFY46JydE1gMxQG1TqBcMZ
Branch: claude/issue-15416-method-not-allowed-names-failing-conjunct
Worktree: objectstack-issue-15416
Domain: domain:cli
File surface: packages/rest/src/rest-server.ts, packages/mcp/src/stdio-data-bridge.ts, plus their tests (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus (⛔ no path-derived mandate — dispatch-gates.mjs --tier derived at 1ecee3e5 from a detached worktree at origin/main, ⛔ not from the shared checkout)
Clause-②: no
Serial constraints cleared: none — see the measurement below

HARD SERIAL cleared — 28/28 MEASURED, ⛔ and the first pass was not a clearance

Both target files scanned against every open PR (28 rows):

pass 1  --depth=50   → 19 measured clean, 8 NO MERGE-BASE, 1 FETCH FAILED

⛔ That is NOT MEASURED, never "0 collisions" — this lane's rule, and the reason it exists is that a shallow clone's silence is indistinguishable from a true negative. Re-measured:

pass 2  --shallow-since=2026-08-25   → 5 of the 9 resolved, clean
pass 3  API file lists               → #16474 clean (1 file) · #16271 clean (2) · #16267 clean (1)
                                        #16416 state=closed merged=true ⇒ not an open holder

⇒ 28/28 measured, 0 collisions on rest-server.ts and stdio-data-bridge.ts. This is a reading, not a silence.

⭐ RULING — take option 1. The card offers two shapes; they are not equivalent.

The card says either shape "makes message and set agree". True, but they cost differently, and triage (5547738677) already named why:

Name the conjunct that actually failed (delete / create) in the error message. The allowed array keeps meaning "what the object declares".

⛔ Do NOT take option 2 (redefining allowed to be the set the gate evaluated against). It changes the semantics of a field clients already read — the smaller-looking diff is the more invasive one. The allowed array is load-bearing as a discriminator: apps/cloud/test/unscoped-control-plane-tenant-wall.test.ts carries the cloud#1225 rule that a declaration re-widened to create/update can still 405 for an unrelated reason, so only the set proves WHICH gate answered. Redefining it silently retargets that consumer.

⇒ Option 1 is a message repair; option 2 is a published-contract change requiring a maintainer ruling. This seat rules option 1 and ⛔ does not authorise option 2.

⚠️ The second emit site is IN SCOPE — triage found it, the card does not name it

The message template exists in exactly two places (origin/main f1d7872):

site	surface
packages/rest/src/rest-server.ts:366	the REST door the card measured
packages/mcp/src/stdio-data-bridge.ts:275	the MCP data bridge — ⛔ not on the card

⛔ A fix that repairs only REST leaves an identically self-contradicting refusal on MCP, and the next measurement seat files this card again from the other door. Both are in this lane, so there is no hand-off. Check whether the MCP site derives its allowed array the same way: if it does, one fix serves both; if it does not, say so in the PR rather than silently fixing one.

⚠️ Measure this BEFORE writing either shape — ⛔ do not assume it is one line

The card shows three distinct requests (deleteMany, createMany, POST /api/v1/batch) producing an identical envelope naming bulk. Whether :366 can even see which conjunct failed — or whether the conjunct check happens upstream and only bulk ever reaches the formatter — decides whether option 1 is a one-line change or a plumbing change. If it is plumbing, that is the finding; report it, do not force a one-liner.

⚠️⚠️ rest-server.ts is LINE-NUMBER ANCHORED — this is not theoretical

content/docs/permissions/system-context.mdx anchors that file by absolute line number, and it names it 4 times (measured at 1ecee3e5). This lane reddened check-system-context-census twice on this exact file, once from a diff that was nothing but comments:

A comments-only diff moves every line beneath it. "Comments only" and "cannot break a gate" are unrelated claims.

⇒ Any line added or removed above an anchor reds that gate. Repair with the gate's own --fix (it rewrites a pure shift and refuses a population change — a refusal means stop and think, ⛔ not edit harder), and verify structurally by comparing census populations with a re-validated non-zero control. ⛔ Never verify by comparing line content — several anchored lines in that file are the same string.

---

Generated by Claude Code

[claude]

os-dev-report

{
  "issue": 15416,
  "status": "done",
  "branch": "claude/issue-15416-method-not-allowed-names-failing-conjunct",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/16511",
  "premise_still_valid": true,
  "failing_conjunct_reachable_at_formatter": "YES — option 1 is LOCAL, not plumbing. `apiAccessDenialFromEnable` already receives the whole conjunction: the `enable` block, the canonical operation, and the `ApiAccessOpts` carrying `bulkChild` / `writeMode` that every bulk and import route passes through `enforceApiAccess`. Nothing upstream discards the child; the formatter simply never asked which half was false. The measurement also widened the defect by one shape: the envelope self-contradicts in exactly the cases where `isApiOperationAllowed` consults its options, and there are TWO — `bulk AND child`, and `import` refined by `writeMode` (an insert import needs `create` while `import` sits in the effective set via create OR update). With no options passed the verdict reduces to membership in the very set serialized as `allowed`, so the two halves cannot disagree.",
  "one_fix_served_both_emit_sites": "NO — and the MCP site needed no repair, which is the finding rather than a shortcut. Both surfaces derive `allowed` identically via `effectiveOperationsArray(resolveEffectiveApiMethods(enable))`; they differ on the CHECK side, which is the side that produces the contradiction. `enforceApiExposure` passes no `OperationCheckOptions`, and `GATED_ACTIONS` is six words (query/get/create/update/delete/aggregate) containing neither conjunction-bearing operation, so the class is structurally unreachable on stdio. A shared helper would need a home both packages import from, and the only such home is `packages/spec/src/**` — clause 2 territory and out of scope. Delivered instead: a `packages/mcp` pin that DERIVES from the spec that the set of operations whose verdict moves under `OperationCheckOptions` is exactly ['bulk','import'], and asserts the gated set contains neither. Stated in the PR body, not silently skipped.",
  "gates": "85/85 derived families GREEN, asserted against dispatch-gates.mjs's own Reconciliation line (85 = 74 by path + 7 by change KIND + 7 declared whole-tree, 3 reached both ways), derived AFTER the .mdx joined the change set and at the final head a6e0736c1. `--commands` emitted exactly 85. Artifact rosters block run separately (it is outside that union): 37 families, 36 GREEN, 1 NOT MEASURED. `check:type-check-debt` first returned exit 3 PREREQUISITE NOT MET (tsc OOM at the 4096 MB cap) — recorded as NOT MEASURED, re-run at 10240 MB and GREEN with a real measurement (5 ledger entries re-measured, 55 raw errors, none above recorded). `check-partof-closing-keyword` and `check-single-claim-paths` were NOT WIRED in the batch (no PR context); both re-run with the real PR body, a real commits file and PR 16511, both GREEN — the closing-keyword gate confirms both commit messages carry no card-relation trailer. NOT MEASURED: `check:react-declaration-parity`, which needs an objectui SDUI manifest this repo does not contain and a browser dump; this diff touches no React or SDUI surface. `check-system-context-census` reddened exactly as forewarned (+70 line shift over all 8 rest-server.ts anchors), repaired with the gate's own --fix (it rewrote a pure shift and did not refuse), verified STRUCTURALLY and never by line content: sites 105, packages 19, files 44, anchors 140, non-read 27, row references 19, unheld 2 — identical before and after against a re-validated non-zero control, with zero isSystem tokens added or removed by the diff.",
  "line_budget": "N/A — no `skills/**` path in the diff, so no published-skill line or token ratchet applies. `check:skills-token-ratchet` and its --self-test both ran in the rosters block and are green.",
  "deviations": [
    "check:type-check-debt required raising NODE_OPTIONS above the standing 4096 MB cap. Justification is a measured OOM, not a preference: the whole-ledger tsc re-measure died with FATAL ERROR heap out of memory at 4096 and the gate returned exit 3, which is NOT MEASURED. Re-run at 10240 MB on a 15 GB box; the gate pins tsc itself at 6144 MB internally.",
    "check:react-declaration-parity NOT MEASURED — prerequisite MANIFEST unset; it needs `pnpm objectui:build` plus a browser manifest dump. Declared to CI rather than faked. The diff touches no React or SDUI path.",
    "The MCP gated-set ablation leg was VOIDED on its first attempt and re-run. The injected text contained the deleted text as a substring, so the grep -c anchor counts were unreadable; the harness guard refused the observation and the trap restored the tree. Re-run with a single-line anchor, which reddened as required. Reported rather than quietly retried until something landed.",
    "Gates 59-85 exceeded the container's 10-minute foreground cap and were completed under an in-turn blocking wait, not by ending the round. No result was read before it finished.",
    "The first spelling of the MCP structural assertion was `verdict === membership`, which holds for every operation word when no options are passed — a phantom check no drift could break. Replaced with the derived version before commit, and the third ablation leg is what reddens it."
  ],
  "files_changed": [
    "packages/rest/src/rest-server.ts",
    "packages/rest/src/rest-method-not-allowed-conjunct.test.ts",
    "packages/mcp/src/stdio-data-bridge.exposure.test.ts",
    "content/docs/permissions/system-context.mdx",
    ".changeset/rest-method-not-allowed-names-failing-conjunct.md"
  ],
  "clause_2": "no — graded from the delivered diff. No `packages/spec/src/**` path is touched and the `allowed` array is unchanged in contents and in meaning (option 1 taken, option 2 not). A sweep over the whole declaration space asserts the array stays byte-identical to effectiveOperationsArray(resolveEffectiveApiMethods(...)). No needs:contract-review label applied.",
  "changeset": "@objectstack/rest patch — a `fix(` that changes no public surface, per the pr-automation.yml WHICH LEVEL section. The published error envelope's message text changes, so skip-changeset would be wrong; nothing is added to an index, so minor is not required. @objectstack/mcp is not named: its change is test-only.",
  "summary": "The 405 refusal now names a conjunct that is genuinely absent from the same envelope's `allowed` array — `delete` for deleteMany, `create` for createMany, `create`/`update` for a writeMode-refined import — and still names `bulk` when the bulk primitive is the half the object withholds. The failing conjunct is found by asking the spec's own isApiOperationAllowed over a widened whitelist, smallest combination first, rather than re-spelling API_METHOD_DERIVATION in the REST layer, so a future refinement is tracked with no second spelling to drift from it. No gate decision moved: updateMany and batch stay admitted, and status, code and object are unchanged. The MCP door was measured and needs no repair; it gets the pin that keeps that true. Assignee was already set by the dispatch and was not touched.",
  "tests": "Targeted, at final head a6e0736c1 with the dependency closure built first. `pnpm --filter @objectstack/rest exec vitest run --maxWorkers=2 src/rest-method-not-allowed-conjunct.test.ts src/rest-api-derivation-gates.test.ts` -> Test Files 2 passed, Tests 32 passed. `pnpm --filter @objectstack/mcp exec vitest run --maxWorkers=2 src/stdio-data-bridge.exposure.test.ts` -> Test Files 1 passed, Tests 27 passed. Every assertion reads the named operation back out of the wire message and grades it against the same envelope's allowed array, so 'some 405 happened' satisfies none of them; two sweeps cover the entire 64-member declaration space against 15 call shapes and guard against vacuous green by requiring more than 100 actual refusals. ABLATION, three legs, each mutating COMMITTED code, proving the mutation reached disk by git hash-object against the HEAD blob AND by grep -c on both the injected and the deleted text, then restoring with `git checkout HEAD -- path` proven by an empty `git diff HEAD` and a byte-identical blob hash; every leg carried a trap with absolute paths. Leg 1, REST formatter, put ${operation} back: 8 of 16 red, including the whole-space sweep ('expected bulk to be delete', 'expected import to be create'). Leg 2, MCP envelope, shipped the named op inside allowedOperations: 4 of 27 red. Leg 3, MCP gated set, added a bulk entry to GATED_ACTIONS: 4 of 28 red, naming the verb. Direction was RED in all three, the expected direction. No dist preflight was needed: the mutated subject is imported by relative path from inside its own package, so it resolves to source, and the red legs prove that resolution empirically rather than by assertion. Full packages closure built green (71/71 tasks) before the ratchet gates.",
  "mcp_calls": "0 — the whole run used repo-scoped REST (probed first, HTTP 200) plus git; no MCP GitHub tool was called.",
  "open_questions": [],
  "out_of_scope_findings": [
    "noted, not filed: the `error` string is the only wire field that changes; a client string-matching these bulk and import refusals sees the new name, while `code` and `allowed` stay stable.",
    "noted, not filed: when two conjuncts are missing at once (an upsert child on an object granting neither create nor update) the refusal names one of them. Either is truthful and neither is in `allowed`; enum order makes it deterministic. Naming both would be a message-shape change, not this card.",
    "noted, not filed: `check:react-declaration-parity` cannot run in an agent container at all without an objectui build and a browser. Not a defect in this diff, and not filed as a card since it is a known environment prerequisite the gate itself documents."
  ]
}

---

Generated by Claude Code