Finder Intake and Requirements Boundary Planning Research

Scope and method

This report consolidates three readonly planning lanes: current skill and scaffold surfaces, synchronization and release validation, and architecture and public test seams. It also records fresh Linear readback for IP-432 through IP-437. It does not reopen requirements or authorize provider mutation.

Authoritative product meaning is the compiled Finder Intake and Requirements Boundary specification at Harness commit 753563612fe6e39d5ec8665e294283b9628b7021. The requirements grill reports an empty frontier and confirmed shared understanding.

Facts

Provider task graph

Fresh workspace reads proved that the active connector named linear_devpunks reaches the Devpunks workspace 1081916c-55b9-46bb-b923-a80db9ffca35; the connector name is not treated as authority. Every Task is in the CLI Product Area, milestone 628692ba-d348-44eb-a7d9-185f504955fb, and Backlog.

IP-432  Simplify Finder entrypoints                 (no blocker)
IP-433  Requirements Phase owns delivery depth      (no blocker)
IP-434  Separate outcomes from backlog identities   (no blocker)
IP-435  Preserve Fog and delivery truth              (no blocker)
  IP-434 ──blocks──> IP-436  Derive provider hierarchy
  IP-435 ───────────────┐
  IP-436 ───────────────┴──blocks──> IP-437  Integrated proof

get_issue(..., includeRelations: true) proved the native edges. The earlier planning inference that IP-435 also blocks IP-436 was rejected because provider readback shows no such relation.

Current contract drift

Finder still exposes Technical Finder and the three-stage model in apps/cli/src/data/catalog/skills.ts:585, apps/cli/src/data/catalog/packs.ts:249, apps/cli/src/content/prompts.ts:19, apps/cli/src/content/scaffold-copy.ts:29, and apps/cli/src/content/finder-entrypoints-catalog-prompts.test.ts:9.
The synchronized skill mirror still has Technical depth and staged routing in .agents/skills/finder-phase/SKILL.md:9, .agents/skills/finder-phase/phases/router.md:12, and .agents/skills/technical-finder/SKILL.md:1.
Business Finder currently reaches Epic and Functional Finder reaches Story, contradicting their accepted Initiative and Epic ceilings: .agents/skills/business-finder/SKILL.md:28 and .agents/skills/functional-finder/SKILL.md:24.
Requirements Phase currently stops after Create Spec and disclaims backlog creation at .agents/skills/requirements-phase/SKILL.md:9-25.
All five compiler/projection repair surfaces retain Technical Finder, exact-Story, User Stories, or US-### wording: .agents/skills/create-spec/SKILL.md:17, .agents/skills/create-spec/assets/SPEC-TEMPLATE.md:18, .agents/skills/create-spec/references/readiness.md:17, .agents/skills/create-spec/references/spec-quality-bar.md:9, and .agents/skills/write-backlog/references/technical-projection.md:3.
The Linear adapter still maps Product Area and semantic Initiative to nested native Initiatives and Epic to Project at .agents/skills/write-backlog/references/providers/linear.md:7-28.
Fog delivery completion already has the correct narrow production-evidence seam at .agents/skills/write-backlog/references/delivery-status.md:29-63; staged Fog intake remains at .agents/skills/write-backlog/references/fog-intake.md:10-31.
The provider-neutral executable validation seam is .agents/skills/write-backlog/scripts/validate-task-blocker-graph.mjs:9-136.

Equivalent stale skill copies exist under apps/cli/skills/**. They are generated consumers, not authoring sources.

Source, synchronization, and release authority

The required canonical checkout /Users/stefan/Desktop/repos/wearedevpunks-skills is not mounted on this Linux host, and no replacement checkout exists under /home/stefan. Its required main branch and user-owned dirty changes therefore cannot be revalidated here. Implementation must restore that exact source authority before the first skill edit.

Harness pins the shared source in apps/cli/scripts/sync-skills-repo.mjs:20-22; the pin test is apps/cli/src/scripts/sync-skills-repo.test.ts:5-13. bun run sync:skills replaces apps/cli/skills/** and writes the source receipt. The receipt commit must equal the pushed canonical SHA and the pin/test.

apps/cli/scripts/build-baseline.mjs:200-311 packages catalogs, scripts, subagents, and synchronized skills. apps/cli/scripts/build-dist.mjs:46-80 bundles and hashes those bytes. Release selection is changelog-only: BASELINE_CHANGELOG.md selects baseline and CHANGELOG.md selects npm, as implemented in apps/cli/scripts/release-impact-classifier.mjs:121-226.

The supported scaffold update advanced .devpunks/settings.json to baseline 2026.09.02-e430f9a0. Fresh bun run hi check --json then proved CLI 4.0.2, no baseline drift, no changed files, and a successful operation. Separate tool bootstrap still lacks clawpatch and debug-agent; this did not affect the green scaffold check.

Architecture inference

The change is architecture-bearing because it changes cumulative ownership and six public seams:

Business Finder ─┐
Functional Finder├─> finder-phase ──returns bounded Fog context
                 │
direct input ─────┴─> Requirements Phase
                       ├─> Requirements Grill
                       ├─> Create Spec (OUT-###)
                       └─> Write Backlog
                             ├─> provider-neutral blocker validation
                             ├─> Linear adapter
                             ├─> GitHub adapter
                             └─> exact readback / delivery truth

The accepted specification already owns this topology. Planning should preserve thin Finder wrappers, one shared router, one Requirements Phase delivery-depth route, provider-neutral compilation, one mutation writer, provider adapters, and the separate delivery-status seam. No new runtime subsystem or temporary compatibility route is needed.

Test seams

IP-432: tests/finder-phase-graph.contract.test.mjs, tests/functional-finder.contract.test.mjs, and current Technical Finder contracts provide a clean RED for exactly two wrappers and generic support children.
IP-433: tests/wayfinder-lifecycle.contract.test.mjs and tests/requirements-grill-composition.contract.test.mjs currently preserve the old route and can prove direct and conditional-context behavior.
IP-434: tests/fixtures/create-spec-readiness.json and tests/write-backlog-lifecycle.contract.test.mjs can prove OUT-### coverage and unequal outcome/Story counts.
IP-435: tests/delivery-backlog-state.contract.test.mjs and its integration suite already separate merge, staging, production, and partial readback; add only the missing historical/no-credit cases.
IP-436: tests/write-backlog-{operating-model,lifecycle,linear,github,provider-planning}.contract.test.mjs and the blocker validator provide provider-neutral RED/GREEN seams.
IP-437: the canonical full suite plus Harness catalog, sync-receipt, type, packaged-product, consumer-repository, baseline, and live readback gates form the cumulative proof.

Conflicts and uncertainties

One research lane observed and reverted the scaffold update while another worker completed it. Fresh coordinator readback supersedes both lane-local snapshots and proves the updated baseline state.
The canonical source is absent. Remote immutable content can support planning, but it cannot satisfy the required local main branch, user-change reconciliation, commit, and push workflow.
Existing shared-source pin documentation disagrees with the implementation pin. Integrated closeout must reconcile the new source SHA across code, test, receipt, docs, and changelog.
Local fixtures prove Harness-owned mapping and rejection logic. They do not prove live provider representation; final exact readback remains a separate gate.
Historical IP-380 through IP-388 are compatibility evidence only and remain outside every mutation target.

Planning conclusion

Keep all six Linear Tasks as the only execution identities. The four initially unblocked Tasks own disjoint content/test paths and can run in one worker wave. Workers do not stage, commit, push, or change branches. The parent exclusively owns the shared Git index, HEAD, and push after cumulative source validation, without inventing provider blockers. Synchronize and validate Harness only after the canonical source is committed and pushed with an exact receipt.

Finder Intake and Requirements Boundary Planning Research

On this page