lsd-pi 1.0.0 → 1.1.0

package/dist/resources/extensions/gsd/status-guards.js

@@ -1,12 +0,0 @@
-/**
- * Status predicates for GSD state-machine guards.
- *
- * The DB stores status as free-form strings. Two values indicate
- * "closed": "complete" (canonical) and "done" (legacy / alias).
- * Every inline `status === "complete" || status === "done"` should
- * use isClosedStatus() instead.
- */
-/** Returns true when a milestone, slice, or task status indicates closure. */
-export function isClosedStatus(status) {
-    return status === "complete" || status === "done";
-}

package/dist/resources/extensions/gsd/structured-data-formatter.js

@@ -1,98 +0,0 @@
-/**
- * Structured Data Formatter — compact notation for prompt injection.
- *
- * Converts GSD data structures into a token-efficient format that removes
- * markdown table overhead, redundant labels, and formatting while remaining
- * perfectly readable by LLMs.
- *
- * Format rules:
- * - No table pipes, dashes, or header rows
- * - Use indentation (2 spaces) for structure instead of delimiters
- * - Omit field names when the pattern is clear from a header
- * - Use single-line entries for simple records
- * - Use multi-line with indentation for complex records
- */
-// ---------------------------------------------------------------------------
-// Decisions
-// ---------------------------------------------------------------------------
-/** Compact format for a single decision record (pipe-separated, no padding). */
-export function formatDecisionCompact(decision) {
-    return [
-        decision.id,
-        decision.when_context,
-        decision.scope,
-        decision.decision,
-        decision.choice,
-        decision.rationale,
-        decision.revisable,
-        decision.made_by ?? 'agent',
-    ].join(" | ");
-}
-/** Format multiple decisions in compact notation with a Fields header. */
-export function formatDecisionsCompact(decisions) {
-    if (decisions.length === 0) {
-        return "# Decisions (compact)\n(none)";
-    }
-    const header = "# Decisions (compact)\nFields: id | when | scope | decision | choice | rationale | revisable | made_by";
-    const lines = decisions.map(formatDecisionCompact);
-    return `${header}\n\n${lines.join("\n")}`;
-}
-// ---------------------------------------------------------------------------
-// Requirements
-// ---------------------------------------------------------------------------
-/** Compact format for a single requirement record (multi-line). */
-export function formatRequirementCompact(req) {
-    const lines = [];
-    lines.push(`${req.id} [${req.class}] (${req.status}) owner:${req.primary_owner}`);
-    lines.push(`  ${req.description}`);
-    lines.push(`  why: ${req.why}`);
-    lines.push(`  validate: ${req.validation}`);
-    return lines.join("\n");
-}
-/** Format multiple requirements in compact notation. */
-export function formatRequirementsCompact(requirements) {
-    if (requirements.length === 0) {
-        return "# Requirements (compact)\n(none)";
-    }
-    const header = "# Requirements (compact)";
-    const blocks = requirements.map(formatRequirementCompact);
-    return `${header}\n\n${blocks.join("\n\n")}`;
-}
-// ---------------------------------------------------------------------------
-// Task Plans
-// ---------------------------------------------------------------------------
-/** Compact format for task plan entries. */
-export function formatTaskPlanCompact(tasks) {
-    if (tasks.length === 0) {
-        return "# Tasks (compact)\n(none)";
-    }
-    const header = "# Tasks (compact)";
-    const blocks = tasks.map((t) => {
-        const check = t.done ? "x" : " ";
-        const lines = [];
-        lines.push(`${t.id} [${check}] ${t.title} (${t.estimate})`);
-        if (t.files && t.files.length > 0) {
-            lines.push(`  files: ${t.files.join(", ")}`);
-        }
-        if (t.verify) {
-            lines.push(`  verify: ${t.verify}`);
-        }
-        lines.push(`  ${t.description}`);
-        return lines.join("\n");
-    });
-    return `${header}\n\n${blocks.join("\n\n")}`;
-}
-// ---------------------------------------------------------------------------
-// Savings measurement
-// ---------------------------------------------------------------------------
-/**
- * Measure the token savings of compact format vs markdown format.
- * Returns savings as a percentage (0-100).
- * A positive number means compact is smaller (saves tokens).
- */
-export function measureSavings(compactContent, markdownContent) {
-    if (markdownContent.length === 0)
-        return 0;
-    const saved = markdownContent.length - compactContent.length;
-    return (saved / markdownContent.length) * 100;
-}

package/dist/resources/extensions/gsd/sync-lock.js

@@ -1,89 +0,0 @@
-// GSD Extension — Advisory Sync Lock
-// Prevents concurrent worktree syncs from colliding via a simple file lock.
-// Stale locks (mtime > 60s) are auto-overridden. Lock acquisition waits up
-// to 5 seconds then skips non-fatally.
-import { existsSync, statSync, unlinkSync } from "node:fs";
-import { join } from "node:path";
-import { atomicWriteSync } from "./atomic-write.js";
-const STALE_THRESHOLD_MS = 60_000; // 60 seconds
-const DEFAULT_TIMEOUT_MS = 5_000; // 5 seconds
-const SPIN_INTERVAL_MS = 100; // 100ms polling interval
-// SharedArrayBuffer for synchronous sleep via Atomics.wait
-const SLEEP_BUFFER = new SharedArrayBuffer(4);
-const SLEEP_VIEW = new Int32Array(SLEEP_BUFFER);
-function lockFilePath(basePath) {
-    return join(basePath, ".gsd", "sync.lock");
-}
-function sleepSync(ms) {
-    Atomics.wait(SLEEP_VIEW, 0, 0, ms);
-}
-/**
- * Acquire an advisory sync lock for the given basePath.
- * Returns { acquired: true } on success, { acquired: false } after timeout.
- *
- * - Creates lock file at {basePath}/.gsd/sync.lock with JSON { pid, acquired_at }
- * - If lock exists and mtime > 60s (stale), overrides it
- * - If lock exists and not stale, spins up to timeoutMs before giving up
- */
-export function acquireSyncLock(basePath, timeoutMs = DEFAULT_TIMEOUT_MS) {
-    const lp = lockFilePath(basePath);
-    const deadline = Date.now() + timeoutMs;
-    while (true) {
-        // Check if lock file exists
-        if (existsSync(lp)) {
-            // Check staleness
-            try {
-                const stat = statSync(lp);
-                const age = Date.now() - stat.mtimeMs;
-                if (age > STALE_THRESHOLD_MS) {
-                    // Stale lock — override it
-                    try {
-                        unlinkSync(lp);
-                    }
-                    catch { /* race: already removed */ }
-                }
-                else {
-                    // Lock is held and not stale — wait or give up
-                    if (Date.now() >= deadline) {
-                        return { acquired: false };
-                    }
-                    sleepSync(SPIN_INTERVAL_MS);
-                    continue;
-                }
-            }
-            catch {
-                // stat failed (file removed between exists check and stat) — try to acquire
-            }
-        }
-        // Lock file does not exist (or was just removed) — try to write it
-        try {
-            const lockData = {
-                pid: process.pid,
-                acquired_at: new Date().toISOString(),
-            };
-            atomicWriteSync(lp, JSON.stringify(lockData, null, 2));
-            return { acquired: true };
-        }
-        catch {
-            // Write failed (race condition with another process) — retry or give up
-            if (Date.now() >= deadline) {
-                return { acquired: false };
-            }
-            sleepSync(SPIN_INTERVAL_MS);
-        }
-    }
-}
-/**
- * Release the advisory sync lock. No-op if lock file does not exist.
- */
-export function releaseSyncLock(basePath) {
-    const lp = lockFilePath(basePath);
-    try {
-        if (existsSync(lp)) {
-            unlinkSync(lp);
-        }
-    }
-    catch {
-        // Non-fatal — lock may have been released by another process
-    }
-}

package/dist/resources/extensions/gsd/templates/PREFERENCES.md

@@ -1,80 +0,0 @@
----
-version: 1
-mode:
-always_use_skills: []
-prefer_skills: []
-avoid_skills: []
-skill_rules: []
-custom_instructions: []
-models: {}
-skill_discovery:
-skill_staleness_days:
-auto_supervisor: {}
-git:
-  auto_push:
-  push_branches:
-  remote:
-  snapshots:
-  pre_merge_check:
-  commit_type:
-  main_branch:
-  merge_strategy:
-  isolation:
-  manage_gitignore:
-  worktree_post_create:
-unique_milestone_ids:
-budget_ceiling:
-budget_enforcement:
-context_pause_threshold:
-token_profile:
-phases:
-  skip_research:
-  skip_reassess:
-  reassess_after_slice:
-  skip_slice_research:
-dynamic_routing:
-  enabled:
-  tier_models: {}
-  escalate_on_failure:
-  budget_pressure:
-  cross_provider:
-  hooks:
-auto_visualize:
-auto_report:
-parallel:
-  enabled:
-  max_workers:
-  budget_ceiling:
-  merge_strategy:
-  auto_merge:
-verification_commands: []
-verification_auto_fix:
-verification_max_retries:
-notifications:
-  enabled:
-  on_complete:
-  on_error:
-  on_budget:
-  on_milestone:
-  on_attention:
-cmux:
-  enabled:
-  notifications:
-  sidebar:
-  splits:
-  browser:
-remote_questions:
-  channel:
-  channel_id:
-  timeout_minutes:
-  poll_interval_seconds:
-uat_dispatch:
-post_unit_hooks: []
-pre_dispatch_hooks: []
-# experimental:
-#   rtk: false
----
-
-# GSD Skill Preferences
-
-See `~/.gsd/agent/extensions/gsd/docs/preferences-reference.md` for full field documentation and examples.

package/dist/resources/extensions/gsd/templates/context.md

@@ -1,76 +0,0 @@
-# {{milestoneId}}: {{milestoneTitle}}
-
-**Gathered:** {{date}}
-**Status:** Ready for planning
-
-## Project Description
-
-{{description}}
-
-## Why This Milestone
-
-{{whatProblemThisSolves_AND_whyNow}}
-
-## User-Visible Outcome
-
-### When this milestone is complete, the user can:
-
-- {{literalUserActionInRealEnvironment}}
-- {{literalUserActionInRealEnvironment}}
-
-### Entry point / environment
-
-- Entry point: {{CLI command / URL / bot / extension / service / workflow}}
-- Environment: {{local dev / browser / mobile / launchd / CI / production-like}}
-- Live dependencies involved: {{telegram / database / webhook / rpc subprocess / none}}
-
-## Completion Class
-
-- Contract complete means: {{what can be proven by tests / fixtures / artifacts}}
-- Integration complete means: {{what must work across real subsystems}}
-- Operational complete means: {{what must work under real lifecycle conditions, or none}}
-
-## Final Integrated Acceptance
-
-To call this milestone complete, we must prove:
-
-- {{one real end-to-end scenario}}
-- {{one real end-to-end scenario}}
-- {{what cannot be simulated if this milestone is to be considered truly done}}
-
-## Risks and Unknowns
-
-- {{riskOrUnknown}} — {{whyItMatters}}
-
-## Existing Codebase / Prior Art
-
-- `{{fileOrModule}}` — {{howItRelates}}
-- `{{fileOrModule}}` — {{howItRelates}}
-
-> See `.gsd/DECISIONS.md` for all architectural and pattern decisions — it is an append-only register; read it during planning, append to it during execution.
-
-## Relevant Requirements
-
-- {{requirementId}} — {{howThisMilestoneAdvancesIt}}
-
-## Scope
-
-### In Scope
-
-- {{inScopeItem}}
-
-### Out of Scope / Non-Goals
-
-- {{outOfScopeItem}}
-
-## Technical Constraints
-
-- {{constraint}}
-
-## Integration Points
-
-- {{systemOrService}} — {{howThisMilestoneInteractsWithIt}}
-
-## Open Questions
-
-- {{question}} — {{currentThinking}}

package/dist/resources/extensions/gsd/templates/decisions.md

@@ -1,8 +0,0 @@
-# Decisions Register
-
-<!-- Append-only. Never edit or remove existing rows.
-     To reverse a decision, add a new row that supersedes it.
-     Read this file at the start of any planning or research phase. -->
-
-| # | When | Scope | Decision | Choice | Rationale | Revisable? | Made By |
-|---|------|-------|----------|--------|-----------|------------|---------|

package/dist/resources/extensions/gsd/templates/knowledge.md

@@ -1,19 +0,0 @@
-# Project Knowledge
-
-Append-only register of project-specific rules, patterns, and lessons learned.
-Agents read this before every unit. Add entries when you discover something worth remembering.
-
-## Rules
-
-| # | Scope | Rule | Why | Added |
-|---|-------|------|-----|-------|
-
-## Patterns
-
-| # | Pattern | Where | Notes |
-|---|---------|-------|-------|
-
-## Lessons Learned
-
-| # | What Happened | Root Cause | Fix | Scope |
-|---|--------------|------------|-----|-------|

package/dist/resources/extensions/gsd/templates/milestone-summary.md

@@ -1,81 +0,0 @@
----
-id: {{milestoneId}}
-provides:
-  - {{whatThisMilestoneProvides}}
-key_decisions:
-  - {{decision}}
-patterns_established:
-  - {{pattern}}
-observability_surfaces:
-  - {{status endpoint, structured log, persisted failure state, diagnostic command, or none}}
-requirement_outcomes:
-  - id: {{requirementId}}
-    from_status: {{active|blocked|deferred}}
-    to_status: {{validated|deferred|blocked|out_of_scope}}
-    proof: {{whatEvidenceSupportsThisTransition}}
-duration: {{duration}}
-verification_result: passed
-completed_at: {{date}}
----
-
-# {{milestoneId}}: {{milestoneTitle}}
-
-<!-- One-liner must say what the milestone actually delivered, not just that it completed.
-     Good: "State machine integrity with completing-milestone gating, doctor audits, and observability validation"
-     Bad: "Milestone 2 completed" -->
-
-**{{oneLiner}}**
-
-## What Happened
-
-<!-- Cross-slice narrative: compress all slice summaries into a coherent story.
-     Focus on what was built, how the slices connected, and what the milestone
-     achieved as a whole — not a task-by-task replay. -->
-
-{{crossSliceNarrative}}
-
-## Cross-Slice Verification
-
-<!-- How were the milestone's success criteria verified?
-     Reference specific tests, commands, browser checks, or observable behaviors.
-     Each success criterion from the roadmap should have a corresponding verification entry. -->
-
-{{howSuccessCriteriaWereVerified}}
-
-## Requirement Changes
-
-<!-- Transitions with evidence. Each requirement that changed status during this milestone
-     should be listed with the proof that supports the transition. -->
-
-- {{requirementId}}: {{fromStatus}} → {{toStatus}} — {{evidence}}
-
-## Decision Re-evaluation
-
-<!-- Review decisions from this milestone. OMIT if no decisions need re-evaluation. -->
-
-| Decision | Original Rationale | Still Valid? | Action |
-|----------|-------------------|-------------|--------|
-| {{decisionId}} | {{originalRationale}} | {{yes/no/partially}} | {{keep/revise/supersede}} |
-
-## Forward Intelligence
-
-<!-- Write what you wish you'd known at the start of this milestone.
-     This section is read by the next milestone's planning and research steps.
-     Be specific and concrete — this is the most valuable context you can transfer. -->
-
-### What the next milestone should know
-- {{insightThatWouldHelpDownstreamWork}}
-
-### What's fragile
-- {{fragileAreaOrThinImplementation}} — {{whyItMatters}}
-
-### Authoritative diagnostics
-- {{whereAFutureAgentShouldLookFirst}} — {{whyThisSignalIsTrustworthy}}
-
-### What assumptions changed
-- {{originalAssumption}} — {{whatActuallyHappened}}
-
-## Files Created/Modified
-
-- `{{filePath}}` — {{description}}
-- `{{filePath}}` — {{description}}

package/dist/resources/extensions/gsd/templates/milestone-validation.md

@@ -1,74 +0,0 @@
----
-id: {{milestoneId}}
-remediation_round: {{round}}
-verdict: pass | needs-remediation | needs-attention
-slices_added: []
-human_required_items: 0
-validated_at: {{date}}
----
-
-# {{milestoneId}}: Milestone Validation
-
-## Success Criteria Audit
-
-<!-- For each success criterion from the roadmap, list the criterion text,
-     verdict (MET / NOT MET), and the specific evidence or gap.
-     Every criterion must appear here with a definitive verdict. -->
-
-- **Criterion:** {{criterionText}}
-  **Verdict:** {{MET or NOT MET}}
-  **Evidence:** {{sliceSummary, UATResult, testOutput, or observableBehavior}}
-
-## Deferred Work Inventory
-
-<!-- Every deferred, incomplete, or flagged item found across all slice summaries
-     and UAT results. Include the source so a reader can trace back to the original. -->
-
-| Item | Source | Classification | Disposition |
-|------|--------|----------------|-------------|
-| {{itemDescription}} | {{sliceId or UAT reference}} | {{auto-remediable / human-required / acceptable}} | {{what happens with this item}} |
-
-## Requirement Coverage
-
-<!-- Active requirements from REQUIREMENTS.md that are not yet Validated.
-     If no REQUIREMENTS.md exists, write "No requirements tracking active." -->
-
-- **{{requirementId}}**: {{status}} — {{disposition: covered by remediation slice / acceptable gap / needs attention}}
-
-## Verification Class Compliance
-
-<!-- If verification classes were defined during planning, document whether each
-     was addressed. Use N/A for classes that were empty or "none" in planning. -->
-
-| Class | Planned | Evidence | Status |
-|-------|---------|----------|--------|
-| Contract | {{planned_or_none}} | {{evidence_or_none}} | {{MET / NOT MET / N/A}} |
-| Integration | {{planned_or_none}} | {{evidence_or_none}} | {{MET / NOT MET / N/A}} |
-| Operational | {{planned_or_none}} | {{evidence_or_none}} | {{MET / NOT MET / N/A}} |
-| UAT | {{planned_or_none}} | {{evidence_or_none}} | {{MET / NOT MET / N/A}} |
-
-## Remediation Slices
-
-<!-- New slices appended to the roadmap to address auto-remediable gaps.
-     Include the full slice definition as written to the roadmap.
-     If no slices were added, write "None required." -->
-
-{{remediationSliceDefinitions OR "None required."}}
-
-## Requires Attention
-
-<!-- Items classified as human-required, with enough context for Lex to make a decision.
-     Ordered by priority (blocking items first).
-     If none, write "None." -->
-
-- **{{itemTitle}}** ({{priority: blocking / non-blocking}})
-  Context: {{whatTheItemIs, whereItCameFrom, whyItNeedsHumanInput}}
-
-## Verdict
-
-<!-- One-paragraph summary assessment.
-     State the verdict (pass / needs-remediation / needs-attention),
-     the number of criteria met vs total, and the key finding
-     that determined the verdict. -->
-
-{{verdictSummary}}

package/dist/resources/extensions/gsd/templates/plan.md

@@ -1,148 +0,0 @@
-# {{sliceId}}: {{sliceTitle}}
-
-**Goal:** {{goal}}
-**Demo:** {{demo}}
-
-## Must-Haves
-
-- {{mustHave}}
-- {{mustHave}}
-
-## Threat Surface
-
-<!-- Q3: How can this be exploited? OMIT ENTIRELY for simple slices with no auth, user input, or data exposure. -->
-
-- **Abuse**: {{abuseScenarios — parameter tampering, replay, privilege escalation, or N/A}}
-- **Data exposure**: {{sensitiveDataAccessible — PII, tokens, secrets, or none}}
-- **Input trust**: {{untrustedInput — user input reaching DB/API/filesystem, or none}}
-
-## Requirement Impact
-
-<!-- Q4: What existing promises does this break? OMIT ENTIRELY if no existing requirements are affected. -->
-
-- **Requirements touched**: {{requirementIds — e.g. R001, R003, or none}}
-- **Re-verify**: {{whatMustBeRetested — e.g. login flow, API contract, or N/A}}
-- **Decisions revisited**: {{decisionIds — e.g. D002, or none}}
-
-## Proof Level
-
-<!-- Omit this section entirely for simple slices where the answer is trivially obvious. -->
-
-- This slice proves: {{contract | integration | operational | final-assembly}}
-- Real runtime required: {{yes/no}}
-- Human/UAT required: {{yes/no}}
-
-## Verification
-
-<!-- Define what "done" looks like BEFORE detailing tasks.
-     This section is the slice's objective stopping condition — execution isn't done
-     until everything here passes.
-
-     For non-trivial projects:
-     - Write actual test files into the codebase during the first task
-     - Tests should assert on the slice's demo outcome and boundary contracts
-     - Name the test files here so execution has an unambiguous target
-
-     For simple projects or scripts:
-     - Executable verification commands (bash assertions, curl checks, etc.) are sufficient
-
-     If the project has no test framework and the work is non-trivial,
-     the first task should set one up. A test runner costs 2 minutes
-     and pays for itself immediately.
-
-     For non-trivial backend, integration, async, stateful, or UI work:
-     - Include at least one verification check for an observability or failure-path signal
-     - Verify not just that the feature works, but that a future agent can inspect its state when it fails -->
-
-- {{testFileOrCommand — e.g. `npm test -- --grep "auth flow"` or `bash scripts/verify-s01.sh`}}
-- {{testFileOrCommand}}
-
-## Observability / Diagnostics
-
-<!-- Include this section for non-trivial backend, integration, async, stateful, or UI slices.
-     OMIT ENTIRELY for simple slices where all fields would be "none".
-
-     When included, describe how a future agent will inspect current state, detect failure,
-     and localize the problem with minimal ambiguity. Keep it concise and high-signal. -->
-
-- Runtime signals: {{structured log/event, state transition, metric, or none}}
-- Inspection surfaces: {{status endpoint, CLI command, script, UI state, DB table, or none}}
-- Failure visibility: {{last error, retry count, phase, timestamp, correlation id, or none}}
-- Redaction constraints: {{secret/PII boundary or none}}
-
-## Integration Closure
-
-<!-- Omit this section entirely for simple slices with no meaningful integration concerns. -->
-
-- Upstream surfaces consumed: {{specific files / modules / contracts}}
-- New wiring introduced in this slice: {{entrypoint / composition / runtime hookup, or none}}
-- What remains before the milestone is truly usable end-to-end: {{list or "nothing"}}
-
-## Tasks
-
-<!--
-  If every task below is completed exactly as written, the Goal and Demo above
-  should be true at the stated proof level. Tasks should close the loop on the
-  slice, not merely prepare for later work unless the Demo truthfully says the
-  slice only proves fixture/contract-level behavior.
-
-  Write each task as an executable increment, not a vague intention.
-
-  Prefer action-oriented titles:
-  - "Wire real auth middleware into dashboard routes"
-  - "Persist job status and expose failure diagnostics"
-  - "Add browser test covering empty-state recovery"
-
-  Avoid vague titles:
-  - "Set up auth"
-  - "Handle errors"
-  - "Improve UI"
-
-  Each task should usually include:
-  - Why: why this task exists / what part of the slice it closes
-  - Files: the main files likely touched
-  - Do: concrete implementation steps and important constraints
-  - Verify: the command, test, or runtime check that proves it worked
-  - Done when: a measurable acceptance condition
-
-  Keep the checkbox line format exactly:
-  - [ ] **T01: Title** `est:30m`
--->
-
-- [ ] **T01: {{taskTitle}}** `est:{{estimate}}`
-  - Why: {{whyThisTaskExists}}
-  - Files: `{{filePath}}`, `{{filePath}}`
-  - Do: {{specificImplementationStepsAndConstraints}}
-  - Verify: {{testCommandOrRuntimeCheck}}
-  - Done when: {{measurableAcceptanceCondition}}
-- [ ] **T02: {{taskTitle}}** `est:{{estimate}}`
-  - Why: {{whyThisTaskExists}}
-  - Files: `{{filePath}}`, `{{filePath}}`
-  - Do: {{specificImplementationStepsAndConstraints}}
-  - Verify: {{testCommandOrRuntimeCheck}}
-  - Done when: {{measurableAcceptanceCondition}}
-<!--
-  Format rules (parsers depend on this exact structure):
-  - Checkbox line: - [ ] **T01: Title** `est:30m`
-  - Description:   indented text on the next line(s)
-  - Mark done:     change [ ] to [x]
-  - Tasks execute sequentially in order (T01, T02, T03, ...)
-  - est: is informational (e.g. 30m, 1h, 2h) and optional
-
-  Verify field rules:
-  - MUST be a mechanically executable command: `npm test`, `grep -q "pattern" file`, `test -f path`
-  - For content/document tasks: verify file existence, section count, YAML validity, or word count
-    NOT exact phrasing, specific formulas, or "zero TBD" aspirational criteria
-  - If no command can verify the output, write: "Manual review — file exists and is non-empty"
-  - BAD: "Sections 3.1 and 3.2 exist with exact formulas. Zero TBD/TODO."
-  - GOOD: `grep -c "^## " doc.md` returns >= 4 (4+ sections), `! grep -q "TBD\|TODO" doc.md`
-
-  Integration closure rule:
-  - At least one slice in any multi-boundary milestone should perform real composition/wiring, not just contract hardening
-  - For the final assembly slice, verification must exercise the real entrypoint or runtime path
--->
-
-## Files Likely Touched
-
-- `{{filePath}}`
-- `{{filePath}}`