Filed unassigned by the #10101 services seat (session session_01APWX2AwT3a4xDcjPCe8bk4); grading and domain:* are triage's to mint — routed toward the spec seat, because the services lane holds zero packages/spec ownership and this is a packages/spec prose slice.
What
The #8778 scope-pin annotation beside tenancy.organizationField in packages/spec/src/data/object.zod.ts (landed by #10999) transcribes the cloud#1395 ruling and says, correctly at the time it was written:
#10101's PR lands consumers 2 and 3 (the approval-row writer and the automation-run recorder, both through the shared resolver now in @objectstack/metadata-core), so those three sentences and the .describe() ("consulted exclusively when audit rows are stamped") are now stale. The annotation assigned the refresh to #10101 — but the #10101 dispatch bars that lane from packages/spec entirely (zero ownership; its spec slice was exactly #10999), so the slice is filed here instead of ridden.
Also mildly stale in the same block: the resolver is named as "plugin-audit's resolveRecordOrganizationField" — its home is @objectstack/metadata-core since #10101 (plugin-audit re-exports).
What this is NOT
⛔ Not a widening. The pin's load-bearing property — "The ruling sanctions exactly THREE consumers of this key, and no others", fourth consumer needs its own ruling — is untouched. This card is prose/.describe() accuracy only; no accept/reject behaviour change, no new consumer.
Note the .describe() edit regenerates spec's generated artifacts (gen:schema/gen:docs per the AGENTS.md table).
Blocked-by: the #10101 PR (the readers must actually be on main before the text stops being true).
Refs: #10101 · #10999 · #8778 · cloud#1395.
Filed unassigned by the #10101 services seat (session
session_01APWX2AwT3a4xDcjPCe8bk4); grading anddomain:*are triage's to mint — routed toward the spec seat, because the services lane holds zeropackages/specownership and this is apackages/specprose slice.What
The #8778 scope-pin annotation beside
tenancy.organizationFieldinpackages/spec/src/data/object.zod.ts(landed by #10999) transcribes the cloud#1395 ruling and says, correctly at the time it was written:resolveRecordOrganizationFieldto the shared platform-row resolver (approvals + automation runs), per the ruled cloud#1395 Option A #10101 carries that behaviour change";.describe()below still speaks of audit rows — it states what reads the key TODAY, and PromoteresolveRecordOrganizationFieldto the shared platform-row resolver (approvals + automation runs), per the ruled cloud#1395 Option A #10101 updates it as the readers actually land".#10101's PR lands consumers 2 and 3 (the approval-row writer and the automation-run recorder, both through the shared resolver now in
@objectstack/metadata-core), so those three sentences and the.describe()("consulted exclusively when audit rows are stamped") are now stale. The annotation assigned the refresh to #10101 — but the #10101 dispatch bars that lane frompackages/specentirely (zero ownership; its spec slice was exactly #10999), so the slice is filed here instead of ridden.Also mildly stale in the same block: the resolver is named as "plugin-audit's
resolveRecordOrganizationField" — its home is@objectstack/metadata-coresince #10101 (plugin-audit re-exports).What this is NOT
⛔ Not a widening. The pin's load-bearing property — "The ruling sanctions exactly THREE consumers of this key, and no others", fourth consumer needs its own ruling — is untouched. This card is prose/
.describe()accuracy only; no accept/reject behaviour change, no new consumer.Note the
.describe()edit regenerates spec's generated artifacts (gen:schema/gen:docsper the AGENTS.md table).Blocked-by: the #10101 PR (the readers must actually be on
mainbefore the text stops being true).Refs: #10101 · #10999 · #8778 · cloud#1395.