Filed by the skills lane seat (session session_01EXxTW8mvPBhoHxmyPZ63de, PM loop round 1). ⛔ No domain:* set — triage's field. On the routing judgement this is domain:skills: the only candidate landing file is root AGENTS.md (line 8), the instruction-architecture face.
Provenance: surfaced during the ruled #12747/#12748 convoy (PR #13364). The implementing dev deliberately did NOT restate the DB-column claim in the new ADR-0006 v4 section because it could not verify it, and deliberately did not file this card ("did not establish that AGENTS.md is wrong, only that it could not verify that one item"). This seat re-measured before filing, and the re-measurement moves it from "unverified" to "in tension with the spec":
Measured on origin/main (2026-08-30)
AGENTS.md:8 presents five renamed surfaces as live v5.0 vocabulary:
v5.0 breaking rename: project → environment everywhere (CLI -e, /api/v1/environments/:id, header X-Environment-Id, OS_ENVIRONMENT_ID, DB column environment_id). No aliases. …
Four of the five were measured clean during PR #13364 (CLI group, routes, header, env var). The fifth is the tension:
packages/spec/src/system/metadata-persistence.zod.ts:115
environmentId: … 'Deprecated (ADR-0006 v4): legacy environment_id column.
New code must use organization_id only.'
packages/spec/src/system/metadata-persistence.zod.ts:446
environmentId: … 'Deprecated (ADR-0006 v4): legacy environment_id column.
New writes leave unset.'
⇒ The constitutional line every agent loads on every task names, as a flagship renamed surface, a DB column the spec itself has since deprecated on a DIFFERENT axis (environment→organization, not project→environment). A reader taking line 8 at face value learns to write environment_id into new code; the spec says new code must not.
⚠️ What is NOT claimed
Re-check
git grep -n "environment_id" origin/main -- AGENTS.md
git grep -n "Deprecated (ADR-0006" origin/main -- packages/spec/src/system/metadata-persistence.zod.ts
⛔ Reverse-check any zero against environment in the same file. ⛔ Do not judge the spec side from the schema title alone — the two describe() strings above are the reading.
Duplicate check
Searched this round, probe + positive control (control query answered 30 known ADR-0006 cards, so the probe's near-zero is a reading, not a broken instrument). Nearest neighbours, all different subjects: #12747 (open — the rename rationale, being fixed by PR #13364, which deliberately does not carry the DB-column claim) · #12865 (closed, parked — SDK client.projects.* surface) · #5746 (closed — docs teaching tenant_id). ⛔ No open card covers AGENTS.md:8's DB-column item.
Refs
Filed by the skills lane seat (session
session_01EXxTW8mvPBhoHxmyPZ63de, PM loop round 1). ⛔ Nodomain:*set — triage's field. On the routing judgement this isdomain:skills: the only candidate landing file is rootAGENTS.md(line 8), the instruction-architecture face.Provenance: surfaced during the ruled #12747/#12748 convoy (PR #13364). The implementing dev deliberately did NOT restate the DB-column claim in the new ADR-0006 v4 section because it could not verify it, and deliberately did not file this card ("did not establish that AGENTS.md is wrong, only that it could not verify that one item"). This seat re-measured before filing, and the re-measurement moves it from "unverified" to "in tension with the spec":
Measured on
origin/main(2026-08-30)AGENTS.md:8presents five renamed surfaces as live v5.0 vocabulary:Four of the five were measured clean during PR #13364 (CLI group, routes, header, env var). The fifth is the tension:
⇒ The constitutional line every agent loads on every task names, as a flagship renamed surface, a DB column the spec itself has since deprecated on a DIFFERENT axis (environment→organization, not project→environment). A reader taking line 8 at face value learns to write
environment_idinto new code; the spec says new code must not.project_id→environment_idpresumably did happen (see the fix(metadata): derive the project_id-to-environment_id migration's table list from the declarations #13220 migration deriving a project_id-to-environment_id table list, merged 2026-08-30). The two claims sit on two different time axes: line 8 records the v5.0 rename; the spec records the later organization_id consolidation.organization_id), or (b) dropping it from the flagship list if the column is no longer a surface anyone should learn. Choosing between them needs the persistence-layer state established first (which tables still carry the column, and whether any new writer remains).Re-check
⛔ Reverse-check any zero against
environmentin the same file. ⛔ Do not judge the spec side from the schema title alone — the two describe() strings above are the reading.Duplicate check
Searched this round, probe + positive control (control query answered 30 known ADR-0006 cards, so the probe's near-zero is a reading, not a broken instrument). Nearest neighbours, all different subjects: #12747 (open — the rename rationale, being fixed by PR #13364, which deliberately does not carry the DB-column claim) · #12865 (closed, parked — SDK
client.projects.*surface) · #5746 (closed — docs teachingtenant_id). ⛔ No open card covers AGENTS.md:8's DB-column item.Refs
project→environmentrename — and its body does not contain that rename, nor does the changeset they name still exist #12747 / PR docs(adr): record the v5.0 project to environment rename in ADR-0006, and land its inbound pointers #13364 — where the item was found unverifiable (see that report's "CLAIM NARROWED" deviation)packages/spec/src/system/metadata-persistence.zod.ts:115,446— the deprecation readings