September 2026 Runtime Adoption Decisions

Reviewed on 2026-09-12 against VISION.md and the current implementation. The proposals remain accessible in their closed pull requests; neither proposal is an approved implementation backlog or a shipped capability inventory.

MAF implementation proposal — declined

PR #1136 proposes a broad tool-loop budget change and a generic retrieval layer. Do not adopt either package now.

• Converting limit exits into completed runs needs a separately established incomplete-work contract. Hitting a budget is not evidence of completion. New default deadlines, persisted cumulative budgets, migrations, and settings across clients are disproportionate without an observed workload requiring them.
• A collection registry, filter language, store abstraction, and parallel in-memory store add maintenance obligations without demonstrated retrieval quality or latency gains. Keep the existing PostgreSQL retrieval paths and visibility rules. Shared helpers and indexes should follow measured needs.
• The claimed Wiki query mismatch is already handled: handleWikiSearch accepts both search and query, including the context-search fan-out.
• New search tools and secret wrappers are not required to resolve a verified regression in this proposal. No MAF dependency is introduced.

Hermes adoption review — one focused change accepted

PR #1137 contains several distinct ideas. Adopt only the autonomous completion judge's provider-fallback restriction. The judge already selects the effective run model, but previously allowed the provider loop to fall back again. It now sets allowFallbacks: false and requires exact canonical model resolution after the provider configuration refresh, so a removed/disabled model cannot silently resolve to a default provider. Errors retain the existing unavailable/uncertified diagnostics. The orchestrator goal judge already uses a no-fallback inference path.

The remaining packages are declined for this change:

• SQLite recovery mechanisms do not apply to the PostgreSQL datastore. Search error handling and health probes need fault-specific evidence: broad fail-open catches can hide structural failures, and liveness should not depend on a routine database mutation. Do not import the proposed resilience campaign. The specific assertion-search syntax-error claim is also incorrect: searchApprovedAssertions uses websearch_to_tsquery, which accepts raw input without syntax errors, and that query has no vector fallback arm.
• Child-process credential exposure deserves a separate isolation design, but an environment allow-list is not a security boundary for a same-user shell with filesystem access. Current persisted shell runs already replace the internal proxy token with a run-scoped capability and clear AUTH_SECRET. Other inherited credentials and accessible credential files remain a risk; this change does not fix or claim to isolate them. Removing global Codex refresh write-back also requires validating all refresh consumers and child authentication paths, not just deleting assignments.
• A browser vault, unattended TOTP, and password-manager integrations add a sensitive product surface without an established workflow requirement. Keep the existing human sign-in flow. Mailbox encryption and output redaction are separate security concerns, not justification for building a vault.
• Cross-turn billing circuits need provider/model-specific recovery semantics: a credential-wide entitlement block can suppress models still available on the same account. Do not add the proposed circuit or reporting UI speculatively.
• Existing provider attribution, provider-scoped model limits, and persisted steering do not require adopting another framework's mechanisms.

The accepted change is runtime-only. Web, iOS, and macOS share that backend; there are no new controls, strings, tool schemas, or client-specific surfaces.