Skip to content
All entries
ADRArchitectureReasoningRelease notes

ADR-016 “Managed Reasoning Loop” — accepted and Waves S/1/2/3 delivered

Skills were acting independently and the orchestrator wasn’t compounding context. ADR-016 keeps ADR-014’s invariant — the model never controls the session — and replaces the over-implementation with a managed loop: policy defines the space, the model reasons within it, code verifies the result.

The product owner, completing real reflections, reported that outcomes were not compounding: skills acted independently and the orchestrator was not proactively gathering context, closing life-graph gaps, or moving toward 20-year / 12-month plan recommendations. Root-cause analysis confirmed three structural facts: 1. Every conversational skill received only `theme` + `userMessage` — amnesiac turns, no confirmed self-model, goals, or open hypotheses in the prompt. 2. Skill selection was a pure function of turn count and feedback, blind to the D1 coverage engine and D2 agenda (which existed but fed only the agenda route). 3. `insight-to-plan` was an explicit placeholder ("no LLM text generation here"). The diagnosis: ADR-014’s true invariant — *the model never CONTROLS the session* — had been over-implemented as *the model never INFORMS the session*. ADR-016 (accepted 2026-07-08) keeps the invariant and replaces the over-implementation with a managed reasoning loop: policy defines the space, the model reasons within it, code verifies the result. Free-form agentic orchestration was re-rejected on ADR-014’s original grounds; per-skill private memories (as literally requested) were rejected as shadow-profile risk in favour of one shared, policy-filtered, user-visible context. --- Environment defects fixed on the way in --- Two environment defects were found and fixed on the way in: • The pen-test H4 remediation had left the admin console dark for the owner (`PLATFORM_ADMIN_USER_IDS` unset → fail-closed allowlist; owner id added to env). • This local database’s public-schema default privileges had been altered outside any migration, silently stripping `service_role` DML from all twelve tables created after 2026-07-05 — the admin console’s empty skills list, "Eval run failed", missing ops telemetry, and silently failing background scans were all this one defect. Migration `20260708000100_restore_service_role_grants.sql` makes the grants explicit (idempotent, deny-all to `anon`/`authenticated` untouched) and restores the future-table default for `service_role` only. The `AdminSkillsPanel` also no longer renders an empty list on a load error (it says so).

Last updated Aug 3, 2026