TASK-261: the ADR-004 conformance gate and perry-migrate come out — −10,907 lines

.perry/events.jsonl

@@ -1396,3 +1396,15 @@
 {"ts": "2026-08-30T16:44:25+08:00", "event": "done", "id": "TASK-234", "title": ".perry/conformance.md is a pure ledger with a hand-rolled table parser, and its phantom row has nowhere to record provenance", "track": "main", "owner": "Coding Agent", "role": "", "actor": "Ran Jiao", "from": "in_progress", "to": "done", "evidence": "perry/evidence/2026-08/TASK-234-round5-v4-review.md", "rung": "V3"}
 {"ts": "2026-08-30T16:44:44+08:00", "event": "summary", "id": "TASK-255", "title": "Perry never shell-quotes a path into a command it hands a reader — shlex appears nowhere in bin/ or viewer/", "track": "main", "actor": "Ran Jiao", "field": "summary", "from": "SIZED 2026-08-30 by the TASK-234 round-4 agent, which measured the class OUTSIDE the two tools it was fixing: 63 handed-back commands across the other twelve bin/perry-* executables, 25 of them WITHOUT THE ROOT, including six more places that hand back 'perry-tasks render --write' — the command that writes another project's BOARD.md. It also reports that its raw-interpolation rule OVER-REPORTS there (3 genuine, 16 being FLAG_VALUE reading a flag mentioned in prose) and says so rather than quoting 19. So this row's population is 25 confirmed root-droppers plus 3 confirmed raw interpolations, and the instrument's precision on the rest of bin/ is known to be poor. TASK-234 also shipped the shape this row should generalise: a choke point PLUS a source rule, on the argument that a choke point alone is only a convention — _root_flag was already a choke point and that is exactly why it failed.", "to": "POPULATION CORRECTED 2026-08-30 by the TASK-234 round-5 reviewer, which re-derived the census with its own instrument: the row's headline was over FOURTEEN tools, not twelve. Over the other twelve it is 42 handed-back commands / 208 mentions, not 63 / 232 — the difference is exactly perry-conform and perry-migrate's own 21/24, which TASK-234 has now fixed. So THIS ROW'S POPULATION IS A THIRD SMALLER THAN FIRST FILED. The counts that actually matter reproduce exactly: 25 rootless and 19 raw, with both splits confirmed. Two further corrections: of the '3 genuine' raw interpolations outside these tools, TWO INTERPOLATE THE VERB, NOT AN ARGUMENT, so the genuine count is 1; and the backtick residual TASK-234 sized at two is EIGHT, of which only the message_for pair is pinned — two of the unpinned six are 'perry-tasks render --write' and 'write --from-board', the ones that WRITE. Whoever takes this row should re-derive the census a third time rather than inherit any of these numbers: it has now been measured three times and been wrong twice."}
 {"ts": "2026-08-30T16:44:44+08:00", "event": "add", "id": "TASK-259", "title": "Nothing asserts the TASK-234 fixture root is shell-hostile, and 8 of 19 bypass spellings get past the source rule", "track": "main", "mode": "project", "priority": "P1", "actor": "Ran Jiao", "summary": "Filed 2026-08-30 from the TASK-234 round-5 review. Item (b) is the interesting one: the row's defence is a choke point PLUS a source rule, and the source rule is the half that makes the choke point more than a convention — so its recall is the property the whole shape rests on. It is 11 of 19 today.", "depends_on": [], "from": null, "to": "not_started"}
+{"ts": "2026-08-31T20:27:36+08:00", "event": "add", "id": "TASK-260", "title": "V4 criteria must be bounded, and the round stops auditing its own exhibit", "track": "main", "mode": "project", "priority": "P1", "actor": "agent", "summary": "TASK-050 ran 11 rounds against a universal negative and PASSed on the round the criterion became decidable. Measured: 22 of 49 finding headlines audit the round's own artifact, not the product.", "depends_on": [], "from": null, "to": "not_started"}
+{"ts": "2026-08-31T20:27:48+08:00", "event": "done", "id": "TASK-260", "title": "V4 criteria must be bounded, and the round stops auditing its own exhibit", "track": "main", "owner": "Coding Agent", "role": "", "actor": "agent", "from": "not_started", "to": "done", "evidence": "a4eb411; evidence/2026-08/2026-08-31-representation-layer-delete-list.md", "rung": "V3"}
+{"ts": "2026-08-31T20:27:48+08:00", "event": "add", "id": "TASK-261", "title": "Tier A — the ADR-004 declaration gate comes out; perry-conform keeps only its shared helpers", "track": "main", "mode": "project", "priority": "P1", "actor": "agent", "summary": "23 records, all route: declare, all Perry's own files, zero migrations and zero disagreements. The gate's value needs a foreign project that drifts, and Perry has never been run on one. The delete list said 'delete bin/perry-conform, 974 lines'; that was wrong — 598 lines are the dead ledger and ~280 are helpers four tools depend on, so the file is gutted, not removed.", "depends_on": [], "from": null, "to": "not_started"}
+{"ts": "2026-08-31T20:27:58+08:00", "event": "start", "id": "TASK-261", "title": "Tier A — the ADR-004 declaration gate comes out; perry-conform keeps only its shared helpers", "track": "main", "actor": "agent", "from": "not_started", "to": "in_progress"}
+{"ts": "2026-08-31T21:01:37+08:00", "event": "ask", "id": "USER-910", "title": "perry-migrate cannot survive Tier A — its output IS the deleted ledger (C.declare, 14 sites). A: delete migration too (0 records ever carried route:migrate; TASK-097 never started) — recommended. B: restore ~200 ledger lines for migrate alone, keep the write-path gate deleted, make TASK-097 the next phase. Full form: evidence/2026-08/2026-08-31-TASK-261-migration-fork.md", "asked": "2026-08-31", "blocks": "TASK-261", "actor": "agent", "from": null, "to": "pending"}
+{"ts": "2026-08-31T21:01:44+08:00", "event": "status", "id": "TASK-261", "title": "Tier A — the ADR-004 declaration gate comes out; perry-conform keeps only its shared helpers", "track": "main", "actor": "agent", "depends_on": ["USER-910"], "from": "in_progress", "to": "blocked", "reason": "migration fork: perry-migrate's output is the deleted ledger"}
+{"ts": "2026-08-31T21:13:25+08:00", "event": "answer", "id": "USER-910", "title": "perry-migrate cannot survive Tier A — its output IS the deleted ledger (C.declare, 14 sites). A: delete migration too (0 records ever carried route:migrate; TASK-097 never started) — recommended. B: restore ~200 ledger lines for migrate alone, keep the write-path gate deleted, make TASK-097 the next phase. Full form: evidence/2026-08/2026-08-31-TASK-261-migration-fork.md", "answer": "A — delete migration too. perry-migrate, perry_schema.py and test_migrate.py are out; TASK-097 drops with them.", "actor": "agent", "from": "pending", "to": "answered"}
+{"ts": "2026-08-31T21:13:25+08:00", "event": "drop", "id": "TASK-097", "title": "Migrate the two real projects to the store, at V5", "track": "main", "owner": "Coding Agent", "role": "", "stage": "", "actor": "agent", "from": "not_started", "to": "dropped", "reason": "the ADR-004 gate and perry-migrate are deleted (TASK-261, USER-910 answered A); this row is about a subsystem that no longer exists"}
+{"ts": "2026-08-31T21:13:26+08:00", "event": "drop", "id": "TASK-223", "title": "the conformance gate cannot tell a file Perry generated from one it found, so authored files need a hand declare", "track": "main", "owner": "Coding Agent", "role": "", "stage": "", "actor": "agent", "from": "not_started", "to": "dropped", "reason": "the ADR-004 gate and perry-migrate are deleted (TASK-261, USER-910 answered A); this row is about a subsystem that no longer exists"}
+{"ts": "2026-08-31T21:13:26+08:00", "event": "drop", "id": "TASK-246", "title": "an unreadable row in .perry/conformance.md is now DELETED by the next declare, not laundered", "track": "main", "owner": "Coding Agent", "role": "", "stage": "", "actor": "agent", "from": "not_started", "to": "dropped", "reason": "the ADR-004 gate and perry-migrate are deleted (TASK-261, USER-910 answered A); this row is about a subsystem that no longer exists"}
+{"ts": "2026-08-31T21:13:26+08:00", "event": "drop", "id": "TASK-248", "title": "a canonical row inside <pre>, an HTML comment, or <details> still declares a file conformant, and is still laundered", "track": "main", "owner": "Coding Agent", "role": "", "stage": "", "actor": "agent", "from": "not_started", "to": "dropped", "reason": "the ADR-004 gate and perry-migrate are deleted (TASK-261, USER-910 answered A); this row is about a subsystem that no longer exists"}
+{"ts": "2026-08-31T22:02:17+08:00", "event": "done", "id": "TASK-261", "title": "Tier A — the ADR-004 declaration gate comes out; perry-conform keeps only its shared helpers", "track": "main", "owner": "Coding Agent", "role": "", "actor": "agent", "from": "blocked", "to": "done", "evidence": "6ce1f5b, 436d0fb; evidence/2026-08/2026-08-31-TASK-261-migration-fork.md", "rung": "V3"}

README.md

@@ -87,7 +87,7 @@ Don't start from a blank page — Perry can read what's already there:
 
 It reads your README, roadmap, git history, existing design notes, TODOs and issues, then **proposes** goals, tasks and decisions. Nothing is written until you say yes.
 
-**Adoption is a migration, and it is meant to happen once.** Perry used to adapt at runtime to whatever shape your files were already in, and that tolerance is where its bugs lived — two branches guessing differently about the same table and quietly losing a row between them. So it was traded away on purpose ([ADR-004](perry/decisions/ADR-004-mandatory-migration.md)). The rule now: **a project migrates to Perry's structure in order to use Perry's write features, and a project that will not migrate stays readable rather than drivable.**
+**Adoption writes Perry's own state, once.** Perry used to adapt at runtime to whatever shape your files were already in, and that tolerance is where its bugs lived — two branches guessing differently about the same table and quietly losing a row between them. So it was traded away on purpose ([ADR-004](perry/decisions/ADR-004-mandatory-migration.md)). The rule now: **`/perry adopt` reads what you already have as evidence and writes Perry's structure from it; it never rewrites your files in place.** ADR-004 also made every writer refuse a file nobody had declared conformant. That gate is deleted (`TASK-261`) — in 23 declarations it never once disagreed with the live check, so nothing now refuses a write for want of a declaration.
 
 Readable is not the consolation prize. `/perry diagnose` runs on any folder at all, and reading an unmigrated project is exactly how you decide whether to migrate it. And the migration owes you four things: the complete diff before anything is written, no lost rows or IDs, a restore point, and no step you did not ask for.
 
@@ -316,7 +316,7 @@ Any language works for prose. Details, and how to switch later: [reference/i18n.
 
 **Can I use it for non-code projects?** Yes — research, writing, ops, business planning. Those are not a bolt-on: they are the [four modes](#four-kinds-of-work), each with its own horizon, throttle and triage. `/perry diagnose` recognises them from what's on your board.
 
-**Can Perry drive the board I already have?** Only after `/perry adopt` migrates it. Perry stopped bending at runtime to arbitrary file shapes ([ADR-004](perry/decisions/ADR-004-mandatory-migration.md)) — that flexibility was where its data-losing bugs came from. An unmigrated project stays readable and diagnosable; it is just not driven.
+**Can Perry drive the board I already have?** Not in place. `/perry adopt` reads it as evidence and writes Perry's own state alongside; Perry then drives that. Perry stopped bending at runtime to arbitrary file shapes ([ADR-004](perry/decisions/ADR-004-mandatory-migration.md)) — that flexibility was where its data-losing bugs came from. A project Perry has not adopted stays readable and diagnosable; it is just not driven.
 
 **What if my project already has a `design/` folder?** Nothing collides — Perry's own files live under `perry/` by default, so your `design/` stays yours. Setup checks for the collision before it writes anything, and only asks if you tell it to use the project root instead.
 

README_cn.md

@@ -89,7 +89,7 @@ git clone https://github.com/ranjiao/Perry.git ~/perry && ~/perry/setup
 
 它会读你的 README、路线图、git 历史、已有的设计笔记、TODO 和 issue，然后**提议**目标、任务和决策。你不点头，它什么都不写。
 
-**adopt 是一次迁移，只做一次。** 以前 Perry 会在运行时迁就你原有的文件格式。它的 bug 大多出在这里：两处代码对同一张表的读法不一致，中间悄悄丢掉一行。所以这份灵活性被有意放弃了，理由记在 [ADR-004](perry/decisions/ADR-004-mandatory-migration.md)。现在的规矩是：**要用 Perry 的写入能力，项目就得先迁到 Perry 的结构；不迁的项目仍然可读，但 Perry 不会去驱动它。**
+**adopt 写出 Perry 自己的状态，只做一次。** 以前 Perry 会在运行时迁就你原有的文件格式。它的 bug 大多出在这里：两处代码对同一张表的读法不一致，中间悄悄丢掉一行。所以这份灵活性被有意放弃了，理由记在 [ADR-004](perry/decisions/ADR-004-mandatory-migration.md)。现在的规矩是：**`/perry adopt` 把你已有的东西当证据读，据此写出 Perry 的结构；它不会就地改写你的文件。** ADR-004 当初还让每个写工具拒绝未被声明合规的文件，那道门禁已经删除（`TASK-261`）—— 23 次声明里它一次都没和实时检查产生过分歧，现在没有任何写入会因为缺一份声明被拒。
 
 「可读」不是安慰奖。`/perry diagnose` 在任何目录上都能跑，而读一个没迁移的项目，恰恰是你判断该不该迁的依据。迁移本身欠你四件事：动手之前先给出完整 diff、不丢任何一行和任何一个 ID、留一个可回退的还原点、以及绝不做你没让它做的事。
 
@@ -318,7 +318,7 @@ Perry 本身是英文写的，你的项目不必是。首次配置时它会记
 
 **能用在非代码项目上吗？** 能 —— 研究、写作、运维、业务规划都行。这不是外挂上去的：它们就是[四种 mode](#四种工作形态)，各有各的收尾条件、节奏控制和 triage 问法。`/perry diagnose` 会从你板子上的样子把它们认出来。
 
-**Perry 能直接驱动我现有的板子吗？** 得先用 `/perry adopt` 迁一次。Perry 已经不再在运行时迁就任意文件格式了（[ADR-004](perry/decisions/ADR-004-mandatory-migration.md)）—— 那份灵活性正是它丢数据的那类 bug 的来源。没迁的项目仍然可读、可以 diagnose，只是不被驱动。
+**Perry 能直接驱动我现有的板子吗？** 不是就地驱动。`/perry adopt` 把它当证据读，在旁边写出 Perry 自己的状态，之后 Perry 驱动的是后者。Perry 已经不再在运行时迁就任意文件格式了（[ADR-004](perry/decisions/ADR-004-mandatory-migration.md)）—— 那份灵活性正是它丢数据的那类 bug 的来源。没被 adopt 过的项目仍然可读、可以 diagnose，只是不被驱动。
 
 **我的项目已经有** **`design/`** **目录了怎么办？** 不会撞上 —— Perry 自己的文件默认就在 `perry/` 下面，你的 `design/` 还是你的。setup 在写任何东西之前先查一遍冲突，只有你坚持要用项目根目录时它才会问。