feat(ce-plan,ce-work): add wires_into connection verification gate

[Drewx-Design]

Summary

Plans implemented via the compound engineering pipeline consistently ship all planned Implementation Units but miss connections between them — functions that should call each other don't, UI components that should trigger backend paths aren't wired, event handlers that should propagate never fire.

This PR adds:

• A new wires_into field to ce-plan's Implementation Unit template (Phase 3.5) that declares critical cross-unit integration points as grep-verifiable code references
• A connection verification gate in ce-work's Phase 3 (step 1b) that automatically checks each declared connection before code review

Key design decisions

• Explicit type prefixes (call:, event:, route:) eliminate disambiguation — the plan author already knows what type of connection they're declaring
• Grep-based verification — mechanically checkable, unlike manual test cascades that require a browser
• Graceful skip for legacy plans without wires_into entries — no breaking changes
• Complements existing mechanisms — System-Wide Test Check catches within-unit issues during implementation; wires_into catches between-unit connections after all units are complete

Changes

ce-plan/SKILL.md (+14 lines)

• Phase 3.5: wires_into field definition with format guidance, scope rules, and exclusions
• Phase 4.2: wires_into template block in the IU markdown template
• Phase 5.1: Review checklist item for wires_into completeness

ce-work/SKILL.md (+21 lines)

• Phase 3 step 1b: Connection Verification Gate with per-prefix verification strategies, failure prompts, and graceful legacy skip

Context

Analysis of 11 PRs in a production Next.js codebase showed ~70% wired features — each IU built correctly in isolation, but cross-unit connections missed. Examples:

• Backend persists step data, frontend never extracts it
• Gate implemented on one API path, missed on two others
• Three independent API contract mismatches shipped simultaneously

All would have been caught by a wires_into entry declaring the cross-unit connection.

Post-Deploy Monitoring & Validation

No additional operational monitoring required — this change modifies prompt-file skill definitions, not runtime code. Validation is through running the updated skills on real features and observing whether wires_into entries are generated and verified correctly.

Test plan

• Run updated ce-plan on a multi-IU feature and verify wires_into entries are generated with correct type prefixes
• Run updated ce-work on the resulting plan and verify the connection gate runs, greps for declared connections, and reports results
• Verify legacy plans (without wires_into) trigger graceful skip, not errors

[tmchow]

@Drewx-Design Thanks for this work!

the problem statement is well-researched, so appreciate that (the 70% wiring rate across 11 PRs is compelling). The core idea of declaring cross-unit connections at plan time is valuable/good. That's the right intervention for an attention/sequencing problem: make the planner write down the seams so the executor doesn't forget them.

That said, after reviewing the implementation against both skills' design principles, I think the mechanism needs to shift. The direction is right but the approach has a few issues that undermine the stated goal.

---

1. Grep verifies presence, not wiring

The PR title says "verification gate" but the call: strategy only confirms both symbol names exist in changed files (not that Source actually calls Target). A function that's imported but never invoked passes. An endpoint that exists but is called with wrong arguments passes.

These are the failure modes the PR description claims to solve (e.g., "backend persists step data, frontend never extracts it"). The gate would give a green checkmark on several of the motivating examples.

The event: strategy is the strongest of the three (exact string match is meaningful), but call: and route: mostly prove co-occurrence, which is a different claim than "A is wired to B."

2. Typed prefixes push ce-plan away from "decisions, not code"

ce-plan's posture is that plans communicate decisions, not implementation code. Requiring call: orchestrator.generateSection → condensationLoop asks the planner to name exact function exports at planning time which is the same kind of implementation-level specificity the skill deliberately avoids everywhere else. The format serves grep, not the planner's thinking (hopefully this makes sense)

3. Scope contradiction for existing-code integrations

ce-plan says wires_into should be used "when this unit connects to existing code that must call into it," but ce-work's call: and route: verification searches "files changed or created in this PR." If one side of the connection lives in unchanged existing code, the gate fails on one of its primary use cases.

But i think the issue is actually deeper than just "changed vs. unchanged files."

The grep approach assumes the plan perfectly predicted the implementation's symbol names. But implementation regularly introduces intermediary functions, wrapper layers, or renamed exports that the planner couldn't have anticipated. The connection exists, just through a different path than the plan imagined. Grep for the planned name fails even though the wiring is correct.

This is another reason natural-language contracts + agent-directed verification is the better fit. "Unit 1's orchestrator must invoke Unit 2's condensation loop" holds true whether the implementation calls it condensationLoop, runCondensation, or routes through a processingPipeline helper. The agent reads the code and traces the intent, not a specific string.

4. ce-work-beta not updated

ce-work-beta describes itself as "same as ce-work" plus delegation support, but its Phase 3 still jumps straight from core checks to code review. The behavior should be consistent across both workflow surfaces. (and work-beta is something i want to promote in the near future so want to prevent drift)

---

Direction

The declaration is the valuable part: keep wires_into as a concept. The adjustment is to the format and verification mechanism:

Plan-time: Drop type prefixes and grep-formatted function names. Entries should be natural-language integration contracts at the same abstraction level as the rest of the plan:

**Wires_into:**
- The orchestrator (Unit 1) must invoke the condensation loop (Unit 2)
  when generating long sections
- The revision UI (Unit 4) must call the revise-section API (Unit 3)
- The revision API (Unit 3) must emit a completion event consumed by
  the notification handler (Unit 5)

The planner describes what must connect to what and why — a decision, not grep syntax.

Execution-time: Replace the strategy table with agent-directed verification. Something like:

For each wires_into entry, read the relevant source and target code and confirm the integration is actually wired: the call is made, the endpoint is hit, the event is sent and handled. If a connection is missing or incomplete, fix it before proceeding to code review.

The executing agent can trace call chains, check arguments, and read unchanged files (all things grep can't do). This is consistent with how the rest of ce-work operates: give direction and trust agent intelligence, rather than prescribing a mechanical procedure. The agent is already trusted to implement features, write tests, and do code review. It can certainly read two files and confirm one calls the other.

This gets you a gate that actually verifies wiring (not just presence), works for existing-code integrations, stays framework-agnostic, and keeps ce-plan at the "decisions, not code" abstraction level.