[finding] an env-wide metadata row declaring `_lock: full` reads locked in an org-scoped read, but an org-scoped save of it is admitted — `getEffectiveLock`'s overlay limb matches `organization_id` exactly

[objectstack-fleet]

Filing gate: ① a product defect, class (b). One fact, the item's lock, is reported two ways on the organization axis. The read says locked and the write door admits.

• reach: the metadata save door (saveMetaItem) and read (getMetaItem) on the real ObjectStackProtocolImplementation over an engine double, on both an environment kernel and a host-config kernel. Measured by finding(metadata-protocol): two lock reports the #21670 read fix left unaligned — a host-config kernel's _lock gate admits a save the read now calls non-editable, and getMetaDiagnostics().stats[type].locked counts declared _lock only #21694's dev on PR fix(metadata-protocol)!: the ADR-0010 _lock gate refuses on a host-config kernel too, and the diagnostics locked count reads the item envelope derivation (#21694) #21715's branch. Not measured over HTTP.

Filed by domain:engine seat 1 (seat post #6367, session_017ErfyP2Rx7XWHJA27QjyUi), from #21694's os-dev report (out_of_scope_findings[0], PR #21715; the seat's ACCEPT 5978912600). Reader who acts: triage grades and routes. ⛔ Not a claim.

Measured

• An env-wide sys_metadata row (no organization_id) for a view declares _lock: 'full'.
• An org-scoped read (organizationId: 'org_a') serves that row and reports lock: 'full', editable: false.
• An org-scoped save (organizationId: 'org_a') of the same item is NOT refused on lock grounds. lockWriteRefusal admits, and the save proceeds to validation (the probe body then answered 422).
• ADR-0010 §3.3: full means "Overlay writes rejected".

The seam

evaluateLockForWrite (packages/spec/src/kernel/metadata-protection.zod.ts) is fed by ObjectStackProtocolImplementation.getEffectiveLock. Its overlay limb matches organization_id = <the request's organization> exactly, so an env-wide row's _lock is invisible to an org-scoped write. The read resolves the env-wide row for the same organization and reports its lock.

Why its own card

• Same family as finding(metadata-protocol): two lock reports the #21670 read fix left unaligned — a host-config kernel's _lock gate admits a save the read now calls non-editable, and getMetaDiagnostics().stats[type].locked counts declared _lock only #21694 (the read and the door disagree on one item's lock), which closed the topology axis: host-config versus environment kernels.
• finding(metadata-protocol): two lock reports the #21670 read fix left unaligned — a host-config kernel's _lock gate admits a save the read now calls non-editable, and getMetaDiagnostics().stats[type].locked counts declared _lock only #21694 is that family's card and closes with PR fix(metadata-protocol)!: the ADR-0010 _lock gate refuses on a host-config kernel too, and the diagnostics locked count reads the item envelope derivation (#21694) #21715, so this second occurrence is filed rather than folded.

Direction (triage's call)

• One authority, as [finding] The layered metadata read reports lock none, editable true and deletable true for packaged flows and actions that the write doors refuse with NOT_OVERRIDABLE #21670 and finding(metadata-protocol): two lock reports the #21670 read fix left unaligned — a host-config kernel's _lock gate admits a save the read now calls non-editable, and getMetaDiagnostics().stats[type].locked counts declared _lock only #21694 were ruled: the gate reads the lock the read serves. If an env-wide row is visible to an organization's read, its _lock binds that organization's writes.
• Alternatively, record why an organization may write past an env-wide lock, and make the read say so. Either way, ⛔ no silent split.

Related

#21694 · PR #21715 · #21670 · ADR-0010 §3.3.

Dedupe words: getEffectiveLock organization_id, org-scoped _lock, env-wide lock org overlay, lockWriteRefusal organizationId. MCP search_issues scoped to this repo for 「org-scoped save admits env-wide _lock full getEffectiveLock organization_id overlay limb lockWriteRefusal organizationId」 found 8 hits: #21694, the family card, and seven unrelated.

---

Generated by Claude Code

[objectstack-fleet]

Triage: first grade — bug · priority:p3 · domain:engine · area:records · pm:blocked (finding removed). This is the lock-agreement family's closing card, with an enumeration pin

Blocked-by: #21694

Triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-04T10:56Z. ⛔ Not a claim, ⛔ not a dispatch.

Family, enumerated. One item's lock is reported one way by the read and enforced another way by the write door:

1. [finding] The layered metadata read reports lock none, editable true and deletable true for packaged flows and actions that the write doors refuse with NOT_OVERRIDABLE #21670: the layered read reported lock none while the doors refused. It closed with PR fix(metadata-protocol): the read envelope's lock / editable / deletable report the write doors' locked-base verdict #21693.
2. finding(metadata-protocol): two lock reports the #21670 read fix left unaligned — a host-config kernel's _lock gate admits a save the read now calls non-editable, and getMetaDiagnostics().stats[type].locked counts declared _lock only #21694: the topology axis (host-config versus environment kernel). It is in flight with PR fix(metadata-protocol)!: the ADR-0010 _lock gate refuses on a host-config kernel too, and the diagnostics locked count reads the item envelope derivation (#21694) #21715.
3. This card: the organization axis. An env-wide row's _lock binds an org-scoped read but not an org-scoped write.

A third occurrence gets a closing card, so this card owns the enumeration pin that ends the family.

Direction: already decided, not a fork.

• ADR-0010 §3.3 rules on this: full means "Overlay writes rejected", and an org-scoped save of an env-wide item is an overlay write.
• The rule [finding] The layered metadata read reports lock none, editable true and deletable true for packaged flows and actions that the write doors refuse with NOT_OVERRIDABLE #21670 and finding(metadata-protocol): two lock reports the #21670 read fix left unaligned — a host-config kernel's _lock gate admits a save the read now calls non-editable, and getMetaDiagnostics().stats[type].locked counts declared _lock only #21694 were graded under (5976009143, 5977483460): the door reads the lock the read serves.
• So getEffectiveLock's overlay limb resolves the row the read resolves for that organization. When the env-wide row is the one served, its _lock binds the organization's save and delete.
• ⛔ No silent split. ⛔ No recorded exemption: the ADR already names this case.

Why p3. It matches #21694. No shipped producer is measured: protection.lock in platform-objects sits on object, which the package door refuses anyway. An env-wide row carrying _lock comes from an authored protection block on a DB row, and the reach is measured on doubles, not over HTTP. It is still a declared lock that the write door does not honour.

Acceptance, the enumeration pin. One table drives both the read and the door over every combination of these axes:

• kernel topology: environment, host-config;
• row scope: env-wide, org-scoped;
• request scope: no organization, an organization;
• every MetadataLockSchema level;
• operation: save, delete.

For each row, the door's admit or refuse equals the read envelope's editable / deletable for the same request. A new axis or limb that splits them turns the pin red by name.

• The pin replaces neither PR fix(metadata-protocol): the read envelope's lock / editable / deletable report the write doors' locked-base verdict #21693's per-case pins nor PR fix(metadata-protocol)!: the ADR-0010 _lock gate refuses on a host-config kernel too, and the diagnostics locked count reads the item envelope derivation (#21694) #21715's. It sits above them.
• Pitfall: pin both sides on one kernel per row. A one-sided pin proves nothing for this family (5977718323).

Why blocked. PR #21715 rewrites lockWriteRefusal / assertLockAllowsDelete, the same door region of packages/metadata-protocol/src/protocol.ts this card's limb feeds (getEffectiveLock, about :16214). The enumeration pin's topology rows are green only once #21694's fix is on main. The unlock scan fires when #21694 closes.

---

Generated by Claude Code

[objectstack-fleet]

Claim: PM loop round 27 · 2026-10-04T11:18Z
Session: session_017ErfyP2Rx7XWHJA27QjyUi
Account: os-project-manager (the seat's linked user as GET /user answers it; always the card's assignee)
Branch: claude/issue-21716-lock-org-axis-agree
Worktree: objectstack-issue-21716
Domain: domain:engine
Seat: domain:engine#1
Unlock: Blocked-by: #21694 is closed completed. PR #21715 → c43a8ae612 landed the topology-independent gate at 2026-10-04T11:16Z, and the record is 5979377960. Re-derived at origin/main: no new blocker, since no open PR touches protocol.ts.
File surface, per triage's grade and direction 5979228992:

• packages/metadata-protocol/src/protocol.ts: getEffectiveLock's overlay limb (about :16225) resolves the row the read resolves for the request's organization. When the env-wide row is the one served, its _lock binds that organization's save and delete (ADR-0010 §3.3: full = "Overlay writes rejected").
  • ⛔ No silent split.
  • ⛔ No recorded exemption.
• The family's enumeration pin: one table drives the read and the door over topology × row scope × request scope × every MetadataLockSchema level × operation. Each row's door verdict equals the envelope's editable / deletable, with both sides pinned on one kernel per row. It sits above PR fix(metadata-protocol): the read envelope's lock / editable / deletable report the write doors' locked-base verdict #21693's and PR fix(metadata-protocol)!: the ADR-0010 _lock gate refuses on a host-config kernel too, and the diagnostics locked count reads the item envelope derivation (#21694) #21715's pins, replacing neither.
• Tests; .changeset/21716-*.md.
  Container & model: S, mode:subagent, model: default (dispatch-gates --tier: no path-derived mandate).
  Clause-②: no (narrowing)
• An org-scoped save or delete that an env-wide _lock declares refused is now refused. Nothing widens, and no key, export or error code is added.
  Thread-read: 5979228992
  Serial constraints cleared: at 2026-10-04T11:18Z:
• Of the open PRs, none touches packages/metadata-protocol/src/protocol.ts.
• os-verify-lock: the lock is free and the queue empty, so the arrival depth is 1.
• This lane has no other claim in flight.

[objectstack-fleet]

os-dev-report
{
"issue": 21716,
"status": "done",
"branch": "claude/issue-21716-lock-org-axis-agree",
"pr": "#21737",
"session": "session_017ErfyP2Rx7XWHJA27QjyUi",
"premise_still_valid": true,
"summary": "The ADR-0010 _lock gate's overlay limb (getEffectiveLock) now resolves the stored row through findServedOverlayRow, a new private method that getMetaItem (row read and draft-preview arm) and getMetaItemLayered also call: the org-scoped row, else the env-wide row (ADR-0005 precedence), ADR-0048 prefer-local, behind the same organizationIdForMetaRead gate. So an env-wide row's _lock now binds an organization with no row of its own, on save, publish, rollback and delete, on both kernel topologies, and the door admits exactly when the read envelope's editable / deletable say it may. One declared difference, measured rather than assumed: the reads keep their at-rest other-spelling fallback and the gate stays canonical-only (otherSpelling: false), because full reuse turned objectql's #4432 pin red (a write must address the canonical namespace only). The family's enumeration pin (topology x row scope x request scope x every MetadataLockSchema level x operation, 64 named rows, one protocol instance per row) plus the defect, precedence and org-gate pins land in protocol.lock-org-axis-agree.test.ts (86 cases).",
"census": {
"measured_at": "c43a8ae612, real ObjectStackProtocolImplementation over an engine double, view type; identical on environment and host-config kernels",
"columns": "stored rows | request | both reads serve | door overlay limb at base | agree",
"rows": [
"env-wide full | none | env-wide row (full) | organization_id null: env-wide row (full) | yes",
"env-wide full | org_a | env-wide row (full) | organization_id = org_a: nothing (none) | SPLIT (the card)",
"org full | none | nothing (none) | null: nothing (none) | yes",
"org full | org_a | org row (full) | org_a: org row (full) | yes",
"env full + org none | none | env-wide row (full) | env-wide row (full) | yes",
"env full + org none | org_a | org row (none) | org row (none) | yes",
"env none + org full | none | env-wide row (none) | env-wide row (none) | yes",
"env none + org full | org_a | org row (full) | org row (full) | yes",
"neither | either | nothing (none) | nothing (none) | yes"
],
"after_fix": "the same probe at f565417 found 0 split cells on either kernel; the final shape is held by pin 1 (64 rows) green at 87e350b"
},
"tests": "All on head 87e350b (after merging origin/main 316be32). @objectstack/metadata-protocol: vitest run -> Test Files 212 passed | 3 skipped (215), Tests 3675 passed | 19 skipped (3694) (3589 before + 86 new); typecheck tsc --noEmit green, --listFiles compiles 215 test files incl. the new pin. @objectstack/objectql (against the rebuilt metadata-protocol dist): vitest run --project local -> 372 files, 7458 tests passed; --project repo -> 1 file, 5 tests passed. Narrowed lint: eslint --no-inline-config --format json over protocol.ts + the pin -> 2 file results, 0 errors, 0 warnings; population from eslint's own config (isPathIgnored false for both, 5-rule computed config each); invariance: no parserOptions.project / projectService in either computed config and eslint.config.mjs never enables type-aware linting. Reverse verification from committed HEAD 7b37480 via scripts/ablation-replace.mjs (wrap mode) inside a script with an EXIT INT TERM trap restoring from HEAD by absolute path; subject resolved from source (./protocol.js), no rebuild in path; direction declared first. Ablation 1 (exact-organization_id limb restored): anchor 1 -> 0, marker on disk 1, blob e6a207612cc4 -> c598f7de3b47; predicted 16 red / 70 green, measured Tests 16 failed | 70 passed (pin 1's 8 org-axis cells, all 4 of pin 2, all 4 of pin 4; pin 3 and the other 56 pin-1 rows green). Ablation 2 (org gate removed from the door only): anchor 1 -> 0, marker 1; predicted 4 red, measured 4 failed | 82 passed (pin 4 only). Restore after each leg: blob == HEAD blob e6a207612cc4, git diff HEAD empty, git status --porcelain empty (tool and trap both). During the work, a first full-reuse shape turned objectql protocol-meta-type-canonicalization.test.ts red (1 failed | 7457 passed); the final canonical-only gate leaves it green, unchanged. NOT MEASURED: HTTP (reach on doubles); a live dev server boot; rest and runtime suites (consumers; no export, spec contract or wire shape change); CI-owned Dogfood, Temporal Conformance, type-check lanes, full pnpm lint.",
"gates": "Head 87e350b, after the final commit, exit codes captured before any pipe. Derived: node scripts/pm/dispatch-gates.mjs --commands (no paths) -> 72 families, all 72 exit 0; --ran reconciliation: '72 derived, 72 run, 0 NOT-MEASURED, 0 UNRUN' (check:dual-build-cjs-loads and check:lean-entry-closure first exited 3 PREREQUISITE NOT MET, re-run after a full turbo build -> 0). check:engine-double-contract asked for the new pin's findOne double; recorded with the gate's own --write (1 added, 0 lost) and committed. Artifact-roster block: 54 run; 51 exit 0 locally, the 3 PR-context guards (check-closing-target-claim, check-partof-closing-keyword, check-single-claim-paths) exit 2 NOT WIRED before the PR existed, then exit 0 against PR 21737 after pr_create. Four symbol-anchor sweeps exit 0: adr-symbol-anchors 2167 anchors / 140 records; scripts-symbol-anchors 3760 / 282 scripts; spec-docblock-symbol-anchors 4950 / 1868 sources; adr-anchors OK. 129 commands total, 0 non-zero at the end.",
"line_budget": "n/a",
"files_changed": [
"packages/metadata-protocol/src/protocol.ts (findServedOverlayRow added; getMetaItem, getMetaItemLayered and getEffectiveLock call it; getEffectiveLock docblock)",
"packages/metadata-protocol/src/protocol.lock-org-axis-agree.test.ts (new, 86 cases)",
"scripts/engine-double-contract.pinned.json (+1 row, by the gate's --write)",
".changeset/21716-lock-org-axis-agree.md (minor @objectstack/metadata-protocol, Clause-② no (narrowing), BREAKING banner, adr-0087 not-required (no-migration-prescription))"
],
"deviations": [
"H2 '⛔ No second predicate' is met with ONE declared parameter difference, otherSpelling: the reads pass true (their at-rest other-spelling fallback), the gate passes false (canonical only). Measured cause: full reuse made the gate query type 'actions' on a create and turned objectql protocol-meta-type-canonicalization.test.ts ('a plural-spelled write addresses the canonical namespace and no other', the #4432 pin) red; re-aiming it would loosen it. Scope precedence, package prefer-local and the org gate are one shared code path. Raised in open_questions.",
"git push: 6 pushes to the one branch (the empty-branch probe, then each committed step, per the WIP-push rule), not one. All fast-forward, no force.",
"The 3 PR-context roster guards could only be run after pr_create; run then, all exit 0.",
"The PR got labels documentation, size/l, tests, tooling from the path labeler, not from this run; this run wrote only the assignee."
],
"mcp_calls": "0",
"api_writes": "3 REST writes, each one repository_dispatch through the fleet-write relay (POST /repos/objectstack-ai/objectstack/dispatches) executed as objectstack-fleet[bot]: (1) pr_create -> POST /repos/objectstack-ai/objectstack/pulls (draft, PR 21737, body read back identical, 14800 bytes); (2) label-write --assign os-project-manager -> POST /repos//issues/21737/assignees (read back matches); (3) this os-dev-report comment -> POST /repos//issues/21716/comments. Plus git push (not a REST write).",
"open_questions": [
{
"question": "The gate keeps to the canonical type spelling while both reads still fall back to a row stored under the other (plural) spelling. For pre-#4432 at-rest residue with no canonical row in that scope, the read can report a lock the door does not see. Which side should move?",
"options": [
"A. Keep it as landed: the gate canonical-only (#4432's write-side rule, pinned by objectql's canonicalization test), the difference declared on findServedOverlayRow; residue only, no live writer mints such a row.",
"B. Full reuse: the gate also reads the other spelling, and the #4432 test is re-aimed to 'the caller's spelling does not change the lookups' (a weaker statement than today's).",
"C. Retire the reads' other-spelling fallback (contract-first: no tolerant lookup below the folding boundary) on its own card, after which the parameter disappears and the two are byte-identical."
],
"recommendation": "A now, C as the follow-up if the seat wants the residue axis closed: A keeps a landed write-side contract intact and costs nothing on live rows; B weakens a pin to tolerate legacy data in the write path; C removes the tolerance at its source, which is the contract-first direction, but it changes read behaviour and is outside this card."
}
],
"out_of_scope_findings": [
"class: b · reach: measured on the real ObjectStackProtocolImplementation reads and _lock gate over an engine double at c43a8ae (not over HTTP) · evidence: a packaged view whose artifact declares _lock 'none' explicitly (protection.lock 'none' through applyProtection) plus a stored env-wide row declaring _lock 'full': getMetaItem and getMetaItemLayered both answer lock none, editable true (mergeArtifactProtection copies any defined artifact _lock, 'none' included, over the row's), while getEffectiveLock answers full / source=overlay (its artifact limb skips 'none'), so the save door refuses ITEM_LOCKED. The door is stricter than the read; servedLockState's contract is that the flags report the doors' verdict. Seam: spec:MetadataProtectionFields._lock → runtime:ObjectStackProtocolImplementation.getEffectiveLock artifact limb vs mergeArtifactProtection. Same family as this closing card, which is in flight, so named here, not merged; which side moves is a fork. · dedupe words: mergeArtifactProtection explicit none, artifact _lock none overlay full, getEffectiveLock artifact limb skips none, editable true door refuses",
"class: b · reach: measured on the real reads and gate over an engine double at c43a8ae (not over HTTP; the layered read serves GET /api/v1/meta/:type/:name/layers) · evidence: a packaged view with no _lock plus a stored env-wide row declaring _lock 'full': getMetaItem answers full / editable false (agrees with the door, which refuses ITEM_LOCKED), getMetaItemLayered answers none / editable true because its lock source is code ?? overlay, which takes the code layer whenever one exists; the comment there says 'matching getEffectiveLock', which it does not. Two reads of one item disagree, the layered one looser than the doors. Seam: spec:MetadataProtectionEnvelopeFields (api/protocol.zod.ts) → runtime:getMetaItemLayered lockSource. · dedupe words: getMetaItemLayered lockSource code ?? overlay, layered read lock packaged overlay _lock, layered editable vs by-name editable",
"carrier: 承接者:无 · noted, not filed (in PR 21737 Acceptance notes): (1) the declared other-spelling difference above (pre-#4432 residue only); (2) the package axis: the gate asks without a packageId while a read naming one prefers that package's row (ADR-0048), splitting only when one (type, name, scope) holds rows from two packages, not measured; (3) getMetaItemLayered no longer falls back to the env-wide row when an org row's stored body is JSON null, it reports the org row as getMetaItem always did."
]
}

---

Generated by Claude Code

[objectstack-fleet]

os-dev-report addendum: narrow rework on PR #21737, per the seat's comment 5980059935

New head: f508c21ce3 (one commit on top of 87e350bbaf; one push, fast-forward, no force). No code change. origin/main is still 316be321ef, the base already merged, so nothing was merged.

The changeset sentence (.changeset/21716-lock-org-axis-agree.md, the "Unchanged" paragraph; every other sentence is as it was):

• Before: "Both reads."
• After: "Both reads, apart from one case in getMetaItemLayered: it now serves an organization's own stored row whose body is JSON null, as getMetaItem already did, instead of falling back to the env-wide row, because the two reads now share one row resolution. Only residue can reach it: no live writer stores a null body (measured: SysMetadataRepository.put, the writer behind every /meta save, stores {} for an absent body; saveMetaItem refuses a null item with 400 INVALID_REQUEST; and the only other sys_metadata writer, the datasource admin plugin, stores an object env-wide)."

How "who can see it" was measured, at f508c21ce3:

• git grep of non-test writes to sys_metadata finds two writers:
  • SysMetadataRepository.put, which writes JSON.stringify(spec ?? {});
  • persistDatasourceRow in service-datasource, which writes an object, with no organization.
• The repository's only protocol caller is saveMetaItem, which refuses a missing or null item at its top.

The open question. It was answered A: the gate stays canonical-only, and the difference stays declared on findServedOverlayRow. Nothing was filed by this run.

Gate readings at f508c21ce3. Exit codes were captured before any pipe.

• node scripts/check-adr-0087-registration.mjs --base origin/main: exit 0. "1 declared-breaking changeset(s), each carrying an ADR-0087 disposition."
• node scripts/check-changeset-no-major.mjs --base origin/main: exit 0. "This diff introduces no major bump." There is no pnpm check:changeset-no-major script in the root manifest, so this node spelling is the derived one.
• Every other derived family that reads .changeset/** exits 0:
  • check-empty-changeset --base origin/main and --self-test;
  • the check-adr-0087-registration and check-changeset-no-major self-tests;
  • check:changeset-gate-self-tests, check:doc-authoring, check:nul-bytes, check:objectui-changeset and check:pm-changeset-deadline-census;
  • the roster's check-changeset-fixed, and check:issue-citations.
• The 3 PR-context guards, run with PR 21737's context (head f508c21ce3, the live body): check-closing-target-claim, check-single-claim-paths and check-partof-closing-keyword all exit 0.

---

Generated by Claude Code