docs: design revision escalation execution gate

Author: yha9806

docs/product/lost-in-conversation-writing-control-design.md

@@ -127,12 +127,40 @@ If any of these occur during the bench run, the outcome should be recorded as a
 
 ### Revision Escalation
 
-Three unsuccessful attempts against the same edit contract are an operational stop threshold, not a research claim that every task fails after three turns. Only author rejection or a `revise` or `rollback` drift decision counts as an unsuccessful attempt; clarification and unexecuted proposals do not count. At that point the workflow must not apply a fourth prose patch.
+Three unsuccessful attempts against the same revision issue are an operational stop threshold, not a research claim that every task fails after three turns. Contract versions remain in the same issue family through `revision_issue_id`. Only author rejection or a `revise` or `rollback` drift decision counts as an unsuccessful attempt; clarification and unexecuted proposals do not count. At that point the workflow must not apply a fourth prose patch.
 
 The workflow may escalate earlier when claim drift, an evidence gap, an unclear spine, loss of the latest author-approved version, or version contamination is already visible. Before any further edit, it consolidates the valid requirements, compares them with the control packet and approved source, classifies the problem, and asks the author to approve the next action.
 
 The diagnosis separates underspecified or conflicting intent, local execution failure, structural mismatch, evidence gap, and version contamination. It also distinguishes a local patch, section-level restructure, and full reframing. A new branch or manuscript version is an isolation mechanism for approved structural work, not a substitute for repairing an unclear specification.
 
+### Revision Escalation Execution Layer
+
+The instruction rule is not sufficient on its own. Strict thesis-control packets must make revision attempts and escalation approval structurally inspectable.
+
+`edit_contracts.csv` adds two fields:
+
+- `revision_issue_id` groups multiple contract versions that address the same unresolved writing problem;
+- `attempt_no` is a positive, unique, sequential number within that issue.
+
+An unsuccessful attempt is one contract whose audit decision is `revise` or `rollback`. Author rejection must be recorded as one of those two decisions so the outcome is durable and countable. Multiple audits for one contract still count as one attempt.
+
+`revision_escalations.csv` records:
+
+```text
+escalation_id,revision_issue_id,trigger_contracts,primary_category,writing_scope,valid_requirements,missing_or_conflicting_information,latest_author_approved_version,recommended_next_action,human_approved,status
+```
+
+The execution gate is:
+
+1. Find the first three unsuccessful contracts in one `revision_issue_id` family.
+2. Require a revision-escalation row that references those trigger contracts.
+3. Permit draft planning, but reject any later contract marked `approved` or `applied` until a matching escalation row has `human_approved=true` and `status=approved`.
+4. Keep early escalation available with fewer than three trigger contracts; it does not weaken the three-strike gate.
+
+The checker remains structural. It can verify identities, attempt order, audit outcomes, escalation linkage, and human approval. It cannot decide whether feedback is semantically ambiguous, whether evidence is academically sufficient, or whether a full reframing is intellectually correct.
+
+For compatibility, non-strict checking continues to accept legacy packets without revision-tracking columns. Strict checking requires the new fields and escalation file. A local migration helper adds the new schema without guessing historical issue relationships: each legacy contract starts as its own issue and authors may explicitly regroup known revision families.
+
 ## Acceptance Criteria
 
 The design is ready for implementation planning when:

docs/product/lost-in-conversation-writing-control-implementation-plan.md

@@ -10,7 +10,39 @@
 
 **Current extension:** The initial single-case fixture has been expanded into a three-case fixture. `scripts/check_lost_in_conversation_bench.py` validates the root case plus `cases/*`, T73 runs strict `/thesis-control` validation for every case treatment packet, and T74 requires the skill to stop and diagnose repeated revisions instead of applying a fourth prose patch.
 
-**Revision escalation architecture:** Keep revision escalation inside `/thesis-control`. The skill counts unsuccessful outcomes against the same edit contract, stops after three, allows earlier escalation for high-risk control failures, and routes the author to a corrected local contract, section restructure, evidence-boundary decision, approved-version restore, or full reframing. The structural validator remains unchanged because it cannot judge semantic convergence.
+**Revision escalation architecture:** Keep revision escalation inside `/thesis-control`. The skill groups unsuccessful contract versions under one revision issue, stops after three, allows earlier escalation for high-risk control failures, and routes the author to a corrected local contract, section restructure, evidence-boundary decision, approved-version restore, or full reframing. The validator enforces structural attempt and approval gates without claiming to judge semantic convergence.
+
+**Execution-layer extension:** Track one unresolved problem across contract versions with `revision_issue_id` and `attempt_no`. Add `revision_escalations.csv` as the durable diagnosis and author-approval record. Strict validation must require an escalation record after three unsuccessful contracts and must reject a later `approved` or `applied` contract until the escalation is human-approved. Non-strict validation remains compatible with legacy packets.
+
+## Revision Escalation Execution Extension
+
+### File Map
+
+- Modify `.claude/skills/thesis-control/scripts/check_thesis_control.py`: validate revision families, attempts, escalation records, and the fourth-edit gate.
+- Modify `.claude/skills/thesis-control/scripts/scaffold_thesis_control.py`: emit revision identity fields and an empty escalation CSV.
+- Create `.claude/skills/thesis-control/scripts/upgrade_thesis_control_revision_tracking.py`: upgrade legacy packets without inferring historical revision families.
+- Modify `.claude/skills/thesis-control/SKILL.md`: document durable attempt recording and the strict checker gate.
+- Modify `scripts/test.sh`: add red-green tests for schema requirements, blocking, approval, scaffold output, and legacy migration.
+- Modify `examples/lost-in-conversation-bench/**/thesis_control/*.csv`: move all strict public fixtures to the revision-tracking schema.
+- Regenerate `plugins/academic-writing-toolkit/skills/thesis-control/` with `make plugin-sync`.
+
+### Checker Contract
+
+- A revision issue id is a safe identifier shared by contracts for the same unresolved problem.
+- Attempt numbers are positive, unique, and sequential within one issue.
+- A contract counts as unsuccessful once when any linked audit decides `revise` or `rollback`.
+- Three unsuccessful contracts require a linked escalation row.
+- A later draft or rejected contract is inspectable, but a later approved or applied contract requires a matching human-approved escalation.
+- An approved escalation must reference the first three unsuccessful contracts in `trigger_contracts`.
+
+### Test Sequence
+
+1. Add T75 and verify strict validation rejects a fourth applied contract without escalation.
+2. Add T76 and verify a correctly linked, human-approved escalation permits the fourth contract.
+3. Add T77 and verify malformed attempt families and escalation references fail.
+4. Add T78 and verify the scaffold emits revision identity plus the escalation header.
+5. Add T79 and verify the migration helper preserves legacy rows while adding isolated issue identities.
+6. Run `make plugin-sync`, `make test`, public-content audit, and `git diff --check`.
 
 ---