Initialize and verify an adopter

Current repository verificationRenderer: MermaidSource Markdown: docs/architecture/06-runtime-view/README.mdSource revision: 4bbf84bbdd441eb1d12450bc552cafef6dc43f55

The repository also exposes npm run verify, npm run verify:dotnet and npm run test:visual for workspace, .NET and browser evidence respectively.

Semantic initialization

Current semantic initializationRenderer: MermaidSource Markdown: docs/architecture/06-runtime-view/README.mdSource revision: 4bbf84bbdd441eb1d12450bc552cafef6dc43f55

The current CLI executes this plan for the baseline and selected profile assets. Aspire application creation and external CodeGraph checks remain outside this runtime.

Adopt existing authorities

Existing-authority adoptionRenderer: MermaidSource Markdown: docs/architecture/06-runtime-view/README.mdSource revision: 4bbf84bbdd441eb1d12450bc552cafef6dc43f55

Existing-authority adoption leaves provider-owned files unchanged. The same boundary applies to capability adoption: the package owns the catalog and adapter contract, the CLI owns local declaration and evidence, and the provider remains the authority for remote state.

SDLC route planning

Lighthouse SDLC route descriptorsRenderer: MermaidSource Markdown: docs/architecture/06-runtime-view/README.mdSource revision: 4bbf84bbdd441eb1d12450bc552cafef6dc43f55

The SDLC package implements route, stage, gate, state, decomposition and provider-adapter validators. It also distributes gh-aw workflows that execute an agent in GitHub Actions. Lighthouse has no persistent execution service. The selected router handles owner refinement labels, clarification replies and manual dispatch. Later-stage composition remains outside this implemented route.

Verify package and site contracts

Current package and public-site verificationRenderer: MermaidSource Markdown: docs/architecture/06-runtime-view/README.mdSource revision: 4bbf84bbdd441eb1d12450bc552cafef6dc43f55

Target supervised host execution

Proposed delivery and execution authority boundariesRenderer: MermaidSource Markdown: docs/architecture/06-runtime-view/README.mdSource revision: 4bbf84bbdd441eb1d12450bc552cafef6dc43f55

This is the accepted target implementation of the bounded-role use case, not the current gh-aw execution path. The agent supplies candidate results; a deterministic validator interprets them and a separately credentialed publisher performs effects. Automated triage/refine may gather information and prepare artifacts while a required human gate prevents the next stage. Unattended progression requires an accepted policy for the named gate; setting composition: ff alone grants none.

Request and result boundary

The following is a design contract pending a packaged schema and compatibility tests. The SDLC package owns its wire shape; the host owns its operational result. Do not place these fields into stage-result v1, which remains unchanged.

Request content	Validation and owner
Schema and package versions, contract digest	Adapter resolves exact installed artifacts; unsupported combinations stop before model use.
Repository ID, work-item reference, source and workflow revisions	Trusted ingress supplies identity; publisher rereads remote source before writing.
Delivery run ID, stage execution ID, attempt ID and idempotency key	Stable identities correlate events, retries and artifacts; duplicate submission returns the existing attempt.
Route, stage, role, predecessor result digests	Lighthouse validates membership, order, stage/gate pairing and predecessor lineage.
Authority references, tool capabilities, write scope and proposed effect types	Versioned role and adopter policy bound the request; the host may only narrow it.
Deadline, correction/recovery bounds and cancellation reference	Host enforces process/resource limits and stops on exhausted authority.
Policy revision and recorded approval references	Publisher verifies scope, actor and freshness; changed source or policy invalidates affected approvals.

The response contains a separate operational outcome, the candidate stage result, proposed effects and evidence references. completed at the process boundary does not imply passed at the stage boundary. An interrupted run may have no stage result and still needs a durable operational record.

Continuation and event handling

Continuation requires the expected run/stage/gate, successful stage status, complete required evidence, no unresolved blocker and the gate decisions required by the selected route. ready is preparation, not approval. The validator checks evidence content and provenance as well as JSON shape. The router must not use a model's nextAction as an executable command.

The event adapter rereads issue state and actor permission before admission and publication. It accepts at most one stage request for an event identity and ignores closed, duplicate, unauthorized or irrelevant events. Issue comments are task data, never workflow code. An answered clarification resumes only the matching waiting run with a fresh revision and bounded round count.

Persist validated transition events with correlation and source references. Rebuild lifecycle state using Lighthouse's transition rules; derive labels from that state and verify provider writes. The host stores those events without creating a different transition catalog.

GitHub label writes made with GITHUB_TOKEN do not trigger another issue-label workflow. Use explicit reusable-workflow composition or an authorized dispatch for continuation, or a separately configured GitHub App when its event behavior is required. PR CI trigger/approval behavior must be tested with the actual publisher identity; a successful push is not evidence that required CI ran. See GitHub workflow triggering.

The external-host projection accepts an owner-added refine label. The host authenticates event facts and invokes the package's deterministic event router; schema-2 admission carries the verified label-event identity without a triage predecessor. Schema 1 preserves the prior supervised contract. Source remains read-only and the stage publishes a validated refinement comment plus its readiness labels. See the packaged host contract.

The host owns the persistent reservation and projects it as agent-working. human-working prevents new agent admission and requests termination of active work. Outcome publication and reservation cleanup must finish before capacity is released. Labels are cooperative signals; they cannot prevent a human or an unrelated tool from editing the issue.

An owner event reaches one router and one reusable gh-aw worker. A preparation job verifies identity and current source, snapshots issue intent and reserves the issue. The agent job loads the pinned harness package and starts OpenCode in a temporary Docker container. Source and skills are read-only; the candidate envelope is writable. The imported engine streams OpenCode events into the Actions step and gh-aw log artifacts.

A separate publication job validates the envelope and rereads source, owner answers and reservation before commenting and setting ready or needs-info. Cleanup releases agent-working. An owner reply resumes only the waiting refinement. The workflow never treats a ready issue as approval for implementation or merge.

The Actions run owns the execution record, with source/harness/image revisions in a runtime receipt. There is no socket service or SoFa execution dependency. The earlier external-host contract remains available for compatibility. The engine deployment example states the Docker subscription profile's isolation limits; the broader continuation contract above remains target behavior.