@litfamily/litopencode 1.0.0

package/skills/autoresearch/modes/reason.md

@@ -0,0 +1,170 @@
+---
+name: autoresearch:reason
+description: |
+  Adversarial multi-round reasoning with blind-judge panel to reach rigorous conclusions.
+  TRIGGER when: user wants rigorous reasoning or argument evaluation; user wants a decision
+  analyzed from multiple angles; user wants devil's advocate critique; user asks "what are
+  the strongest arguments for/against"; user wants a structured debate; user wants to avoid
+  groupthink or anchoring; user invokes /autoresearch-reason.
+  DO NOT TRIGGER when: user wants a simple recommendation; user wants a quick summary;
+  user wants factual lookup; user just wants pros/cons without adversarial pressure.
+allowed-tools:
+  - Read
+  - Write
+  - Edit
+  - Bash
+  - WebFetch
+  - WebSearch
+---
+
+# autoresearch:reason
+
+## OpenCode authority envelope
+
+This document is inert guidance. `lit-plan` must approve the question, evidence policy, finite budget,
+canonical roots, output write set, rollback policy, and review gate before any mutation, including an
+interactive run. Only explicit `/start-work` may perform bounded writes, commands, evaluation, or
+reversion within that packet; without it this mode remains read-only.
+
+Adversarial multi-round reasoning loop with a blind-judge panel. Arguments are assigned
+crypto-random IDs before critique so judges evaluate logic, not author identity. Runs until
+convergence or budget exhausted.
+
+## Autonomy Directive
+
+**You are an autonomous reasoning agent.** Once the debate begins:
+
+1. **NEVER STOP** to ask permission between rounds.
+2. Continue without another prompt only within the approved round budget and current `/start-work`
+   packet; stop when the packet cannot authorize the next output action.
+3. **NEVER DECLARE CONVERGENCE** prematurely — a single unchallenged round is not convergence.
+4. **The loop runs until:** all positions converge OR budget exhausted OR user interrupts.
+5. **If neither condition is true, begin the next round immediately.**
+
+---
+
+## Setup
+
+### Step 1 — Define the question
+If not provided, ask once: "What is the question or decision to reason about?"
+The question must be specific enough to allow falsifiable positions. Refuse vague inputs like
+"think about AI" — ask for a concrete framing.
+
+### Step 2 — Set parameters
+Ask if not provided:
+- **Number of positions** (default: 3). Minimum 2, maximum 5.
+- **Max rounds** (default: 4). Minimum 2.
+- **Convergence threshold:** "Converged" = all judges rate the top position's logical score ≥8/10
+  AND no position has an unanswered rebuttal.
+
+---
+
+## Round Structure
+
+Each round follows this exact sequence:
+
+### Phase 1 — Propose Positions (Round 1 only)
+Generate N distinct positions on the question. Positions must:
+- Be mutually distinguishable (not minor variations of each other)
+- Be stated as falsifiable claims, not vague preferences
+- Cover the genuine range of defensible views (not strawmen)
+
+Write each position to `reason/rounds.md` as: `Position [PENDING-ID]: [statement]`
+
+### Phase 2 — Assign Crypto-Random IDs
+Assign each position a random alphanumeric ID (e.g., `ARG-7F3A`, `ARG-2C91`).
+Write the mapping to `reason/id-map.md` — this file is **sealed until the end** (not read during debate).
+Replace all position labels in `reason/rounds.md` with their assigned IDs.
+**From this point forward, all debate references use IDs only — never "Position 1" or author names.**
+
+### Phase 3 — Blind Critique Round
+For each argument ID, write a rigorous critique:
+- Identify the strongest assumption and test whether it holds
+- Find the weakest logical link in the chain
+- Propose a concrete counterexample or falsifying scenario
+- Rate logical strength: 1–10 (where 10 = logically airtight)
+
+Critiques reference IDs only: "ARG-7F3A assumes X, which fails when Y..."
+Write all critiques to `reason/rounds.md` under `## Round [N] — Critiques`.
+
+### Phase 4 — Rebuttal Round
+Each argument ID responds to the critiques it received:
+- Acknowledge valid critiques (update or narrow the claim)
+- Rebut invalid critiques with specific evidence or reasoning
+- A position may concede partially — update the statement if weakened by critique
+
+Write rebuttals to `reason/rounds.md` under `## Round [N] — Rebuttals`.
+
+### Phase 5 — Judge Evaluation
+Three independent judges evaluate all arguments:
+- Judge A: Logic and internal consistency
+- Judge B: Evidence quality and falsifiability
+- Judge C: Practical applicability
+
+Each judge scores every argument ID on their dimension (1–10) and identifies the strongest argument.
+Judges reference IDs only. Write scores to `reason/rounds.md` under `## Round [N] — Judgment`.
+
+### Phase 6 — Convergence Check
+After each round:
+- If top-scoring argument has score ≥8/10 from all judges AND no unanswered rebuttal exists → converged.
+- If max rounds reached → converged by budget.
+- Otherwise → begin next round (return to Phase 3 with updated positions).
+
+---
+
+## Output Files
+
+All output goes to a `reason/` folder in the working directory.
+
+| File | Purpose |
+|------|---------|
+| `reason/rounds.md` | Per-round arguments, critiques, rebuttals, and scores (IDs only during debate) |
+| `reason/verdict.md` | Final synthesis: winning argument with reasoning, minority positions summarized |
+| `reason/id-map.md` | Revealed at end only: maps each ID → original position label |
+
+### verdict.md structure
+```
+# Verdict: [Question]
+Rounds completed: [N]
+Convergence: [yes/no — budget exhausted]
+
+## Winning Argument
+ID: [ARG-XXXX] (revealed: [original position])
+Score: [avg judge score]/10
+Summary: [2-3 sentence synthesis]
+Key evidence: [bullet points]
+
+## Minority Positions
+- [ARG-YYYY]: [why it lost — specific logical weakness identified]
+- [ARG-ZZZZ]: [why it lost]
+
+## Synthesis
+[2-3 paragraphs on what the debate revealed — including any nuances that
+don't fit cleanly into the winning argument]
+
+## Confidence
+[Low / Medium / High] — with explicit statement of remaining uncertainty
+```
+
+---
+
+## Anti-Anchoring Protocol
+
+The ID system exists to prevent these failure modes:
+- **Position ordering bias** — "the first argument always sounds best"
+- **Framing bias** — "the argument labeled 'conservative' gets dismissed without evaluation"
+- **Authority bias** — "the argument by the named expert wins by default"
+
+Judges MUST NOT reference position order, original labels, or authorship until after `verdict.md` is written and `id-map.md` is revealed.
+
+---
+
+## Edge Cases
+
+| Situation | Handling |
+|-----------|----------|
+| Two positions are identical | Merge them; reduce N by 1 |
+| One position dominates all others in round 1 | Still run min 2 rounds — premature convergence is bias |
+| Judges disagree strongly (spread ≥5 points) | Note as "contested" in verdict.md — no forced winner |
+| Budget = 1 round | Complete one full cycle, write verdict with low confidence |
+| Question has a factual answer | Note this upfront — reason is for judgment calls, not facts |

package/skills/autoresearch/modes/scenario.md

@@ -0,0 +1,164 @@
+---
+name: autoresearch:scenario
+description: |
+  12-dimension scenario exploration across user-specified domain modes.
+  TRIGGER when: user wants to explore scenarios, edge cases, or what-if analysis;
+  user asks "what could go wrong"; user wants failure mode analysis; user asks about
+  best/worst case outcomes; user wants to stress-test a plan, design, or system;
+  user mentions "scenario analysis" or "scenario planning";
+  user invokes /autoresearch-scenario.
+  DO NOT TRIGGER when: user wants a one-shot answer; user wants a simple pros/cons list;
+  user just wants debugging help; user wants iterative optimization.
+allowed-tools:
+  - Read
+  - Write
+  - Edit
+  - Bash
+  - WebFetch
+  - WebSearch
+---
+
+# autoresearch:scenario
+
+## OpenCode authority envelope
+
+This document is inert guidance. `lit-plan` must approve the subject, dimensions, finite budget,
+canonical roots, output write set, rollback policy, and review gate before any mutation, including an
+interactive run. Only explicit `/start-work` may perform bounded writes, commands, evaluation, or
+reversion within that packet; without it this mode remains read-only.
+
+Systematic scenario exploration across 12 dimensions and up to 5 domain modes.
+Ensures every meaningful angle — from best case to adversarial to long-term drift — is covered before declaring analysis complete.
+
+## Autonomy Directive
+
+**You are an autonomous scenario analysis agent.** Once the loop begins:
+
+1. **NEVER STOP** to ask for permission mid-analysis. The user may be asleep.
+2. Continue without another prompt only within the approved dimension and output budget; an
+   interactive run follows the same `/start-work` boundary as an unattended run.
+3. **NEVER SUMMARIZE AND WAIT.** After completing a dimension × domain cell, move to the next immediately.
+4. **The loop runs until:** all applicable dimension × domain cells are covered, or budget exhausted.
+5. **If neither condition is true, begin the next cell NOW.**
+
+---
+
+## Setup
+
+### Step 1 — Identify the subject
+If the user has not provided a clear subject (system, plan, design, decision), ask once:
+"What is the subject of this scenario analysis?" Do not proceed until answered.
+
+### Step 2 — Select domain modes
+Ask (if not already specified): "Which domain modes apply? Select all that apply:
+(1) technical, (2) business, (3) social, (4) regulatory, (5) environmental"
+
+Record the applicable modes. All 12 dimensions will be explored for each selected mode.
+
+### Step 3 — Set budget
+Default: cover all dimension × domain cells (12 × N modes). If the user specifies a budget
+(e.g., "top 6 dimensions only"), honor it — prioritize dimensions in order 1–12.
+
+---
+
+## The 12 Dimensions
+
+All dimensions are defined in `references/scenario-dimensions.md`. Quick reference:
+
+| # | Dimension | Core question |
+|---|-----------|---------------|
+| 1 | Best case | What if everything goes right? |
+| 2 | Worst case | What if everything goes wrong? |
+| 3 | Most likely | What does the realistic outcome look like? |
+| 4 | Edge case | What breaks at the boundaries? |
+| 5 | Cascade failure | What systemic chain reaction is possible? |
+| 6 | Adversarial | What if a motivated actor exploits this? |
+| 7 | Time-compressed | What happens under extreme time pressure? |
+| 8 | Resource-constrained | What if key resources are cut by 50–90%? |
+| 9 | Stakeholder conflict | What if stakeholders have opposing goals? |
+| 10 | Regulatory/compliance | What if rules change or are enforced strictly? |
+| 11 | Long-term drift | What does degradation look like over 1–5 years? |
+| 12 | Recovery/resilience | How does the system recover after failure? |
+
+---
+
+## Balanced Rotation Loop
+
+The core loop ensures no dimension or domain mode is skipped or over-represented.
+
+```
+coverage_map = {dim: {mode: False for mode in applicable_modes} for dim in 1..12}
+
+while uncovered_cells exist and budget not exhausted:
+    1. Find the dimension with the fewest covered modes (least-recently-covered first)
+    2. Within that dimension, pick the first uncovered mode
+    3. Analyze that (dimension, mode) cell:
+       a. Load the dimension's questions from dimensions.md
+       b. Apply them through the lens of the selected domain mode
+       c. Write findings to scenario-report.md (see Output section)
+    4. Mark cell as covered in coverage_map
+    5. If all cells for this dimension × all modes are done, mark dimension complete
+    6. Continue to next cell immediately
+```
+
+Tie-breaking when multiple dimensions have equal coverage: lower dimension number goes first.
+
+---
+
+## Output
+
+All output goes to `scenario-report.md` in the working directory.
+
+### scenario-report.md structure
+
+```
+# Scenario Report: [Subject]
+Generated: [date]
+Dimensions covered: [N]/12
+Domain modes: [list]
+
+---
+
+## Dimension 1: Best Case
+### Technical
+[findings]
+### Business
+[findings]
+...
+
+## Dimension 2: Worst Case
+...
+
+## Summary Table
+| Dimension | Technical | Business | Social | Regulatory | Environmental |
+|-----------|-----------|----------|--------|------------|---------------|
+| 1. Best case | covered | covered | N/A | covered | N/A |
+...
+
+## Key Risks Identified
+[Top 5 risks ranked by severity × likelihood]
+
+## Recommended Actions
+[Concrete actions implied by the scenario analysis]
+```
+
+Write `scenario-report.md` incrementally — append each cell as it completes. Do not wait until all cells are done to write.
+
+---
+
+## Termination Conditions
+
+1. All applicable dimension × domain cells covered → write summary table + key risks + recommended actions → done.
+2. Budget exhausted (user-specified limit) → write partial summary noting which cells remain → done.
+3. User manually interrupts → flush current cell to file → done.
+
+---
+
+## Edge Cases
+
+| Situation | Handling |
+|-----------|----------|
+| Only 1 domain mode selected | Run all 12 dimensions for that mode |
+| Subject is ambiguous | Ask once to clarify, then proceed |
+| A dimension is clearly not applicable | Note "N/A — [reason]" and move on |
+| Budget = 0 or subject refused | Abort with clear message |

package/skills/autoresearch/modes/security.md

@@ -0,0 +1,282 @@
+---
+name: autoresearch:security
+description: |
+  Iterative security audit engine. Performs STRIDE threat modeling, OWASP
+  Top-10 checks, attack surface mapping, and mitigation proposals. Loops
+  until coverage target is reached or budget is exhausted.
+  TRIGGER when: user wants a security audit, threat model, vulnerability
+  assessment, penetration test review, "is this secure", "what are the
+  threats", STRIDE analysis, OWASP check, or security posture review.
+allowed-tools:
+  - Read
+  - Write
+  - Edit
+  - Bash
+  - WebFetch
+  - WebSearch
+---
+
+# Security Audit: Iterative Threat Modeling Engine
+
+## OpenCode authority envelope
+
+This document is inert guidance. `lit-plan` must approve the assessment target, probe policy, finite
+budget, canonical roots, output write set, rollback policy, and review gate before any mutation,
+including an interactive run. Only explicit `/start-work` may perform bounded writes, commands,
+evaluation, or reversion within that packet; without it this mode remains read-only.
+
+An autonomous security audit that applies structured threat modeling (STRIDE), OWASP Top-10 checks, and attack surface mapping. Iterates until coverage >= target or budget is exhausted. Produces a `security/` folder with actionable outputs.
+
+## Autonomy Directive
+
+**You are an autonomous security auditor.** Once the audit begins:
+
+1. **NEVER STOP** between phases to ask permission.
+2. **NEVER skip a STRIDE category** because it seems unlikely — every category must be checked.
+3. **NEVER mark coverage as complete** without running the re-audit phase.
+4. **Loop until coverage >= target (default 80) or iterations exhausted.**
+
+## Pre-Flight Setup
+
+Before starting, establish scope:
+
+1. **Ask (if not already specified):** "What is the target? (codebase path, system description, architecture diagram, or specific component)"
+2. **Ask:** "What is the coverage target? (default: 80)"
+3. **Ask:** "Is this a re-audit with `--diff` flag? If so, provide the previous `security/` folder."
+4. **Detect:** Can you read code directly (Bash/Read available)? → Tier 1 (code audit). Web access only? → Tier 2 (architecture review). Neither? → Tier 3 (description-based).
+
+**Do NOT start Phase 1 until scope is defined.**
+
+## The 7-Phase Iterative Audit
+
+```
+[Scope] --> [Asset Inventory] --> [STRIDE Modeling] --> [OWASP Check]
+    --> [Attack Surface Mapping] --> [Mitigation Proposals]
+    --> [Coverage Scoring] --> [Re-audit if needed]
+```
+
+---
+
+### Phase 1 — Scope Definition
+
+Define precisely what is being audited:
+
+- **In scope:** Specific files, services, APIs, data flows, trust boundaries
+- **Out of scope:** Third-party dependencies (unless their integration is being audited), infrastructure not owned by the team
+- **Threat actors:** Who might attack this? (external attacker, malicious insider, compromised dependency, unauthenticated user)
+- **Security objectives:** Confidentiality, Integrity, Availability — which matter most for this system?
+- **Compliance context:** Any relevant standards (PCI-DSS, HIPAA, SOC2, GDPR) that constrain mitigations?
+
+Log to `security/threats.md` under `## Scope`.
+
+---
+
+### Phase 2 — Asset Inventory
+
+Enumerate what exists in the system:
+
+- **Data assets:** What sensitive data is stored, transmitted, or processed? (PII, credentials, tokens, financial data)
+- **Entry points:** All places where external input reaches the system (HTTP endpoints, CLI args, file uploads, message queues, webhooks)
+- **Trust boundaries:** Where does the system trust a caller it shouldn't blindly trust?
+- **External dependencies:** Third-party services, libraries, APIs that the system relies on
+- **Authentication surfaces:** All places where identity is verified or assumed
+
+For Tier 1, scan the codebase:
+```bash
+# Find entry points
+grep -r "app.get\|app.post\|router\|@Controller\|@Route\|def.*view\|def.*api" --include="*.py,*.js,*.ts,*.java,*.go" -l
+# Find credential handling
+grep -r "password\|secret\|token\|key\|auth" --include="*.py,*.js,*.ts" -l
+```
+
+Log to `security/threats.md` under `## Asset Inventory`.
+
+---
+
+### Phase 3 — STRIDE Threat Modeling
+
+Read `stride-model.md` for full category definitions, examples, and standard mitigations.
+
+For each of the 6 STRIDE categories, systematically apply it to every entry point and trust boundary identified in Phase 2:
+
+**For each threat found:**
+```
+Threat ID: T-[category]-[sequence] (e.g., T-S-001, T-T-002)
+Category: [STRIDE letter]
+Target: [which asset or entry point]
+Description: [specific attack scenario]
+Severity: Critical / High / Medium / Low
+Likelihood: High / Medium / Low
+Evidence: [code reference or architectural reason]
+```
+
+**Severity × Likelihood matrix:**
+
+| | High Likelihood | Medium Likelihood | Low Likelihood |
+|---|---|---|---|
+| **Critical impact** | P0 | P1 | P2 |
+| **High impact** | P1 | P2 | P3 |
+| **Medium impact** | P2 | P3 | P4 |
+
+Log all identified threats to `security/threats.md` under `## STRIDE Threats`.
+
+---
+
+### Phase 4 — OWASP Top-10 Check
+
+Read `owasp-checklist.md` for the full checklist per category.
+
+For each of the 10 OWASP 2021 categories, check whether the system is vulnerable:
+
+**Check result format:**
+```
+[Category]: PASS / FAIL / PARTIAL / N/A
+Evidence: [code reference or architectural note]
+Severity: [if FAIL/PARTIAL]
+```
+
+**Coverage rule:** A category is PASS only if all check items from `owasp-checklist.md` are verified. PARTIAL means some items pass, some couldn't be verified. N/A means the category is structurally inapplicable (e.g., A09 Logging for a stateless function with no logs needed).
+
+Log results to `security/threats.md` under `## OWASP Top-10 Results`.
+
+---
+
+### Phase 5 — Attack Surface Mapping
+
+Synthesize findings from Phases 3–4 into an attack surface map:
+
+- **High-value targets:** Assets that appear in multiple threats (concentrated risk)
+- **Attack chains:** Sequences where one vulnerability enables another (e.g., SSRF → credential theft → privilege escalation)
+- **Unprotected perimeter:** Entry points with no authentication or validation
+- **Data exfiltration paths:** How could an attacker extract sensitive data?
+- **Blast radius:** If a specific component is compromised, what else is at risk?
+
+Log to `security/threats.md` under `## Attack Surface Map`.
+
+---
+
+### Phase 6 — Mitigation Proposals
+
+For each threat from Phase 3 + each FAIL/PARTIAL from Phase 4, propose a concrete mitigation:
+
+**Mitigation format:**
+```
+Mitigation ID: M-[ThreatID]
+Threat addressed: [T-xxx or OWASP category]
+Proposal: [Specific code change, configuration, or architecture change]
+Implementation effort: Low (< 1 day) / Medium (1–5 days) / High (> 5 days)
+Status: proposed / in-progress / implemented / accepted-risk / wont-fix
+```
+
+**Prioritization:** P0/P1 threats must have mitigations. P2+ threats should have mitigations but may be deferred.
+
+**Mitigation types:**
+- Code change (input validation, parameterized queries, etc.)
+- Configuration change (CORS policy, security headers, TLS enforcement)
+- Architecture change (add authentication layer, separate privilege domains)
+- Monitoring/detection (log anomalies, rate limiting, alerting)
+- Accepted risk (document why the threat is tolerated)
+
+Log to `security/mitigations.md`.
+
+---
+
+### Phase 7 — Coverage Scoring & Re-Audit
+
+**Coverage metric:**
+
+```
+coverage = (threats_addressed / threats_identified) × 100
+
+Where:
+  threats_identified = all STRIDE threats + all OWASP FAIL/PARTIAL findings
+  threats_addressed  = findings with mitigation status NOT 'proposed'
+                       (i.e., implemented, accepted-risk, or wont-fix with justification)
+```
+
+**At the end of each iteration:**
+1. Calculate current coverage score.
+2. Write `security/coverage-report.md` with score + gap analysis.
+3. If `coverage >= target` → audit complete, produce final summary.
+4. If `coverage < target` AND budget not exhausted → begin re-audit pass.
+
+**Re-audit pass:** Focus on the highest-severity unaddressed threats. Propose additional mitigations or refine existing ones. Increment the pass counter.
+
+---
+
+## Re-Audit with --diff Flag
+
+When called with `--diff`, only audit what changed since the last audit:
+
+1. Load `security/threats.md` and `security/mitigations.md` from the previous run.
+2. Identify changed files (via `git diff --name-only` or user-provided diff).
+3. Re-check only STRIDE threats and OWASP items that touch changed files.
+4. Update threat/mitigation records. Do NOT re-check unchanged components.
+5. Recalculate coverage score.
+
+**--diff skips:** All STRIDE categories for unchanged components, all OWASP checks for unaffected code paths.
+
+---
+
+## Coverage Report Format
+
+`security/coverage-report.md`:
+
+```markdown
+# Security Coverage Report
+Date: [ISO date]
+Pass: [N]
+Target: [80]%
+Current Coverage: [X]%
+
+## Score Breakdown
+- Threats identified: [N]
+- Threats addressed: [M]
+- Coverage: [X]%
+
+## Status
+[PASS: Target achieved] / [IN PROGRESS: X% of target]
+
+## Unaddressed Threats (Gaps)
+| Threat ID | Severity | Description | Blocker |
+|-----------|----------|-------------|---------|
+
+## Addressed Threats Summary
+| Threat ID | Severity | Mitigation | Status |
+|-----------|----------|------------|--------|
+
+## Accepted Risks
+[List of threats with accepted-risk status and justification]
+```
+
+---
+
+## Output Structure
+
+| File | Updated | Purpose |
+|------|---------|---------|
+| `security/threats.md` | Each phase | All identified threats (STRIDE + OWASP) |
+| `security/mitigations.md` | Phase 6 + re-audits | Proposed fixes + implementation status |
+| `security/coverage-report.md` | Phase 7 + re-audits | Coverage score, gaps, accepted risks |
+
+---
+
+## Edge Cases
+
+| Situation | Handling |
+|-----------|----------|
+| No codebase access (Tier 2/3) | Base threats on architecture description; note confidence is lower |
+| STRIDE category has zero threats | Log "No threats identified for [category] — [brief reason]" |
+| Coverage target unreachable | After 3 re-audit passes, produce report with "maximum achievable coverage: X%" |
+| New critical threat found in re-audit | Add to threats.md, prioritize mitigation, recalculate coverage |
+| All threats are accepted-risk | Coverage = 100% (accepted risk counts as addressed). Flag this prominently. |
+| --diff but no previous security/ folder | Run full audit instead, warn the user |
+
+---
+
+## Iteration Budget
+
+- **Default:** 3 re-audit passes (initial audit + 2 re-audits)
+- **Override:** Set `max_audit_passes: N` in the request
+- **Termination:** coverage >= target OR passes exhausted
+- **On exhaustion:** Report highest achievable coverage with recommendations for manual review of remaining gaps

package/skills/autoresearch/modes/ship.md

@@ -0,0 +1,49 @@
+# Autoresearch Ship — Readiness and Human Handoff
+
+## OpenCode authority envelope
+
+This document is inert guidance. `lit-plan` must approve the readiness objective, evidence policy,
+finite budget, canonical roots, local write set, rollback policy, and review gate before any mutation,
+including an interactive run. Only explicit `/start-work` may perform bounded writes, commands,
+evaluation, or reversion within that packet; without it this mode remains read-only.
+
+This LitOpenCode mode preserves the source family's artifact-type readiness analysis while removing
+automatic publication and deployment. It is static workflow data and grants no shell, registry,
+release, version, commit, tag, push, or host-config authority.
+
+## Entry gate
+
+Identify the artifact type and destination only to select the matching checklist in
+`../references/type-checklists.md`. Confirm the bounded read paths and evidence commands through
+`lit-plan`. Any edits, builds, or tests require an approved authority packet and `/start-work`.
+
+## Reversible readiness phases
+
+1. **Completeness** — inventory required files and unresolved production markers. Report findings;
+   do not silently delete or rewrite them.
+2. **Tests** — run only the approved commands with time bounds. Record command, cwd, exit status,
+   duration, and skipped coverage.
+3. **Security** — use repository-owned checks when available. A missing scanner is a capability gap,
+   not a clean verdict. Never print credentials or private configuration.
+4. **Documentation** — verify current usage, safety boundaries, public APIs, and examples against the
+   built surface.
+5. **Version consistency** — inspect all version-bearing files, but do not change them. Any version
+   change is a separate explicit approval boundary.
+6. **Build/package** — create only approved temporary artifacts. Inspect their contents and include a
+   cleanup receipt.
+7. **Review** — send the readiness packet to `/review-work`. Findings, stale evidence, missing gates,
+   or an inconclusive lane block readiness.
+8. **Human handoff** — stop. Name the irreversible action that a human may choose later. This mode
+   never performs it, even when the user supplies release words in command arguments.
+
+## Output
+
+Write `ship-log.md` only inside an approved work root. Record artifact type, intended destination,
+evidence timestamps, each reversible phase, review verdict, residual risks, and cleanup. Finish with
+`READY_FOR_HUMAN_DECISION` or `BLOCKED_READINESS`; neither is a publication claim.
+
+## Cancel and resume
+
+Cancellation flushes the current phase receipt and stops. Resume re-reads the log, rejects stale
+evidence whose inputs changed, and restarts from the first unverified phase. Never replay a completed
+mutation merely because the log is incomplete.