SDLC / Creation — one software request to a verified candidate #40

Selected direction — 12 November 2026

Main designer and coordinating lead: founder (@zenithruneblade). This reopens the existing SDLC / Creation outcome; it does not create a second SDLC coordinator. The 6 November closure moved planning into #62 and never meant completion or cancellation.

Participants and current depth: the founder leads design and future slice selection. Backend fundamentals in #152/#153 remain the developers' immediate work; Nav and Anshuk contribute from that evidence. Chirayu and Kiran learn and challenge the general handoffs through their client/product work. All four should progressively understand the workflow; exact contributors, depth and implementation slices remain to be selected.

Founder design direction: a possible missing-capability case

A small case can inform the design when useful. The questions below are a reference for selecting it, not a current deep-agentic assignment for Nav or a prerequisite for the backend baseline.

• Choose one bounded public/synthetic case where a bot lacks a required capability or handoff. Distinguish a genuine missing contract/implementation from cold or unavailable execution and refused authority; consider existing capabilities before proposing construction.
• Sketch request → evidence/inquiry → explicit change acceptance → bounded construction candidate → independent checks/review → target-owned adoption and any later retry. Pin the owner and identity at each handoff. Preserve explicit refusal, insufficient evidence and interruption/unknown outcomes.
• When a useful slice is selected, Nav may prepare its source-bound inquiry from Backend execution foundations — dispatch, orchestration and task results #153 and Anshuk may review execution, persistence and private-route implications. The founder settles the design and selects the next bounded implementation. An operator-mediated rehearsal is valid when named; do not present it as a delivered native integration.
• Record the implemented versus missing steps and one next construction slice with permitted inputs/effects, workspace, verification and responsible contributor. Teach the general flow across both pairs through Enter — prepare the shared reproduction and acceptance journey #133.

The founder can continue design now; this reserves no additional developer implementation allocation and sets no whole-system completion deadline. #152 first proves durable task/result/human-feedback custody that later candidate/evaluation work can build on. It does not satisfy the full software-change acceptance below. A generated capability remains a candidate until independently checked and admitted by the appropriate owner; missing capability is not authority to change the active system.

Retained delivery scope

Wire one small software change from admitted intent through implementation and review to an inert promotion request.

This is the bounded delivery issue for the Creation software-development workflow under ADR 16. It does not create a universal SDLC coordinator: source control, verification, packaging, migration, activation and recovery retain their existing owners.

Current source boundary — 3 November 2026: Creation / Forge is Partial. The bounded creation.investigation revision 2 owns immutable public-source requests, role reservations and attempts, retained candidate/verdict, external feedback and explicit owner dispositions, with PostgreSQL custody, a protected local API and creation.investigate@2. It produces an investigation report and separate judgment; it does not edit source or execute a disposable candidate. Native accepted, independent partial and owner hold remain distinct. The software-change checklist below remains open: the existing investigation slice does not establish an admitted command executor, verified executable edit, Promotion Request or target-owner effect. Older ordinary-native observations are dated history under the current evidence envelope.

First working slice

• Persist an immutable Creation Request with exact base, desired outcome, allowed paths/effects, budget and verification criteria. Name the exact Composition owner (or Suite for coordination only) before registering its bounded Pattern; otherwise retain an inert operator-reviewed request without claiming an executable application workflow.
• Use settled direction or Inquiry / Crucible — one bounded evidence and review workflow #39 where needed, then construct one attributable candidate in a disposable workspace through an admitted executor.
• Run focused checks and independent review; retain exact candidate/artifact identities, commands, results and unresolved findings.
• Resume interrupted preparation safely and reject a changed base; produce a Promotion Request without changing the active checkout or Vessel.

Connections: Builds on #29, #23 and #33; the first acceptance uses #27 Tomb for an explicitly admitted command-based change, and required decisions use #26. #28 is an optional later foreign-agent executor, not an additional prerequisite. #35 adds foreign-source admission to this candidate lifecycle.

Later: Multiple work packages, merge/conflict handling and target-owned release/update effects. Outcome-driven improvement links to #30/#33/#34 through separate admission.

References: ADR 16 · ADR 28 · Creation method.

Contribution entry: Extend the accepted Creation owner toward one verified disposable-workspace path, reusing its existing immutable investigation/candidate/verdict custody rather than treating those records as absent.
Open decision: Pin the exact application contract and Pattern revision for an executable software-change slice; creation.investigate@2 admits investigation only. Use #27 Tomb for the bounded command-based candidate, with founder/maintainer review admitting the exact commands and source change. Until that execution contract is accepted, retain inert records and stop before executable Pattern publication or promotion.
Verification: Pinned source fixture, isolated executor and independent checks. Shared contribution and touched-docs rules: #52.