Tighten loop discovery evidence

Traceability

• Spec ID: tighten-loop-discovery-evidence
• Status: Implemented

Intent

Prevent Loop Discovery from treating commits, configured assets, related work inside one task, or user-global history as proof of repeated coding-agent work. Reuse the repository's Task Episode and evidence-state contracts, keep current coverage separate from a proposed owner, and retain compact discovery output.

Acceptance Scenarios

• AC-1: Observed recurrence requires at least two distinct, comparable Task Episodes with the same normalized intent, scope, host, trigger, procedure, output, and validation shape. Commits, report rows, and same-task steps remain supporting evidence rather than Task Episodes.
• AC-2: Explicit recurring policy or cadence, a costly single task, and entropy-only evidence remain separate recurrence classes and do not become observed repetition.
• AC-3: Discovery reports configured and observed coverage using the canonical evidence states, separates current from proposed ownership, and does not call present-only coverage exercised or effective.
• AC-4: Repository-only discovery stays repository-scoped unless the user includes workspace history, sessions, external records, or user-level memory.
• AC-5: A quick discovery returns at most three compact candidate decisions and expands only a selected new-owner or extension handoff.
• AC-6: Focused contract tests and fresh-context smoke tests against two representative repositories reject recurrence inflation while retaining a genuinely repeated command candidate.

Non-goals

• Changing the loop-blueprint Skill trigger, runtime envelopes, automation readiness, state schema, or implementation authority.
• Creating a deterministic transcript analyzer or a new report schema.
• Requiring runtime execution when the user requested a read-only discovery.

Plan and Tasks

1. Tighten demand-source normalization around distinct Task Episodes and source scope.
2. Make recurrence, coverage, and owner action explicit axes in Loop Discovery.
3. Narrow the Harness repeated-work route to previously constructed Episodes.
4. Add focused contract assertions and rerun bounded Codex CLI smoke tests.

Test and Review Evidence

• AC-1 through AC-5: node --test test/harness-skill.test.mjs.
• Markdown routing: regenerate docs/harness-doc-links.mmd, then run node --test test/doc-link-graph.test.mjs.
• AC-6: reinstall the current plugin snapshot and run read-only, ephemeral Codex CLI discovery against two representative local repositories.
• Final review: run git diff --check and inspect the focused diff separately from the pre-existing Loop Blueprint worktree changes.
• Risk: added vocabulary could duplicate Task Episode construction. Keep that construction owned by models/agent-work-loop.md and link it instead of copying its procedure.

Implementation Evidence

• Demand Source Analysis and Loop Discovery now preserve distinct Episode, evidence-scope, coverage-state, single-owner, and compact-search boundaries; the root Harness adds a direct inline route without expanding the Blueprint Skill.
• Focused Skill contracts passed 30 tests; documentation routing passed 5 tests with a current 17-file, 17-link Harness graph.
• Fresh read-only Codex CLI smoke tests in the representative repositories reported zero Observed repeated Loops, kept configured policies as Declared recurring plus Try existing, and did not use history, sessions, Memory, or target mutations. The final smoke also skipped Node and the Harness CLI.