RedinGhost/intent-loop

1# Frozen product baseline2 3Status: frozen before source implementation on 2026-08-28.4 5## Definition6 7Intent Loop stays inside the current agent. Only when it matters, it uses one question, two or three comparisons, or one inexpensive sample to help the user form what they want while work proceeds, then hands the current version of intent back to that same agent.8 9The product maintains an updateable, traceable, disagreement-preserving current intent. It does not claim to discover one objectively true intent. The user and agent may each be wrong and need not reach consensus.10 11## Included semantic surface12 13- desired outcome;14- success and failure signals;15- hard and soft constraints;16- tradeoffs;17- unknowns;18- result feedback;19- unresolved disagreements.20 21Every claim carries at least `statement`, `role`, `epistemic_status`, `source_ref`, `scope`, inferred `confidence`, `valid_from`, `last_confirmed`, and `supersedes`.22 23`epistemic_status` distinguishes user-explicit statements, agent inferences, result or external evidence, unknowns, disputes, and superseded or invalidated material. Explicit means explicitly stated, not necessarily factually correct. Unknown and disputed records remain distinct.24 25## Architecture decision26 27The Codex MVP is one plugin containing:28 29- one Skill for intervention policy and normal-dialogue/manual entry points;30- one local MCP server for structured state;31- optional `SessionStart`, `UserPromptSubmit`, `PostCompact`, `Stop`, and `SessionEnd` hooks.32 33Hooks observe, restore compact context, or record candidate signals. They never block a user prompt, force another turn, or act as semantic judges. The MVP has a headless path and no rich-UI dependency. It does not use Codex App Server to build a client and never parses an unstable transcript file.34 35## Ownership boundary36 37Intent Loop owns intent versions, sources, unknowns, disagreements, invalidation, intervention advice, post-install history-signal filtering, compact handoff, and result feedback.38 39Codex continues to own reasoning, planning, research, coding, file and tool operations, permissions, safety, tests, verification, delivery, and sub-agent orchestration.40 41## History and long-term rules42 43- Only events visible after installation are used by default.44- Older history requires an explicit import and is never described as complete understanding.45- A single choice, acceptance, or silence does not establish a durable preference.46- A durable rule is either explicitly declared by the user or becomes a candidate after the same signal appears across at least three independent tasks and the user confirms it.47- Inferred durable preferences become stale after 90 days without confirmation and are not silently injected.48- Conflicts and stale records keep provenance and require review; they are not silently erased.49 50## Explicit non-goals51 52- prompt pack, intake form, one-shot task brief, PRD generator, or decision interceptor;53- full user model, digital twin, independent chat surface, or large workbench;54- replacement for Codex reasoning, planning, execution, tools, approvals, validation, or agents;55- Claude Code, Cursor, Gemini CLI, or WorkBuddy adapters in this release;56- automatic access to all pre-install history;57- efficacy claims based on calls, questions, fields, protocol prose, or green builds.58 59## Frozen release gates60 611. Gate 0: canonical repository and scope are safe.622. Gate 1: current Codex surfaces support the bounded architecture without private transcript access, Codex modification, App Server, or a new client.633. Gate 2: value is measurable from independent task outcomes and failure attribution.644. Gate 3: persistence, privacy, export, invalidation, deletion, and threat boundaries are testable before any real user data is stored.65 66The implementation may proceed after these gates. User pilot and cross-agent expansion remain separately gated.67