Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
51 changes: 51 additions & 0 deletions .changeset/liveness-symbol-anchors-batch-4.md
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,51 @@
---
"@objectstack/spec": patch
---

chore(spec): re-anchor the closing twelve liveness ledgers to consuming symbols (#13003)

Adoption batch 4 — the closing batch — of the symbol-anchor citation grammar
landed by #12516. The `liveness/` ledgers ship inside this package's npm tarball
(they are named in `files`), so this is a published-data change even though no
runtime behaviour moves and no schema key changes.

Eighty of the eighty-two remaining `path:NNN` citations — across
`liveness/app.json`, `validation.json`, `translation.json`, `field.json`,
`hook.json`, `mapping.json`, `capability.json`, `seed.json`, `view.json`,
`dashboard.json`, `flow.json` and `qa.json` — are now written `path#symbol`,
each re-closed by reading the code on the current tree rather than by shifting a
line number. Every path-only pointer in the same entries is anchored with them.
The gate's own line-citation counter goes 82 to 2 and its symbol-anchor counter
383 to 499.

Sixty-seven of the eighty were already wrong, every one IN RANGE and therefore
invisible to the existence check, the line bound and the key-mention check alike.
Six files were 100% rotted (validation 10/10, seed 6/6, view 5/5, dashboard 4/4,
flow 4/4, qa 4/4). The dominant shape is BLOCK drift: nine of `validation.json`'s
ten pointers had come to rest inside one 70-line ADR-0124 docblock roughly 1,200
lines above `evaluateValidationRules`, and `app.json`'s `name` / `label` /
`description` had settled on three consecutive lines of one unrelated action
resolver. `flow.status` is the sharpest single case — its pointer landed on
`flowLedgerDisabled`, the map ADJACENT to the one this key writes, after #10243
split the two apart.

Two silent classes are closed with them. Seventeen positions across four files
were written as bare `:NNN` suffixes with no path in front of them, which the
scanner never matched as citations at all, so nothing ever resolved, bounded or
key-checked them; `translation.objects` alone carried five. Three more entries
(`hook.retryPolicy` / `timeout` / `onError`) cited a path with no line, which a
line bound cannot falsify by construction. All twenty are repo-rooted anchors now.

Three citations were falsified in PROSE as well as position and are corrected
with their lines: `view.object` credited `getViewsByObject()` to
`packages/objectql/src/engine.ts` (it is in `packages/metadata`),
`field.requiredWhen` named `fieldRequiresParentRoot` (no such symbol; it is
`hasParentScopedRequiredWhen`), and `translation.metadataForms` named
`translateMetaTypes` (it is `translateMetaTypesResponse`).

Nothing is re-classified. Two entries are deliberately left byte-for-byte
untouched and un-restamped because their `live` verdict — not their citation —
is what is falsified: `action.execute` (reported as #13036) and
`field.conditionalRequired` (reported as #13043), both `retiredKey` tombstones
since protocol 17 whose cited `.transform` lowering no longer exists. Those are
ADR-0049 re-classifications with their own card shape.
56 changes: 28 additions & 28 deletions packages/spec/liveness/app.json

Large diffs are not rendered by default.

32 changes: 16 additions & 16 deletions packages/spec/liveness/capability.json
Original file line numberDiff line numberDiff line change
@@ -1,36 +1,36 @@
{
"type": "capability",
"_note": "CapabilityDeclarationSchema (ADR-0066 D1). The DECLARATION side of the three-way separation — packages DEFINE a capability here, permission sets GRANT it via `systemPermissions`, resources REQUIRE it via `requiredPermissions`. Seeded 2026-08-08 with #5961, the PR that made `capability` a registered metadata kind; every property was call-graph-closed at that time against `packages/plugins/plugin-security/src/bootstrap-declared-capabilities.ts`, which is the one consumer that turns a declaration into a `sys_capability` row. The ADR-0010 envelope keys carry the same `null` verdict as `permission`/`position`: they are loader-stamped, not authored.",
"_note": "CapabilityDeclarationSchema (ADR-0066 D1). The DECLARATION side of the three-way separation — packages DEFINE a capability here, permission sets GRANT it via `systemPermissions`, resources REQUIRE it via `requiredPermissions`. Seeded 2026-08-08 with #5961, the PR that made `capability` a registered metadata kind; every property was call-graph-closed at that time against `packages/plugins/plugin-security/src/bootstrap-declared-capabilities.ts`, which is the one consumer that turns a declaration into a `sys_capability` row. The ADR-0010 envelope keys carry the same `null` verdict as `permission`/`position`: they are loader-stamped, not authored. 2026-08-28 (#13003): all six `path:NNN` citations in this file were re-anchored to their consuming symbols. Five of the six were wrong and every one was IN RANGE; the three row-field pointers had drifted as a block onto three consecutive lines of one unrelated docblock, which reads as precision right up until you open the file.",
"props": {
"name": {
"status": "live",
"verifiedAt": "2026-08-08",
"evidence": "packages/plugins/plugin-security/src/bootstrap-declared-capabilities.ts:203-210 (upsertPackageCapability the name is the `sys_capability` upsert key, is matched against PLATFORM_CAPABILITY_NAMES to refuse shadowing a curated capability, and is the string `systemPermissions` / `requiredPermissions` resolve a grant by); packages/lint/src/validate-capability-references.ts:99 (the authoring lint's known-name set)",
"note": "The whole identity of a capability. This is also why the kind's write door matters: the name is resolved by string from both the grant side and the requirement side, so an unvalidated row lands directly in the authorization namespace (#5961)."
"verifiedAt": "2026-08-28",
"evidence": "packages/plugins/plugin-security/src/bootstrap-declared-capabilities.ts#upsertPackageCapability (the name is the `sys_capability` upsert key and is matched against `PLATFORM_CAPABILITY_NAMES` to refuse a package shadowing a curated capability; it is also the string `systemPermissions` / `requiredPermissions` resolve a grant by); packages/lint/src/validate-capability-references.ts#validateCapabilityReferences (`known.add(cap.name)` — the authoring lint's known-name set)",
"note": "The whole identity of a capability. This is also why the kind's write door matters: the name is resolved by string from both the grant side and the requirement side, so an unvalidated row lands directly in the authorization namespace (#5961). 2026-08-28: RE-ANCHORED (#13003), and REPOINTED on the bootstrap leg — `:203-210` had rotted onto the opening `/**` of the unowned-declaration diagnostic's docblock; `upsertPackageCapability` begins ~43 lines below it. The lint leg was ACCURATE (`:99` is still `known.add(cap.name)`) and is migrated, not repaired. Re-closed by hand against 8cb96ec41."
},
"label": {
"status": "live",
"verifiedAt": "2026-08-08",
"evidence": "packages/plugins/plugin-security/src/bootstrap-declared-capabilities.ts:122 (capabilityRowFields — written to sys_capability.label, falling back to humanize(name) when absent)",
"note": "display (Setup's capability list/detail, rendered from the sys_capability row)."
"verifiedAt": "2026-08-28",
"evidence": "packages/plugins/plugin-security/src/bootstrap-declared-capabilities.ts#capabilityRowFields (`label: typeof cap.label === 'string' && cap.label ? cap.label : humanize(cap.name)` — written to `sys_capability.label`)",
"note": "display (Setup's capability list/detail, rendered from the sys_capability row). 2026-08-28: RE-ANCHORED (#13003) and REPOINTED — `:122` had rotted onto a docblock sentence about the `unchanged` outcome counter, ~45 lines above `capabilityRowFields`. Its two siblings cited `:123` and `:124`, the next two lines of that same docblock: the three row-field pointers had drifted as ONE block, which is why none of them looked wrong beside the others. Re-closed by hand against 8cb96ec41."
},
"description": {
"status": "live",
"verifiedAt": "2026-08-08",
"evidence": "packages/plugins/plugin-security/src/bootstrap-declared-capabilities.ts:123 (capabilityRowFields — written to sys_capability.description, falling back to `Capability <name>.` when absent)",
"note": "display."
"verifiedAt": "2026-08-28",
"evidence": "packages/plugins/plugin-security/src/bootstrap-declared-capabilities.ts#capabilityRowFields (`description: … ? cap.description : `Capability ${cap.name}.`` — written to `sys_capability.description`)",
"note": "display. 2026-08-28: RE-ANCHORED (#13003) and REPOINTED — `:123` had rotted onto the closing `*/` of that docblock (see the `label` entry: all three of this file's row-field pointers moved together). Re-closed by hand against 8cb96ec41."
},
"scope": {
"status": "live",
"verifiedAt": "2026-08-08",
"evidence": "packages/plugins/plugin-security/src/bootstrap-declared-capabilities.ts:124 (capabilityRowFields — written to sys_capability.scope, normalized to 'org' only on an exact 'org' match, else 'platform')",
"note": "platform vs org decides whether holding the capability is a global power or one scoped to the caller's organization — the same distinction PLATFORM_CAPABILITIES carries on the curated side. Not display: it is the field that would be escalated if a tenant could overlay a package-shipped declaration, which is why the #5961 registry entry sets `supportsOverlay: false` / `allowOrgOverride: false`."
"verifiedAt": "2026-08-28",
"evidence": "packages/plugins/plugin-security/src/bootstrap-declared-capabilities.ts#capabilityRowFields (`scope: cap.scope === 'org' ? 'org' : 'platform'` — normalized on an exact `org` match, else `platform`)",
"note": "platform vs org decides whether holding the capability is a global power or one scoped to the caller's organization — the same distinction PLATFORM_CAPABILITIES carries on the curated side. Not display: it is the field that would be escalated if a tenant could overlay a package-shipped declaration, which is why the #5961 registry entry sets `supportsOverlay: false` / `allowOrgOverride: false`. 2026-08-28: RE-ANCHORED (#13003) and REPOINTED — `:124` had rotted onto `unchanged: number;`, the counter field itself (see the `label` entry). Re-closed by hand against 8cb96ec41."
},
"packageId": {
"status": "live",
"verifiedAt": "2026-08-08",
"evidence": "packages/plugins/plugin-security/src/bootstrap-declared-capabilities.ts:294 (`const packageId= cap._packageId ?? cap.packageId` — the ADR-0086 D3 author-declared FALLBACK provenance, consulted when the registry stamp is absent; with neither, upsertPackageCapability takes the no-owning-package refusal at :214 and the capability is materialized with no package provenance)",
"note": "Deliberately a fallback and not the primary: #5870 added `capabilities` to the ObjectQL engine's stamped-collection list (packages/objectql/src/engine.ts:2393), so `_packageId` now reaches a declaration and takes precedence. The key stays live because the fallback branch is still read and still decides materialization for any declaration that arrives unstamped."
"verifiedAt": "2026-08-28",
"evidence": "packages/plugins/plugin-security/src/bootstrap-declared-capabilities.ts#bootstrapDeclaredCapabilities (`const packageId: string | undefined = cap._packageId ?? cap.packageId ?? undefined` — the ADR-0086 D3 author-declared FALLBACK provenance, consulted when the registry stamp is absent); packages/plugins/plugin-security/src/bootstrap-declared-capabilities.ts#upsertPackageCapability (with neither, this takes the no-owning-package refusal and the capability is materialized with no package provenance)",
"note": "Deliberately a fallback and not the primary: #5870 added `capabilities` to the ObjectQL engine's stamped-collection list (packages/objectql/src/engine.ts:2393), so `_packageId` now reaches a declaration and takes precedence. The key stays live because the fallback branch is still read and still decides materialization for any declaration that arrives unstamped. 2026-08-28: RE-ANCHORED (#13003) and REPOINTED — `:294` had rotted onto a `//` continuation line inside the unowned-declaration refusal's comment block, and the read itself had moved OUT of `upsertPackageCapability` into its caller, which is the distinction the two anchors now hold apart. The note's `engine.ts:2393` pointer was stale in the same way; the stamped-collection list is `packages/objectql/src/engine.ts#METADATA_ARRAY_KEYS`. Re-closed by hand against 8cb96ec41."
},
"_lock": null,
"_lockReason": null,
Expand Down
Loading
Loading