Tightening DLD-kit into the coding harness

Background

DLD-kit is working well in production on Genie — 206 decisions in conversation-agent-runtime, 123 in conversation-agent-admin. Today it ships as a collection of agent skills the agent reads on demand, runs scripts for, and reports back in plain text. That's a solid baseline; the question is whether the experience could be meaningfully smoother if DLD were a first-class part of the harness rather than something the agent reaches for on request — always-visible state, structured rendering, proactive signals instead of after-the-fact transcript scanning.

The recently-released Pi coding agent (https://pi.dev) is a low-risk place to try this: it's designed to be extended in TypeScript at every layer (TUI, tool calls, lifecycle, autocomplete, overlays) while still loading the same SKILL.md files we already have. We keep DLD-kit's portable core and add a thick harness layer on top — nothing about today's setup gets undone if it doesn't pan out, and the patterns we'd learn probably transfer to any future harness.

Solution / Spike idea

Build a Pi extension that pulls DLD into the harness itself. Existing skills stay portable; the Pi layer adds the surfaces current harnesses don't have. The common thread is shifting DLD from on-request to always-on — the harness watches the repo alongside you and surfaces what matters when it matters.

Some directions worth exploring (not a fixed feature list — the spike is partly about figuring out which of these are actually worth doing):

• Ambient state beats on-demand state — a persistent surface showing what's proposed, drifting, and recently audited.
• Surfacing audit and review outcomes — make it visible which actions an agent decided to carry out, which it skipped, and why; today this gets buried in the transcript.
• Background watchers for repo-level signals — detect upstream changes that affect in-flight decisions (reindex needs, ID collisions, freshly-merged decisions that supersede ours) and flag them proactively instead of waiting for the user to hit a rebase wall.
• Other plausible candidates: editor-level autocomplete for decision references, structured "decision cards" instead of raw markdown dumps, soft workflow modes that nudge toward decide-then-implement.

Alternative framings worth keeping open: do a lighter version of the same thing in Claude Code with its existing hooks, build a small out-of-band DLD console instead, or treat the day as a pure research spike — smallest possible loop, dogfooded for an afternoon, writeup as the deliverable. If we don't land on one path, the writeup of "where does the harness layer actually pay off?" is itself worth shipping.

Competences needed

Already have: DLD methodology and real Genie usage context, the existing DLD-kit codebase, general TypeScript/Node.

Would be learning: Pi's extension API specifically (lifecycle hooks, TUI library, autocomplete providers, overlays) — new framework, but good docs and lots of example extensions. Also: designing terminal UI that feels native, and picking measurable proxies for "is this smoother?" (typo'd IDs, reroll turns, time spent re-explaining branch state).

Nice-to-have but not required: prior terminal-UI experience (ink, blessed, ratatui) — mental model transfers.

Others

• MVP bar is low. Ambient status + decision-ID autocomplete + one typed tool is enough to evaluate the bet.
• Genie is a great proving ground — 300+ decisions across two repos, can dogfood immediately.
• Skill markdown stays portable; nothing in DLD-kit gets undone if we don't continue.
• Open question for the day: does the extension live inside dld-kit or as a separate dld-kit-pi package?