Creatidy/scarcity-router

Fork 0

A0: Architecture, decisions, and contracts for the optional execution gateway #85

New issue

Closed

opened 2026-09-19 13:05:01 +00:00 by kilo · 0 comments

kilo commented

2026-09-19 13:05:01 +00:00

Member

Goal

Produce the coherent architecture specification for the owner-approved optional execution gateway extension — without a rewrite and without breaking recommendation-only operation — and record the superseding product decisions that authorize it.

This is the program-map issue for the execution-gateway program. The module issues M01–M10 are separate Forgejo issues (linked in the program map below and via Forgejo dependencies). A0 is documentation/contract work only; it implements no runtime behavior.

Analysis baseline: develop @ fce4311b934771f0005cada53163864790edd0e2 (2026-09-19).

Program map (module issues)

Planning id	Forgejo issue	Scope
A0	#85	This issue — architecture, decisions, contracts
M01	#86	Resource registry, state, and collectors for executable resources
M02	#87	Routing core, policy, and client-requirement binding for executable targets
M03	#88	OpenAI-compatible gateway and execution coordinator
M04	#89	Generic OpenAI-compatible HTTP adapter and Ollama integration
M05	#90	Native worker, pairing, and execution transport
M06	#91	Codex adapter: CLI/App Server with Desktop and VS Code installations
M07	#92	ZCode adapter: feasibility proof and experimental integration
M08	#93	MCP, REST, and CLI compatibility; optional remote mode
M09	#94	Configuration, web UX, and diagnostics
M10	#95	Distribution, installation, update, and end-to-end acceptance

Dependency edges (blocked-by, cycle-free): M01→A0; M02→A0; M03→A0,M01,M02; M04→A0,M03; M05→A0,M03; M06→A0,M05 (stage 2 only; stage 1 verification exempt); M07→A0,M05 (stage 2 only; stage 1 verification exempt); M08→A0; M09→A0,M03; M10→A0,M01,M02,M03,M04,M05.

Recommended first useful execution vertical slice: M01/M02 → M03/M04, with the minimum M09/M10 support each slice needs — a user should be able to use real API/Ollama resources through one OpenAI-compatible endpoint before all local CLI adapters are complete. Then M05 and M06; M07 runs as an independent research/integration track; M08 guards compatibility throughout; M09 and M10 contribute their per-slice minimums rather than being postponed entirely.

User value

A user can point any OpenAI-compatible client (one base_url, one client API key, one model/profile identifier) at a single Scarcity Router endpoint and have requests served from the best available authorized resource — API providers, Ollama/local inference, or approved local Codex/ZCode adapters — under the existing least-scarce-capable routing discipline, while every existing recommendation-only user and interface keeps working unchanged.

Product decision being implemented (owner-approved, 2026-09-19)

Scarcity Router remains one independent Apache-2.0 OSS repository and gains an OPTIONAL execution gateway alongside recommendation-only mode. This intentionally supersedes the previous blanket prohibition on inference proxying and the removal of Ollama support. It does NOT remove recommendation-only mode, does not turn Scarcity Router into an autonomous coding/agent framework, does not grant arbitrary command execution on hosts, and does not build issue-to-PR orchestration, repository management or a generic agent workflow framework. Repositories and client-side tools remain controlled by the client; SSH is a way a user may reach a machine, not a router orchestration protocol.

The goal is efficient use of heterogeneous AI access: subscriptions, eligible promotions, metered APIs, prepaid APIs and local models/local GPU. The same model name must not be assumed to mean the same resource, entitlement, quota pool, cost model or promotional eligibility.

Relationship to current code (what exists today)

Recommendation-only core: scarcity_router/selector.py, scarcity.py, policy.py, selection_types.py, simulation.py, selection_app.py (balanced selector; catalog v3 with nine calibrated identities; policy v8; capacity contract v3; machine-interface v1).
Interfaces: CLI (cli.py: status/select/simulate/install-config), loopback REST (server.py: /healthz, /v1/status, /v1/select, /v1/simulate), stdio MCP (mcp.py: scarcity_status/scarcity_select/scarcity_simulate), shared logical parsing in machine_api.py.
Collectors: OpenAI Codex app-server (providers/openai_codex*.py) with the D-039 ExecutionEligibility contract (eligibility.py, providers/openai_eligibility.py), Z.ai Coding Plan (providers/zai*.py).
Packaging: scarcity-router 0.1.0 wheel with three console scripts (D-034); default user config ~/.config/scarcity-router/selector-policy.json (D-036).
Explicit prohibitions today: D-001 (recommend, do not proxy), D-017 (no local inference), D-028/D-030/D-031 (loopback-only unauthenticated machine interfaces; MCP recommendation-only), AGENTS.md "Product boundary", docs/product.md non-goals, docs/security.md invariants.

Related but NOT repurposed: issue #82 / decision D-039 (execution-eligibility telemetry) is merged work this program builds on; its scope is complete and it remains a separate open issue for its own closeout.

Existing decisions and documents that A0 must supersede or amend (explicit list)

Superseding decisions are recorded in docs/decisions.md with the next free D-numbers; history is never rewritten:

D-001 (Recommend, do not proxy) — superseded in part: an optional execution gateway may receive prompts and execute/proxy model traffic. Recommendation-only remains the default standalone mode.
D-017 (Local Ollama support removed) — superseded: Ollama/local inference returns as an execution resource (server-direct over HTTP, or worker-bridged when localhost-only). The D-017 removal rationale (local-runtime operational instability) remains a design input for isolation, health handling and honest unknown states.
D-028 (machine-interface contract) and the docs/machine-interfaces.md non-goals — amended: the existing v1 recommendation surfaces keep their frozen semantics untouched; a NEW, separately versioned OpenAI-compatible execution surface is introduced (never silently added to v1).
D-030/D-031 (REST/MCP local, no authentication) — amended for the containerized SERVER component only: it exposes authenticated interfaces with separate administrator / inference-client / worker identities. Local CLI, loopback REST v1 and stdio MCP keep today's boundary unchanged.
D-009 (Security defaults) — extended: the new network exposure, credential storage and listener defaults each get an explicit security decision in docs/security.md.
AGENTS.md "Product boundary", docs/product.md non-goals and README boundary text — rewritten to the two-mode product; every invariant that remains true (security invariants, provider-edge discipline, quota-never-changes-capability, licensing) stays unchanged.

Scope

Update docs/architecture.md, docs/product.md, docs/security.md, docs/machine-interfaces.md, docs/providers.md, docs/capacity-model.md, docs/selection-policy.md, docs/roadmap.md, AGENTS.md, README.md and docs/decisions.md to the two-mode product.
Define the module map and dependency direction as logical module boundaries, NOT microservices: Resource State/Registry/Collectors; Routing Core (pure, deterministic); Execution Coordinator (admission, concurrency reservation, dispatch, streaming lifecycle, cancellation, observed usage/accounting); HTTP/Worker adapters (communication with concrete execution surfaces); Public interfaces (OpenAI-compatible execution + existing recommendation-only MCP/REST/CLI). One server component; one native worker component; no new containers/databases/deployed services per boundary.
Define the contracts: request contract; route-decision contract (separating physical model/variant, execution channel/surface, entitlement, shared quota pool and client routing profile); state contract (versioned snapshots); execution contract (dispatch/stream/cancel/usage); worker protocol contract (versioned, outbound TLS/WSS); entitlement/quota model (direct observation vs provider telemetry vs estimates vs local limits vs unknown); OpenAI compatibility model (per-adapter/adapter-version/model matrix: roles and conversation history, streaming, tool_calls, tool results, structured output, reasoning controls, context limits, error semantics, usage reporting, cancellation); threat model; supported deployment topologies; migration plan.
Resolve: minimum worker transport (simple versioned protocol over TLS/WSS; no inbound worker port, no manual IP configuration, no routine certificate maintenance for ordinary users); durable-state requirements (prefer minimal durable state, e.g. SQLite, only where the analysis supports it); pairing/trust bootstrap model; client profiles and authorization; stable vs experimental integration boundaries (ZCode may remain experimental/disabled by default).
Freeze the authorization precedence: administrator constraints > client authorization > request requirements > configured routing profile > explicitly selected target/model > optimization preferences. A client override may narrow permissions and must never expand authorization, provider access or spending limits. Profiles/aliases may simplify base_url+api_key+model clients but never replace the full requirement contract; reuse the existing task/profile model — no second simplified scoring system, no mandatory LLM request classifier. If the caller explicitly requests a concrete model/effort/target, it is never silently replaced.
Define how a client that first uses MCP select can subsequently execute the selected target through the gateway without triggering an unexpected second routing decision, and freeze that a recommendation is not automatically a reservation, a capacity guarantee or an execution guarantee.
Map existing files/modules to future changes; do not impose a new directory tree without evidence; preserve the current implementation language, core code and package structure where practical.
Distribute the program security requirements to M03 (ingress), M04 (outbound provider HTTP), M05 (worker transport), M06/M07 (local runtime integrations), M09 (administration) and M10 (E2E verification), and freeze the minimal audit-metadata contract: request id, decision id, client/profile identity, routing-policy version, state snapshot identity/version, selected target, actually executed target, adapter version, start/end time, result status, provider-reported usage, estimated usage where applicable — with no sensitive prompt/response contents in the default audit trail.

Non-goals

No implementation of gateway, worker or adapters inside A0.
No Redis/Kafka/Kubernetes/plugin marketplace/Electron application/complex multi-tenancy without demonstrated need; no rewrite unless the analysis proves one necessary.
No scarcity run <task>-style interface; no reset-card redemption or similar benefit-consuming actions (they remain information unless a separate explicit decision authorizes acting on them); no general task scheduler; an execution mode with undefined/unbounded start time must not silently replace a synchronous HTTP request.
No Creatidy-specific workflow rules imported into this repository.
No invented deadlines, assignees or milestone structures.

Contracts / interfaces affected

Machine-interface v1 (preserved; additive changes only per D-028 versioning rules), a new versioned OpenAI-compatible execution surface (new contract), worker protocol (new contract), catalog/policy artifacts (additive evolution per the D-032 compatibility discipline), capacity contract v3 (preserved; extensions only via explicit versioning), ExecutionEligibility v1 (preserved, D-039).

Dependencies

None — this issue is the program root. M06/M07 Stage-1 feasibility evidence may inform A0 but does not block it; A0 must not wait for adapter implementations, and adapter implementation issues must not wait for A0 beyond their declared dependency edges (the Forgejo dependency graph encodes this DAG; Stage-1 research in M06/M07 is explicitly exempt from those edges).

Acceptance criteria

docs/decisions.md records the superseding decisions above with provenance, date/version, confidence, rationale and human-reviewable diffs; no decision is changed silently.
Documentation no longer contains contradictory product-boundary rules; recommendation-only operation remains documented and supported everywhere.
The architecture documentation defines every module's responsibility boundary and input/output contracts, and each module issue (M01–M10) references them.
Every risk involving local CLI/app integrations is resolved through explicit verification tasks/tests (M06/M07), never assumptions.
The threat model covers: separate credentials/permissions for administrator, inference clients and workers; revocation; verified TLS; simple trust bootstrap; no verify=false; no shared default password; no bearer secrets in URLs; request-body, context/output, concurrency, execution-time and spending limits; router-loop protection (router → router → router); provider credentials bound to configured origins; SSRF protection; no Authorization forwarding across unsafe redirects; explicit bounded localhost-HTTP exceptions only where justified; no generic shell API; no root/Administrator execution by default; no Docker socket mounting; no arbitrary repository mounting; no uncontrolled client-supplied subprocess flags/environment variables; session, filesystem and tool isolation; no accidental import of unrelated conversation history or global plugins; no prompt/response logging by default; no secret logging; redacted diagnostics; minimal audit metadata with bounded retention; logs created by local runtimes accounted for; provider subscription/promotional terms respected; several apps owned by one user must not automatically imply the right to share one personal subscription with multiple independent users.
No circular dependency between A0 and the adapter implementation issues (M06/M07 stage 2 depend on A0; their stage 1 does not).
A0 may complete before all module implementations; the program map links all module issues.

Security considerations

A0 defines the boundaries only (see threat model above); implementation lands in the module issues. No credential values, account identifiers or prompt content may appear in any A0 document, example or fixture.

Risks

Scope creep toward an agent framework — mitigated by the explicit non-goals and recommendation-only default.
Contract churn in frozen v1 surfaces — mitigated by the D-028 additive/versioning rules.
Provider-terms exposure for subscription/promotional usage through execution adapters — mitigated by M06/M07 evidence gates and U-009.

Evidence still required

Worker transport/protocol choice evidence (kept minimal per the constraints above).
Durable-state requirements evidence before choosing any store beyond current defaults.
OpenAI compatibility matrix evidence per adapter/backend (M03/M06/M07), with dated, versioned sources.

Validation gate (unchanged)

uv sync --only-dev && make check && uv run basedpyright && git diff --check for any documentation PR; one feature branch from develop, one PR targeting develop, left open for human review.

## Goal Produce the coherent architecture specification for the owner-approved **optional execution gateway** extension — without a rewrite and without breaking recommendation-only operation — and record the superseding product decisions that authorize it. This is the program-map issue for the execution-gateway program. The module issues M01–M10 are separate Forgejo issues (linked in the program map below and via Forgejo dependencies). A0 is documentation/contract work only; it implements no runtime behavior. Analysis baseline: `develop` @ `fce4311b934771f0005cada53163864790edd0e2` (2026-09-19). ## Program map (module issues) | Planning id | Forgejo issue | Scope | | --- | --- | --- | | A0 | #85 | This issue — architecture, decisions, contracts | | M01 | #86 | Resource registry, state, and collectors for executable resources | | M02 | #87 | Routing core, policy, and client-requirement binding for executable targets | | M03 | #88 | OpenAI-compatible gateway and execution coordinator | | M04 | #89 | Generic OpenAI-compatible HTTP adapter and Ollama integration | | M05 | #90 | Native worker, pairing, and execution transport | | M06 | #91 | Codex adapter: CLI/App Server with Desktop and VS Code installations | | M07 | #92 | ZCode adapter: feasibility proof and experimental integration | | M08 | #93 | MCP, REST, and CLI compatibility; optional remote mode | | M09 | #94 | Configuration, web UX, and diagnostics | | M10 | #95 | Distribution, installation, update, and end-to-end acceptance | Dependency edges (blocked-by, cycle-free): M01→A0; M02→A0; M03→A0,M01,M02; M04→A0,M03; M05→A0,M03; M06→A0,M05 (stage 2 only; stage 1 verification exempt); M07→A0,M05 (stage 2 only; stage 1 verification exempt); M08→A0; M09→A0,M03; M10→A0,M01,M02,M03,M04,M05. Recommended first useful execution vertical slice: M01/M02 → M03/M04, with the minimum M09/M10 support each slice needs — a user should be able to use real API/Ollama resources through one OpenAI-compatible endpoint before all local CLI adapters are complete. Then M05 and M06; M07 runs as an independent research/integration track; M08 guards compatibility throughout; M09 and M10 contribute their per-slice minimums rather than being postponed entirely. ## User value A user can point any OpenAI-compatible client (one `base_url`, one client API key, one model/profile identifier) at a single Scarcity Router endpoint and have requests served from the best available authorized resource — API providers, Ollama/local inference, or approved local Codex/ZCode adapters — under the existing least-scarce-capable routing discipline, while every existing recommendation-only user and interface keeps working unchanged. ## Product decision being implemented (owner-approved, 2026-09-19) Scarcity Router remains one independent Apache-2.0 OSS repository and gains an OPTIONAL execution gateway alongside recommendation-only mode. This intentionally supersedes the previous blanket prohibition on inference proxying and the removal of Ollama support. It does NOT remove recommendation-only mode, does not turn Scarcity Router into an autonomous coding/agent framework, does not grant arbitrary command execution on hosts, and does not build issue-to-PR orchestration, repository management or a generic agent workflow framework. Repositories and client-side tools remain controlled by the client; SSH is a way a user may reach a machine, not a router orchestration protocol. The goal is efficient use of heterogeneous AI access: subscriptions, eligible promotions, metered APIs, prepaid APIs and local models/local GPU. The same model name must not be assumed to mean the same resource, entitlement, quota pool, cost model or promotional eligibility. ## Relationship to current code (what exists today) - Recommendation-only core: `scarcity_router/selector.py`, `scarcity.py`, `policy.py`, `selection_types.py`, `simulation.py`, `selection_app.py` (balanced selector; catalog v3 with nine calibrated identities; policy v8; capacity contract v3; machine-interface v1). - Interfaces: CLI (`cli.py`: `status`/`select`/`simulate`/`install-config`), loopback REST (`server.py`: `/healthz`, `/v1/status`, `/v1/select`, `/v1/simulate`), stdio MCP (`mcp.py`: `scarcity_status`/`scarcity_select`/`scarcity_simulate`), shared logical parsing in `machine_api.py`. - Collectors: OpenAI Codex app-server (`providers/openai_codex*.py`) with the D-039 `ExecutionEligibility` contract (`eligibility.py`, `providers/openai_eligibility.py`), Z.ai Coding Plan (`providers/zai*.py`). - Packaging: `scarcity-router` 0.1.0 wheel with three console scripts (D-034); default user config `~/.config/scarcity-router/selector-policy.json` (D-036). - Explicit prohibitions today: D-001 (recommend, do not proxy), D-017 (no local inference), D-028/D-030/D-031 (loopback-only unauthenticated machine interfaces; MCP recommendation-only), AGENTS.md "Product boundary", `docs/product.md` non-goals, `docs/security.md` invariants. Related but NOT repurposed: issue #82 / decision D-039 (execution-eligibility telemetry) is merged work this program builds on; its scope is complete and it remains a separate open issue for its own closeout. ## Existing decisions and documents that A0 must supersede or amend (explicit list) Superseding decisions are recorded in `docs/decisions.md` with the next free D-numbers; history is never rewritten: 1. **D-001 (Recommend, do not proxy)** — superseded in part: an optional execution gateway may receive prompts and execute/proxy model traffic. Recommendation-only remains the default standalone mode. 2. **D-017 (Local Ollama support removed)** — superseded: Ollama/local inference returns as an execution resource (server-direct over HTTP, or worker-bridged when localhost-only). The D-017 removal rationale (local-runtime operational instability) remains a design input for isolation, health handling and honest unknown states. 3. **D-028 (machine-interface contract) and the `docs/machine-interfaces.md` non-goals** — amended: the existing v1 recommendation surfaces keep their frozen semantics untouched; a NEW, separately versioned OpenAI-compatible execution surface is introduced (never silently added to v1). 4. **D-030/D-031 (REST/MCP local, no authentication)** — amended for the containerized SERVER component only: it exposes authenticated interfaces with separate administrator / inference-client / worker identities. Local CLI, loopback REST v1 and stdio MCP keep today's boundary unchanged. 5. **D-009 (Security defaults)** — extended: the new network exposure, credential storage and listener defaults each get an explicit security decision in `docs/security.md`. 6. **AGENTS.md "Product boundary", `docs/product.md` non-goals and README boundary text** — rewritten to the two-mode product; every invariant that remains true (security invariants, provider-edge discipline, quota-never-changes-capability, licensing) stays unchanged. ## Scope - Update `docs/architecture.md`, `docs/product.md`, `docs/security.md`, `docs/machine-interfaces.md`, `docs/providers.md`, `docs/capacity-model.md`, `docs/selection-policy.md`, `docs/roadmap.md`, `AGENTS.md`, `README.md` and `docs/decisions.md` to the two-mode product. - Define the module map and dependency direction as logical module boundaries, NOT microservices: Resource State/Registry/Collectors; Routing Core (pure, deterministic); Execution Coordinator (admission, concurrency reservation, dispatch, streaming lifecycle, cancellation, observed usage/accounting); HTTP/Worker adapters (communication with concrete execution surfaces); Public interfaces (OpenAI-compatible execution + existing recommendation-only MCP/REST/CLI). One server component; one native worker component; no new containers/databases/deployed services per boundary. - Define the contracts: request contract; route-decision contract (separating physical model/variant, execution channel/surface, entitlement, shared quota pool and client routing profile); state contract (versioned snapshots); execution contract (dispatch/stream/cancel/usage); worker protocol contract (versioned, outbound TLS/WSS); entitlement/quota model (direct observation vs provider telemetry vs estimates vs local limits vs unknown); OpenAI compatibility model (per-adapter/adapter-version/model matrix: roles and conversation history, streaming, `tool_calls`, tool results, structured output, reasoning controls, context limits, error semantics, usage reporting, cancellation); threat model; supported deployment topologies; migration plan. - Resolve: minimum worker transport (simple versioned protocol over TLS/WSS; no inbound worker port, no manual IP configuration, no routine certificate maintenance for ordinary users); durable-state requirements (prefer minimal durable state, e.g. SQLite, only where the analysis supports it); pairing/trust bootstrap model; client profiles and authorization; stable vs experimental integration boundaries (ZCode may remain experimental/disabled by default). - Freeze the authorization precedence: administrator constraints > client authorization > request requirements > configured routing profile > explicitly selected target/model > optimization preferences. A client override may narrow permissions and must never expand authorization, provider access or spending limits. Profiles/aliases may simplify `base_url`+`api_key`+`model` clients but never replace the full requirement contract; reuse the existing task/profile model — no second simplified scoring system, no mandatory LLM request classifier. If the caller explicitly requests a concrete model/effort/target, it is never silently replaced. - Define how a client that first uses MCP `select` can subsequently execute the selected target through the gateway without triggering an unexpected second routing decision, and freeze that a recommendation is not automatically a reservation, a capacity guarantee or an execution guarantee. - Map existing files/modules to future changes; do not impose a new directory tree without evidence; preserve the current implementation language, core code and package structure where practical. - Distribute the program security requirements to M03 (ingress), M04 (outbound provider HTTP), M05 (worker transport), M06/M07 (local runtime integrations), M09 (administration) and M10 (E2E verification), and freeze the minimal audit-metadata contract: request id, decision id, client/profile identity, routing-policy version, state snapshot identity/version, selected target, actually executed target, adapter version, start/end time, result status, provider-reported usage, estimated usage where applicable — with no sensitive prompt/response contents in the default audit trail. ## Non-goals - No implementation of gateway, worker or adapters inside A0. - No Redis/Kafka/Kubernetes/plugin marketplace/Electron application/complex multi-tenancy without demonstrated need; no rewrite unless the analysis proves one necessary. - No `scarcity run <task>`-style interface; no reset-card redemption or similar benefit-consuming actions (they remain information unless a separate explicit decision authorizes acting on them); no general task scheduler; an execution mode with undefined/unbounded start time must not silently replace a synchronous HTTP request. - No Creatidy-specific workflow rules imported into this repository. - No invented deadlines, assignees or milestone structures. ## Contracts / interfaces affected Machine-interface v1 (preserved; additive changes only per D-028 versioning rules), a new versioned OpenAI-compatible execution surface (new contract), worker protocol (new contract), catalog/policy artifacts (additive evolution per the D-032 compatibility discipline), capacity contract v3 (preserved; extensions only via explicit versioning), `ExecutionEligibility` v1 (preserved, D-039). ## Dependencies None — this issue is the program root. M06/M07 Stage-1 feasibility evidence may inform A0 but does not block it; A0 must not wait for adapter implementations, and adapter implementation issues must not wait for A0 beyond their declared dependency edges (the Forgejo dependency graph encodes this DAG; Stage-1 research in M06/M07 is explicitly exempt from those edges). ## Acceptance criteria - [ ] `docs/decisions.md` records the superseding decisions above with provenance, date/version, confidence, rationale and human-reviewable diffs; no decision is changed silently. - [ ] Documentation no longer contains contradictory product-boundary rules; recommendation-only operation remains documented and supported everywhere. - [ ] The architecture documentation defines every module's responsibility boundary and input/output contracts, and each module issue (M01–M10) references them. - [ ] Every risk involving local CLI/app integrations is resolved through explicit verification tasks/tests (M06/M07), never assumptions. - [ ] The threat model covers: separate credentials/permissions for administrator, inference clients and workers; revocation; verified TLS; simple trust bootstrap; no `verify=false`; no shared default password; no bearer secrets in URLs; request-body, context/output, concurrency, execution-time and spending limits; router-loop protection (router → router → router); provider credentials bound to configured origins; SSRF protection; no `Authorization` forwarding across unsafe redirects; explicit bounded localhost-HTTP exceptions only where justified; no generic shell API; no root/Administrator execution by default; no Docker socket mounting; no arbitrary repository mounting; no uncontrolled client-supplied subprocess flags/environment variables; session, filesystem and tool isolation; no accidental import of unrelated conversation history or global plugins; no prompt/response logging by default; no secret logging; redacted diagnostics; minimal audit metadata with bounded retention; logs created by local runtimes accounted for; provider subscription/promotional terms respected; several apps owned by one user must not automatically imply the right to share one personal subscription with multiple independent users. - [ ] No circular dependency between A0 and the adapter implementation issues (M06/M07 stage 2 depend on A0; their stage 1 does not). - [ ] A0 may complete before all module implementations; the program map links all module issues. ## Security considerations A0 defines the boundaries only (see threat model above); implementation lands in the module issues. No credential values, account identifiers or prompt content may appear in any A0 document, example or fixture. ## Risks - Scope creep toward an agent framework — mitigated by the explicit non-goals and recommendation-only default. - Contract churn in frozen v1 surfaces — mitigated by the D-028 additive/versioning rules. - Provider-terms exposure for subscription/promotional usage through execution adapters — mitigated by M06/M07 evidence gates and U-009. ## Evidence still required - Worker transport/protocol choice evidence (kept minimal per the constraints above). - Durable-state requirements evidence before choosing any store beyond current defaults. - OpenAI compatibility matrix evidence per adapter/backend (M03/M06/M07), with dated, versioned sources. ## Validation gate (unchanged) `uv sync --only-dev && make check && uv run basedpyright && git diff --check` for any documentation PR; one feature branch from `develop`, one PR targeting `develop`, left open for human review.

kilo referenced this issue

2026-09-19 13:05:47 +00:00

M01: Resource registry, state, and collectors for executable resources #86

kilo referenced this issue

2026-09-19 13:05:47 +00:00

M02: Routing core, policy, and client-requirement binding for executable targets #87

kilo referenced this issue

2026-09-19 13:06:31 +00:00

M03: OpenAI-compatible gateway and execution coordinator #88

kilo referenced this issue

2026-09-19 13:06:31 +00:00

M04: Generic OpenAI-compatible HTTP adapter and Ollama integration #89