feat: add dev-context, resolved editing context for one piece of the framework

[vivibui]

What

aidlc engine dev-context <kind> <id> emits the resolved context for editing one
piece of the framework, instead of leaving you to walk the prose for it.

aidlc engine dev-context stage requirements-analysis
aidlc engine dev-context hook aidlc-run-sensors
aidlc engine dev-context tool aidlc-graph
aidlc engine dev-context agent aidlc-architect-agent
aidlc engine dev-context test t243-install-mechanism.test.ts   # reverse lookup

Why

The runtime already refuses to walk prose to answer "what applies here?" —
graph compile resolves it once and the orchestrator reads the answer off the
node, the discipline docs/reference/02-plane-architecture.md states as "filter
evaluation never happens at packet rate". Whoever edits a stage gets no such
service: they open the stage file, guess which protocol modules apply, find the
persona, then its knowledge dir, then the scope grid, then the covering tests,
then the doc chapters. This applies the existing compile boundary one plane out,
to the developer.

For a stage it emits the resolved graph node, the protocol modules that actually
apply, lead/support persona paths and the lead's knowledge dir, compile-resolved
sensors and rules, which scopes execute it, the covering tests, and the doc
chapters that name it.

Measured on stage:requirements-analysis: ~574 tokens, against ~67k for the
seven files a first-time reader actually opens to answer the same question.
The bundle replaces the search for what applies — not the reading of whatever you
then decide to change.

Design notes

It adds no source of truth. Everything is derived from artefacts the build
already produces (stage-graph.json, tests/.coverage-registry.json, the shipped
agent/sensor trees), so a stale bundle means a stale bun scripts/package.ts.

Engine-namespaced, not a public verb. The public surface is deliberately six
install-lifecycle commands, pinned by an exact-list assertion in t230. Widening the
product's front door is a maintainer call, so this sits with graph, runtime, and
sensor. Promoting it later is a one-line route change.

Two things are mirrored rather than derived, and are labelled as such:

• The protocol-module rule is duplicated from the engine's directive build, which
  cannot be imported (it needs live workflow state). t340 re-derives the engine's
  three conditions over every shipped stage and compares, so a change there fails
  in the test rather than silently skewing every bundle.
• The review class is the stage's declared value. resolveReviewClass() lowers
  it per scope reviewCap and honours a Review Override state field, and a
  developer query has neither, so the output says (declared) and points at the
  resolver.

Paths follow the tree you are in: core/ in a source checkout (what you edit,
per AGENTS.md), the harness directory in an install. Verified both, including that
every emitted path exists on disk in each mode. Coverage and doc sections need a
source checkout and report themselves unavailable otherwise rather than vanishing.

Coordination with #1115 — please read before merging

#1115 replaces loadDelegate's switch with
DELEGATES: Record<ToolFile, () => Promise<DelegateModule>>, where a missing entry
is a tsc error. That is strictly better than the mechanism here, and it deletes
every case TOOLS.x: line.

This branch adds case TOOLS.devContext: because without it the tool is
unroutable on the compiled/native channel — dev-mode bun <tool> spawns directly,
so the gap is invisible until the binary runs. That is the same class of bug #1115
exists to fix (#1070, reviewBrief), not a duplicate of its fix: different tool,
different line.

On merge order: if #1115 lands first, this needs one entry —
"aidlc-dev-context.ts": () => import("./aidlc-dev-context.ts") — instead of the
case. t340's registration check deliberately accepts either spelling, so it stays
green across that landing. Happy to rebase whenever #1115 is ready.

Verification

• bun run check — packaging deterministic across two independent builds for all
  seven harnesses, 3 typecheck projects, lint over 771 files: clean.
• bun test tests/unit/t340-dev-context.test.ts — 9/9. Both new pins were
  negative-controlled: breaking the protocol rule fails t340, and removing the
  delegate registration fails it. A first attempt at the registration pin was a
  behavioural probe through the dispatcher; it passed with the registration removed
  (dev mode spawns rather than resolving the table), so it was replaced.
• t239 documentation-parity and t230 dispatcher-routes pass; the README tool count
  moved 70 → 71, which t239 derives from disk.
• Exit codes verified on both channels: found → 0, unknown id → 1, through the
  dispatcher as well as direct invocation.
• Install mode verified by copying dist/claude/.claude outside any checkout.

Verified on macOS; CI covers Linux and Windows.

Not included

No release metadata: per AGENTS.md § Release Metadata Policy (#1096), feature PRs
do not touch aidlc-version.ts, the README badge, or CHANGELOG.md.

Whole-registry delegate exhaustiveness is #1115's. Sharing one protocol-module
resolver between the engine and this tool would remove the mirroring entirely, but
that edits the engine's directive build and belongs in its own PR.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the project license.

[vivibui]

Note for whoever runs the unit tier locally on this branch, so 12 failures are not
misattributed here.

tests/unit/t314-source-freshness-receipts.test.ts fails identically on
unmodified main:

tree	result
fix/dev-context @ 04ff5dd4	107 pass / 12 fail
clean main @ 891669aa (no aidlc-dev-context.ts present)	107 pass / 12 fail

Same file, same count, with this PR's tool absent from the baseline tree. Two
adjacent files, t249-copilot-adapter and t265-plan-approval-guard, also looked
red at first and are clean when run with enough memory — 58/0 and 53/0 here.

Two measurement traps I hit establishing that, in case they save someone time:

• A baseline run first reported t314 as 0 pass / 1 fail / 1 error in ~92 ms. That
  was not a test result — it was
  SyntaxError: Export named 'reviewRecordDigest' not found in .../dist/claude/.claude/tools/aidlc-lib.ts,
  i.e. a stale projection. bun scripts/package.ts in that tree first, then the
  file actually runs and gives 107/12.
• Passing several test paths as one shell-quoted string makes bun test treat them
  as a name filter and run zero tests while exiting quietly. That reads exactly
  like "no failures."

Scope of what this PR verified: bun run check clean (packaging deterministic
across all seven harnesses, three typecheck projects, lint over 776 files), and
t340 + t239 + t230 at 143 pass / 0 fail. A complete local smoke+unit tier is not
part of that evidence — this machine runs out of memory partway through (the tier
was killed once for it, and free memory sat at 56–84 MB throughout). Linux CI is the
right arbiter for the full tier, and it still needs the fork workflow-run approval.

[vivibui]

@apackeer @leandrodamascena — would you mind taking a look when you have a moment?
I can't add reviewers directly (my account has read-only access to this repo), so
tagging instead.

Tagging you two specifically because of what it touches:

• @apackeer — it registers a new tool in core/tools/aidlc.ts, and that
  registration is the exact mechanism fix: make compiled dispatch exhaustive over TOOLS so native review briefs route (#1070) #1115 replaces. Details are in the PR
  description, but the short version: this adds case TOOLS.devContext: because
  without it the tool is unroutable on the compiled channel, and if fix: make compiled dispatch exhaustive over TOOLS so native review briefs route (#1070) #1115 lands
  first this needs one DELEGATES entry instead. The registration test accepts
  either spelling so it stays green across that landing. Happy to rebase whenever
  suits.
• @leandrodamascena — the only doc change is a new subsection in
  docs/reference/11-contributing.md, which you've been maintaining.

Two things worth a second opinion:

1. Engine mirroring. protocolModulesFor() duplicates three of the engine's
   four module conditions, because the engine's version is internal to a directive
   build that needs live workflow state. A Codex review pass caught that the fourth,
   learnings, was missing after 1b064585 added it — so the guard now enumerates
   protocolModules.push(...) from aidlc-orchestrate.ts and fails if this tool
   stops accounting for one. Sharing a single resolver would remove the mirroring
   entirely, but that edits the directive build, so I left it as a follow-up rather
   than widening this diff. Tell me if you'd rather see it done properly here.
2. Namespace choice. It sits under engine rather than as a public verb, since
   t230 pins the public surface to six install-lifecycle commands and widening the
   product's front door felt like your call, not mine. One-line change if you'd
   prefer it public.

bun run check is clean (deterministic across all seven harnesses, typecheck, lint
over 776 files) and the targeted tests pass 144/0. The comment above records which
local failures are pre-existing on main. CI still needs a fork workflow-run
approval before the real suites run.