sdlc 0.8 plan — the bun/node product, completed and published

State: closed/archived · Genre: plan

Status: approved plan, 2026-09-23. This is the reference document for the work. Phase 1 turns its phase list into a roadmap entity with milestones and tasks; the roadmap tracks state, and this document keeps the rationale. Plan changes land as commits on the phase PRs. Tracked by RM-E2L0.

Context

sdlc (solutions/ontological in sksizer/dev) will be superseded by the larger ontological/SDF revision, possibly Rust. Before moving on, the bun/node version gets finished as a complete product, published as soon as it’s usable rather than held back for a single end-of-plan drop. The first public release is v0.4.0: Phases 1–3, plus the publishing mechanics (Phase 14, pulled forward to branch off sdlc/p3-vault once Phase 2 (#2296) and Phase 3 (#2312) merge) and a fix for the installed-plugin CLI lookup gap (T-VAW3). It publishes as sdlc’s own self-hosted, single-plugin marketplace at sksizer/sdlc (D-P3NF-sksizer-sdlc-is-product-home — not sksizer/marketplace-sdlc’s pre-existing multi-plugin catalog), compiled for Claude Code, Codex and Cursor by agent-pants; every later version (v0.5.0, v0.6.0, v0.7.0, v0.8.0) publishes the same way, on tag, through the same mechanics. The work should mostly run by itself, overnight, with one PR per phase for the user to review, not hundreds.

What the user asked for:

• Tracking and quality: a tracking document (a version roadmap linking every milestone) under a very strict validation loop. That loop includes a thorough, judgment-based code review covering functions, modularity, duplication, comments and structure.
• Orchestrator loops, dogfooded first:
  • dispatch work that advances the tracking document;
  • watch PRs, run adversarial reviews and respond to them;
  • on merge, update the other PRs and close out.
• Workflows in sdlc.yaml: built-in skills by default, which a project can override or extend with its own skills or scripts. That includes a judgment check that runs after the deterministic one. Flowline is optional.
• The whole configuration in sdlc.yaml, meta-defined, as desired state with drift detection. CLI first, then TUI.
• Hosts for sessions: Orca, terminal and cmux, plus Claude, Codex and Cursor.
• Git hooks, standardized (#2283). A blocking pre-commit must notify and let work continue elsewhere.
• An SDLC chain with label-driven autonomy and a GitHub issue loop.
• From the comparable-tools survey: an MCP server, notifications, GitHub Issues integration, cost/token tracking.
• OKF v0.2 conformance: status → state; wikilinks stay links.
• The agent-pants vault becomes the canonical plugin source, converted once, early.
• The current UI, ported where it can run on the bun/node product.
• A relaxed task-definition contract, mainly the code-area specification.
• Pruning decided by an audit.

Key facts the plan builds on

• Config: SdlcConfigSchema (lib/config/load.ts:72, loaded by loadConfig at :679); the schema-driven scaffold (lib/config/scaffold.ts); resolveVerb (lib/config/verbs.ts:254) with trust gating (exit 21); runOneSilent (lib/services/quality/ops/run.ts:48).
• Deterministic PR and task machinery: pr classify (verdict plus per-PR cursor), pr survey / pr update (rebase or merge with guards), leases (lease task acquire), task next, task inflight, orchestrate watch, orchestrate log-tick.
• Judgment checks already exist: sdlc verify changes (via @sksizer/agent-dev, which judges a diff against in-scope standards and instruction files using agent-call); pr review launches an interactive review session. Review-style skills exist too: bug-finder, docs-sweep, api-enhancement-scan.
• Hosts: lib/services/host/: the HostParts contract, hosts/{terminal,orca,cmux}.ts, pickHost. Interactive engines are in engines.ts; headless engines are in packages/ts/agent-call (claude | codex | gemini | opencode).
• Op registry (lib/registry.ts): typed Zod descriptors, from which MCP tools can be derived.
• Entities: CommonFrontmatter (lib/model/entities/_common.ts:180) has type, title, tags, status, related and provenance; the schemas are .strict() with markdown-contract on top. The task contract (lib/model/entities/task/implementation-ready.md) disqualifies unresolvable ## Today / ## Files to touch rows; the claim resolver (lib/model/entities/task/claims/) uses them for collision avoidance.
• agent-pants: its input is a vault: <plugin>/<plugin>.md plus skills/<name>/<name>.md with ap-kind/ap-plugin, rendering three harness trees. marketplace.out: . works. Gaps: plugin-level assets, resource excludes, a plugin-root token. Codex and Cursor resolve paths relative to the skill directory.
• Flowline (packages/ts/flowline) is a scaffold with no logic; its spike lives on consolidate/workflow-library-full.
• Current UI:
  • the dashboard server (lib/services/dashboard/server.ts: an INDEX_HTML page plus a JSON API);
  • the SDF desktop (desktop/src-nuxt): sessions and dispatch pages run on @sdlc/dashboard-client; work, control-plane, model/* and agent-pants still need classifying;
  • experiences/system-graph and experiences/suspenders.
• Snapshot: ~/dev/repos/sksizer/marketplace-sdlc-wt/sdlc-import at 6077a33 (Claude plugin form, verified), unpushed.

Execution model (how this runs overnight)

• One branch and one PR per phase. Branch sdlc/p<N>-<slug>, with a draft PR opened at the phase’s first commit and appended to as work proceeds. Tasks inside a phase commit to the phase branch, or run on short sub-branches that the driver merges into it once they pass the phase gate. The user reviews one PR per phase.

• Stacked phases. A phase that depends on an earlier one branches off that phase’s branch and continues without approval. When an earlier branch changes, pr-update restacks the later ones. Each phase is marked:

  • auto: proceeds and stacks unattended;
  • gate: stops and notifies.

  Gates are only for outward-facing or irreversible steps: pushing to the public sksizer/sdlc, npm publishing, merging to main — each one needs the user’s explicit approval every time it happens, starting at v0.4.0 and repeating at every version after it. Approval is never a standing grant.

• Phase gate, applied per task and again per phase before its PR leaves draft:

  1. deterministic check;
  2. the judgment judge workflow: verify changes plus a thorough code review with a fixed rubric (functions, modularity, duplication, comments, structure, naming, dead code, tests);
  3. an adversarial pr-review by a different engine or model;
  4. pr-respond until the review is clean or max_rounds is reached.

  Rubric findings above a severity threshold block. Each phase PR carries a review report.

• Blocked is not stopped. When a pre-commit hook or any gate blocks an autonomous task, the agent fixes and retries up to N times. Then the task is parked: state: in-progress/blocked with the failure recorded, the WIP committed to its sub-branch (never --no-verify), and a notification sent. The loop moves on to other ready work, so one failure never halts the night.

• Three-tier delegation, driven from one top-level agent session, to preserve context.

  • Tier 1, the top orchestrator (the driving session). It holds the roadmap and phase states, and never reads or writes implementation code. Its jobs:

    • Phase 1 bootstrap: create the roadmap, milestones and tasks through a subagent;
    • dispatch one phase orchestrator per ready phase, as a background general-purpose subagent (not a fork, since forks can’t delegate further);
    • start dependent phases as stacked branches once their parent phase is far enough;
    • apply the gates;
    • verify a phase from its PR, its review report and the command output of check/roadmap check, never by re-reading diffs;
    • send notifications;
    • re-dispatch parked work.

    It stays live overnight by always keeping phase orchestrators in flight; their completions wake it.

  • Tier 2, phase orchestrators (one per phase, sonnet). Each owns its phase branch, worktree and draft PR. It breaks the phase into tasks (creating or refining the task entities) and delegates all implementation. Then it runs the phase gate (check → judge → adversarial review → respond, each through subagents), merges sub-branches into the phase branch, updates the PR and roadmap state, parks blocked tasks, and returns a short structured summary: done, parked, PR link, gate results. It writes its running log to .sdlc/runs/p<N>.md, not into its own context.

  • Tier 3, implementers and reviewers. Each is a subagent with one task or one review in the phase worktree (or a sub-branch worktree). Model per the cheapest-capable-model rule: haiku for mechanical and search work, sonnet for design-bearing work. Each returns a short result; details live in commits and the run log.

• The CLI loops join as they land. Once Phase 2 is merged into its branch and working, sdlc orchestrate run --loop prs,merges runs in the background to tend every phase PR (adversarial review, respond, restack). The work loop is dogfooded on individual tasks. Phase-level orchestration stays with the agent tiers for the overnight run.

• Resumable: the roadmap, task states and .sdlc/runs/ logs are the source of truth, so an interrupted night resumes from them.

• Preflight before starting:

  • probe push rights to origin branches and gh pr create, per the probe-before-dispatch lesson;
  • check gh auth;
  • check the notification channel works.

• Versions (the roadmap’s version sections). Tags sdlc/vX.Y.Z via release-lib:

  • v0.4.0 after Phases 1–3, plus Phase 14 pulled forward: roadmap and strict loop, orchestrator loops, canonical vault, the installed-plugin CLI fix (T-VAW3), and the publishing mechanics. The first public release — pushed to sksizer/sdlc (D-P3NF-sksizer-sdlc-is-product-home) as a marketplace plugin only. npm publish is a follow-up (T-7H3A): the mirror doesn’t yet ship a buildable CLI source tree, so it’s not part of v0.4.0.
  • v0.5.0 after Phases 4–6: audit, config, hooks, hosts, sessions. Publishes on tag, through Phase 14’s mechanics.
  • v0.6.0 after Phases 7–9: chain and issue loop, notifications, MCP; plus Sessions v2 and Router, folded in from simple-dispatch;
  • v0.7.0 after Phases 10–11: OKF and state, usage; plus Forge port + pr-update extraction, folded in from simple-dispatch;
  • v0.8.0 after Phases 12–13: UI and TUI, the audit’s pruning done — the complete product.

  From v0.4.0 on, every version publishes to sksizer/sdlc the same way, on tag, through Phase 14’s mechanics. npm publish joins once the mirror ships buildable CLI source (T-7H3A). Public push to sksizer/sdlc, and npm publish once it starts, stay gates: each needs the user’s explicit approval, every time, not just once at the start.

• The atlas, kept current. The architecture and plan are drawn in one HTML page, the sdlc 0.8 Atlas. It has two tabs: an overview (phase status, the PR stack, architecture, open items, glossary) and the built-in flows (workflows, orchestrator loops, hooks).

  • It exists in two places: the published page (https://claude.ai/artifact/FbMLdWK2Nz56nATVPq4JkY, private to the user) and the committed copy sdlc-0.8-atlas.html, which is the durable source.
  • The top orchestrator updates both whenever a phase PR opens, merges or changes status; a gate decision is made or needed; or the architecture or a built-in flow changes. Edit the committed copy, republish the page from it, and commit the copy on the next campaign PR. Neither copy is left stale.

Folded in: simple-dispatch

Status: decided, 2026-09-26. simple-dispatch and this campaign are a single thread of work, not two: this roadmap (RM-E2L0) is the one plan, and simple-dispatch’s docs — simple-dispatch-plan.html and simple-dispatch-interfaces.html, plus the survey notes under docs/research/ — become design input for it. The docs PR carrying this fold-in is #2324.

A comparison of the two plans found, contingent on #2296 and #2327 landing close to their current shape — both are open, unmerged PRs as of this writing, not code on main yet:

• “Dispatch replaces the orchestrate loop” is superseded. P2 (#2296, open) proposes sdlc orchestrate run --loop work,prs,merges with leases; nothing on main implements it yet (T-3HIC confirms the op doesn’t exist today). If it merges as proposed, simple-dispatch’s “claim is the lease” design matches P2’s design exactly, and there is no separate loop left to build — but that conclusion holds only once #2296 lands.
• Host vs. harness axes. simple-dispatch’s cleaner model keeps hosts (terminal/orca/cmux/tmux) independent of harnesses (claude/codex/cursor/pi). P6 (#2327, open) proposes collapsing the two by making claude/codex/cursor hosts directly. If P6 merges as-is, un-collapsing them is the first task of the new Sessions v2 milestone — but if review reshapes P6 before it lands, this section and Sessions v2’s own framing need re-checking against whatever actually merges.
• New capability from simple-dispatch: live session states (running / waiting_for_input / gone), SessionNote, Host.send into an already-open session, hook-driven status, and a Router (send → native → resume → open fallback) with a DeliveryRecord and signature-keyed idempotent delivery.
• New from simple-dispatch: extracting pr-update into packages/ts/pr-update, plus a Forge port (GitHub adapter, then Forgejo). This campaign is GitHub-only today.
• One TUI. simple-dispatch’s Ink TUI (a PR table and a Tasks page) becomes the first screens of Phase 13’s TUI.
• Web UI. simple-dispatch’s SDF web view is sequenced after Phase 12’s UI port, since both target the same desktop/src-nuxt pages.
• Parked. sdlc-lite and the Foreman peer relationship go to the backlog (T-RCXA).

This adds three milestones: Sessions v2 and Router join v0.6.0, and Forge port + pr-update extraction joins v0.7.0 — described in the Phases section below, alongside the phases they extend. See RM-E2L0 for the milestones and their tasks.

Phases

Step 0 — Commit this plan first, in its own PR

• The very first action after approval: copy this plan into the repo as docs/planning/notes/N-S4AJ-sdlc-0-8-plan.md, a plain doc with an S-0007-formatted header, and PR links hyperlinked per CLAUDE.md. Commit it in a worktree on branch docs/sdlc-0.8-plan, push, and open a docs-only PR immediately, so agents working elsewhere can reference it by path or PR link. The user merges it (merging to main is a gate).
• Phase 1 turns it into the roadmap entity: the roadmap links to this doc for rationale, and the doc links back to the roadmap. Later plan changes land as commits on the phase PRs.

Phase 0 — Keep the v0.3.1 capture local

• The verified snapshot (feat/sdlc-bun-import in the local marketplace-sdlc clone) stays local and unpushed, tagged sdlc-v0.3.1 locally for reference. Superseded: the first public release now ships from mainline at v0.4.0 (Phase 14, pulled forward), not from this snapshot; the snapshot itself is never published.
• The stray lease-message one-liner is folded into Phase 1.

Phase 1 — Tracking, strict loop, relaxed task contract (auto)

• Tracking. A roadmap entity type (schema, template, contract) and docs/planning/roadmaps/<id>-sdlc-0.8.md: version sections linking one milestone per phase, each milestone with its tasks, and each phase’s auto/gate marking.
• roadmap check: links resolve, tasks exist, and roadmap/milestone/task states are consistent.
• Strict check verb, run by pre-commit, CI and the loops: typecheck, tests, entities validate plus entities audit in strict mode, roadmap check, and docs generate --check.
• judge workflow (see Phase 2 for the grammar): verify changes plus the code-review rubric. The rubric lives as a standard (an S- entity), so verify changes and reviewers read the same criteria.
• Relax the task contract.
  • ## Files to touch becomes ## Areas: packages, directories or modules, advisory, with no resolution disqualifier. ## Today becomes optional prose.
  • The claim resolver works at area (directory) granularity for collision avoidance.
  • Goal, acceptance criteria (objectively verifiable), verification and out-of-scope stay strict.
  • Existing tasks are migrated by an entities-migrate transform.

Phase 2 — CLI orchestrator loops (auto; PR tending runs on them from here on)

• Workflows in sdlc.yaml. A workflow is an ordered list of steps; a step is one of skill:, run: (a verb), script: or prompt:. Built-in defaults ship in code, and a project overrides a workflow or adds prepend: / append: steps. The built-ins:

  • implement: task-work;
  • check: the deterministic verbs;
  • judge: judgment checks after check;
  • pr-review: adversarial;
  • pr-respond;
  • pr-update: rebase or merge onto a moved base, and restack;
  • close-out;
  • define: task-ensure-ready → task-auto-define.

  The grammar is kept runner-agnostic, so flowline could execute it later.

• sdlc session launch: extracted from pr review. It takes --workflow|--skill|--prompt, --engine, --host and --cwd, and has a headless mode (claude -p / codex exec) that writes a session record to .sdlc/sessions/<id>/.

• sdlc orchestrate run --loop work,prs,merges [--interval] [--once] [--dry-run]:

  • work: picks the roadmap’s next ready tasks in milestone order, within in-flight limits, taking leases. It runs define if needed, then implement on the phase branch or a sub-branch, then the phase gate, then merges into the phase branch. It parks blocked tasks, refreshes roadmap state, and opens or updates the phase PR.
  • prs: a new PR, or new commits on one, gets an adversarial pr-review; after that come pr-respond rounds, and CI failures go to pr-respond.
  • merges: on a merge, runs close-out, then pr-update across the open PRs and stacked phase branches, then re-queues review.

  Per-item leases prevent double dispatch. Blocked items park and notify. There’s a minimal notifier (desktop plus ntfy) here; it grows into the full notify: section in Phase 8.

• Dogfood: the prs and merges loops tend every later phase PR, and work is exercised on individual tasks. The existing skills are used unchanged in this phase.

Phase 3 — Invert to the canonical agent-pants vault (auto)

• One hard-cutover conversion in place.

  • Plugin files: a sdlc.md plugin note replaces .claude-plugin/plugin.json; each skills/<name>/SKILL.md becomes <name>.md with ap-kind/ap-plugin; a marketplace-sdlc marketplace note is added.
  • Build config: a nested solutions/ontological/agent-pants.yaml. Verify what the vault root requires; add a mode to agent-pants rather than moving skills away from the CLI.

• agent-pants additions:

  • plugin-level assets (the built cli/: sdlc.js, wasm, launcher);
  • resource excludes (tests/, fixtures);
  • a skill-relative scripts/sdlc shim emitted per skill (walks up to cli/sdlc, falls back to PATH), with Claude optionally rendering ${CLAUDE_PLUGIN_ROOT}.

  Conventions are served by sdlc conventions show <name>.

• Rewire the skill-file consumers in the same PR: the skill-prose gate and invariants.yaml, gate corpus-invocation, audit_skill_runtime.ts, the docs-site generator, harness install / project doctor (pointed at the rendered Claude tree), and the skill tests.

• Dev loop: agent-pants build joins check, with a drift gate and a --watch mode. This repo’s live Claude session loads the rendered plugin.

• Retire sdlc harness export and agent-plugin’s exporters. Reconcile the root vault’s pr-tools/check-pr with sdlc:pr-respond.

• Tag v0.4.0 + first public release (gate; Phase 14 mechanics run here first).

Phase 4 — Audit (auto; runs alongside 2–6)

• Grade the skills, CLI nouns, ops and config keys. Apply the code-review rubric codebase-wide (functions, modularity, duplication, comments, structure), reconciled with docs/planning/notes/N-UAG5-2026-07-19-sdlc-simplification-audit.md.
• Write a report plus tasks. Pruning and refactor tasks join Phase 13; mechanical fixes go into the phases whose code they touch.

Phase 5 — Full sdlc.yaml, meta-defined, with config CLI and hooks (auto)

• Meta definition. Zod 4 .meta() on every key (category, consumers, layers, applies_via, runs_in), enforced by a completeness test. Sections: verbs, workflows, chain, hooks, harness, sessions, orchestrator, notify, mcp, knowledge, issues, usage. Trust stays machine-local.
• CLI: sdlc config list|explain|get|set (writes through yaml-splice), sdlc run, sdlc apply [--dry-run], sdlc init, and drift reporting in doctor. The sdlc.yaml reference docs are generated from schema plus meta.
• Hooks. hooks: uses the workflow step grammar, plus when: deps-missing (reusing detectDeps / NODE_LOCKFILE_MANAGERS) and on_fail: warn|block|park. park signals the loop to park the task and notify rather than stall. apply writes shims into the --git-common-dir hooks dir, chaining existing hooks and printing entries when lefthook or husky owns the dir.
• #2283: its logic moves into setup resolution, and scripts/bootstrap-deps.sh goes.

Phase 6 — Hosts and sessions (auto)

• New hosts in lib/services/host/hosts/, each implementing the session and/or terminal parts, with available() probes:
  • claude: Claude Code, via the CLI or the desktop app where it exposes a launch-with-prompt entry;
  • codex: the Codex CLI or app;
  • cursor: the cursor-agent CLI, or opening the worktree in Cursor with the prompt.
• Mapping: a per-host/engine mapping turns a workflow step into the first message.
• Visibility: session list / session attach read the session records across hosts. The sessions: config sets defaults per workflow.
• v0.5.0 publishes on tag, through Phase 14’s mechanics (already in place since v0.4.0). The public-push and npm-publish gates apply, as at every release.
• Merges as-is. Making claude/codex/cursor hosts directly collapses host and harness into one axis; simple-dispatch keeps them independent. The host/harness split follows in Sessions v2 (v0.6.0), folded in from simple-dispatch — see “Folded in: simple-dispatch” above.

Phase 7 — SDLC chain, label-driven autonomy, issue loop (auto)

• The chain: a decision doc plus chain: config. Stages: capture → triage → define → ready → implement → check → judge → review → respond → merge → close-out, each bound to a workflow.
• Labels: sdlc:stage/<stage> for position, sdlc:auto/<stage> for the autonomy ceiling. apply manages the label vocabulary.
• Markdown stays the source of truth: an issue entering define gets a linked task entity (issue:), and the label mirrors state both ways. sdlc issues sync handles fields; conflicts are reported.
• An issues loop joins the runner. Roadmap tasks and issues both advance up to their ceiling.

Phase 8 — Notifications (auto)

• notify: configures channels (desktop, ntfy HTTP topic, webhook for Slack or Discord) and events: pr.needs_response, pr.ci_failed, task.parked, stage.ceiling_reached, phase.ready_for_review, lease.expired, session.ended, hook.blocked, orchestrator.dead_stop.
• Ops: sdlc notify send|test. This grows Phase 2’s minimal notifier.

Phase 9 — MCP server (auto)

• sdlc mcp: a stdio server whose tools are derived from the op registry, with an allowlist in mcp:. apply registers it per harness.
• Tag v0.6.0 locally.

Sessions v2 — host/harness split, tmux + pi, Host.send, live states (auto)

Folded in from simple-dispatch (M-TAYX) — see “Folded in: simple-dispatch” above.

• Split host and harness back into independent axes after Phase 6’s collapse: rename AgentEngine to Harness (claude | codex | cursor), keep hosts (terminal/orca/cmux) harness-agnostic, and pick host and harness independently per session.
• Add a tmux host and a pi harness, closing simple-dispatch’s two gaps against terminal/orca/cmux and claude/codex.
• Host.send: a new host-contract part that delivers a message into an already-open session, with a per-harness nativeSend fallback.
• Live session states and status hooks: SessionState (running / waiting_for_input / gone), a SessionNote/SessionRegistry keyed by lease, and hook-driven status per harness (falling back to host polling), feeding session list/session attach from Phase 6.

Router — live-session PR delivery (auto)

Folded in from simple-dispatch (M-27ZR) — see “Folded in: simple-dispatch” above. Builds on the prs tick’s PR-action path (Phase 2); does not replace the orchestrate loop, which Phase 2 already ships.

• Delivery chain: send (live terminal) → harness native send → resume → fresh open, per simple-dispatch’s createRouter design, wired into the prs tick so NEEDS-RESPONSE feedback reaches a PR’s live session before a new one opens.
• DeliveryRecord: a signature-keyed, per-subject delivery log (comments and reviews signed by kind+id+edit-time; pr-update conflicts signed by PR+base+paths) so a tick never re-sends the same feedback twice — pr classify’s cursor cannot be reused for this since it advances on every call regardless of outcome.
• PR-subject lease: extends the lease system with a refs/sdlc/prs/<n> kind so a PR with no task behind it can still be leased and routed to.

Phase 10 — OKF v0.2 conformance (auto)

• Rename status → state as a hard cutover: schema bump, a migrate transform, every consumer and the label mirror.
• Admit OKF’s optional keys, including status (draft|stable|deprecated); map provenance onto generated; count wikilinks as edges.
• Bundle: index.md files with okf_version: "0.2", type: Note or scope-exclusion for non-entity docs, and sdlc okf validate in the strict loop.

Phase 11 — Cost and token tracking (auto)

• Headless usage from engine JSON output; interactive usage from transcripts by session id. Stored in .sdlc/usage.jsonl.
• sdlc usage report, a per-tick total, and usage.budget, which pauses dispatch and notifies.
• Tag v0.7.0 locally.

Forge port + pr-update extraction (auto)

Folded in from simple-dispatch (M-JEH1) — see “Folded in: simple-dispatch” above. The campaign is GitHub-only today.

• Extract pr-update into its own package, packages/ts/pr-update, following the S-0015 standalone CLI shape and the packages/ts/waypost precedent: a plain PrUpdateConfig object in place of the injectable SdlcConfig, injected ports for repo location and the post-update verb hook, layered standalone config (flags → .pr-update.yaml → defaults), and sdlc pr survey/sdlc pr update kept as thin wrappers.
• Forge port: a pluggable interface (listPrs/getPr/postComment/ updateBranch/parsePrUrl/prForBranch) with a GitHub adapter first, so pr-update and pr classify depend on the port rather than @sksizer/easy-gh directly. Drift (behind/ahead) stays a local git computation, not a forge field, since Forgejo has no equivalent.
• Forgejo adapter: the second adapter, proving the port needs no change elsewhere to add a forge, per docs/planning/notes/N-G3HA-forges-forgejo.md.

Phase 12 — Bring over the current UI (auto)

• Inventory and classify the desktop pages, experiences and INDEX_HTML by backend. Port what runs on the sdlc JSON API into one static SPA (nuxt generate from the desktop’s browser mode; fall back to Vite + Vue if the vendored closure is too heavy). sdlc dashboard serves it, and it ships as plugin assets with @sdlc/dashboard-client.
• New views: roadmap progress, loop status and tick log, the PR board with review/respond rounds, sessions with open-in-host, chain stages and labels, config (read and edit), notifications, usage.
• Terminals: link out to the host rather than embedding PTYs.
• Web dispatch view follows. simple-dispatch’s SDF web view — its proposed extension of T-B6YL to render the dispatch loop’s live state — is folded in as design input and sequenced after this phase’s port, since both target the same desktop/src-nuxt sessions/dispatch pages.

Phase 13 — TUI and pruning (auto)

• An Ink TUI over the same ops. Its first screens are simple-dispatch’s Ink TUI, folded in as design input: a PR table (verdict, behind/ahead, checks, new comments, session present) and a Tasks page (status, impact, complexity, lease phase, open PR, rank).
• Execute the audit’s pruning and refactor tasks.
• Tag v0.8.0 — the complete product, published through Phase 14’s mechanics (already in place since v0.4.0), not the first public release.

Phase 14 — Publishing mechanics (pulled forward; first release v0.4.0) (gate)

• Pulled forward. Originally the last phase before v0.8.0, Phase 14 now branches as sdlc/p14-release off sdlc/p3-vault, once its preconditions — Phase 2 (#2296) and Phase 3 (#2312) merged — are met, and runs alongside Phases 5–7, so the first public release ships at v0.4.0 instead of waiting for the complete product.
• Prerequisite: T-VAW3. The launcher copied into a built pack can’t find the CLI, and five skill scripts import lib/ by relative path; both work only from the dev checkout. This must be fixed before an installed copy is usable.
• Retargeted to sksizer/sdlc (D-P3NF-sksizer-sdlc-is-product-home): sdlc’s own self-hosted product repo, not sksizer/marketplace-sdlc’s pre-existing multi-plugin catalog. assemble.ts’s --layout product mode (the default for this target) replaces the whole repo with the rendered plugin trees for all three harnesses plus a root README/LICENSE/ .gitignore/CHANGELOG — the target does not need to be its own agent-pants project the way the original plan assumed; --layout marketplace (the surgical merge) is what a pre-existing multi-plugin marketplace still needs, and stays available for one.
• Assembler scripts/sdlc-mirror/assemble.ts does a plain copy with no format conversion: the dependency closure, path rewrites with a leftover-path gate, the shared fixtures, cli/sdlc.js plus the SPA assets, agent-pants build, then standalone validation (install, strict loop, agent-pants check, a Node-only install per harness).
• Move product-level fixes back from the snapshot: build-node.ts, node-bootstrap, the launcher dev-checkout rule, the test fixes, and marking monorepo-only tests.
• Version bump to 0.4.0 across solutions/ontological/package.json, the plugin note (.claude-plugin/plugin.json, moving to a sdlc.md plugin note once Phase 3 lands), and the marketplace manifest (.claude-plugin/marketplace.json).
• Standalone install test per harness: Claude, Codex, Cursor and a Node-only install, each exercised against the assembled tree outside this monorepo.
• Release: an sdlc entry in publish-libs.json with an assemble hook, and a release-lib / publish-lib.yml extension. The npm binary release moves to a mirror-side release.yml.

Verification

• Execution model:
  • the preflight passes before starting;
  • the top orchestrator’s context holds only summaries and command output, never code;
  • every phase orchestrator returns a structured summary, and its run log exists in .sdlc/runs/;
  • each phase ends with exactly one PR carrying its review report;
  • a parked task leaves the loop running and sends a notification;
  • a stacked branch restacks after its parent changes;
  • no gate step (public push, npm, merge to main) happens without the user.
• Phase 1: roadmap check fails on a broken link or a state mismatch; a relaxed task (areas only) passes task-ensure-ready; the migrated corpus validates; judge produces rubric findings on a seeded duplicate function.
• Phase 2:
  • orchestrate run --once --dry-run gives correct plans for fixture PRs and the roadmap;
  • live: the work loop dispatches a roadmap task, a new PR gets a cross-engine review answered by pr-respond, and a merge closes out and restacks;
  • there’s no double dispatch;
  • a workflow append and an override both apply.
• Phase 3: no SKILL.md or plugin.json remains in the source; three harness trees render with the CLI and without tests/; the live Claude session loads the rendered plugin; gates pass; Codex and Cursor skills run scripts/sdlc --help.
• Phase 5: meta completeness; a byte-preserving config set; apply idempotence; doctor flags drift; the hook scenarios (worktree deps install, pre-commit backstop, park path, chaining, the lefthook entry, untrusted exit 21).
• Phase 6: session launch works on each of the orca, terminal, cmux, claude, codex and cursor hosts where available; unavailable hosts fail with a clear available() message.
• Phases 7–13: a labeled issue advances to its ceiling, then notifies; notify test reaches every channel; MCP tools list, and task_next parity holds; the state migration passes validate, audit and okf; usage rows total correctly; the SPA serves from an installed plugin on Node only; the TUI edits config.
• Phase 14 (alongside Phases 5–7): T-VAW3’s acceptance criteria pass — an installed copy of the pack finds and runs its CLI with no dev checkout, SDLC_HOME or link present; the version bump lands in package.json, the plugin note and the marketplace manifest; the publish-lib rehearsal passes; harness trees from sksizer/sdlc install and run under the standalone install test on Claude, Codex, Cursor and Node-only.
• Always: the strict check plus judge, and the roadmap reflects the real state.

---

← Back to Notes