docs: volition, planning, agency and cognitive research

New documents define goal, want, intention, commitment, plan, action,
capability, authority, agency and introspection operationally, state
prominently that no operational measure establishes phenomenal
consciousness or sentience, and describe the rules, thresholds, events,
inspection points and limits of each subsystem:

- docs/volition.md: want derivation, reinforcement, decay and suppression,
  conflicts, formation and its outcomes, the intention–action gap,
  reconsideration, commitments and volition metacognition;
- docs/planning.md: plans and step kinds, validation, strategies, the
  executor, observe–act–verify, replanning, budgets, operator attention,
  long-running work, restarts and duplicates;
- docs/agency.md: the fifteen authority invariants and their tests,
  scoped authority, forensic why, attribution and the agency timeline;
- docs/cognitive-research.md: operational definitions separating
  implementation property from philosophical interpretation, experiment
  protocols (global workspace, ablation, self-model, counterfactual, model
  comparison, conflict), every measure, introspection accuracy,
  metacognitive calibration and temporal self-continuity.

Updated: interpretation table, capabilities (metadata, typed operations,
scoped grants, requests), cognition, snapshots (fork authority), security
and threat model (T14, T16, new T27–T29), architecture, README, changelog,
release notes, ADR-0012 and ADR-0013, and PLAN.md §8.10 status. The
unimplemented record_procedure internal step is removed from the
vocabulary; procedural memory is recorded when a plan completes.

docs/adr/0012-volition.md

@@ -0,0 +1,26 @@
+# ADR-0012: Wants, intentions and commitments as separate recorded states
+
+Date: 2026-09-15  
+Status: Accepted
+
+## Context
+Until 0.2 a request mapped straight to a capability invocation, and goals were the only motivational record. Nothing recorded that the mind wanted something, whether it decided to pursue it, what normative constraints applied, or why a strong want led to no action. Explanations of behaviour would have had to be reconstructed after the fact, which is exactly the fluent, unsupported self-description Noema is meant to avoid.
+
+## Decision
+- Keep four states distinct, in their own tables with their own events: **wants** (preference with origin, decaying strength, urgency, optional means), **intentions** (decision with sources, expected result, priority, status and blocked reason), **commitments** (do/refrain over matched actions, optional "unless approved", weight from kind, due, expiry, revocability) and **actions** (what the capability layer recorded).
+- Derive wants, resolve conflicts, form intentions, check commitments and reconsider intentions with pure Go functions over plain inputs (`internal/volition`), and store every choice, including non-formation, with its terms in an append-only decision ledger.
+- Let attention gate formation: an `intend` candidate competes for the workspace, so what the mind decides to pursue depends on the same competition as everything else, and ablations of attention or the workspace are measurable.
+- No fixed hierarchy between wants and commitments. Conflicts are resolved by recorded scores in which commitments contribute normative weight, goals priority and urgency scales strength. Value-derived wants (caution, privacy) oppose actions explicitly and can constrain an approach to the approved route.
+- Commitments restrict only. A refrain-unless-approved commitment sets `RequireApproval`, turning ALLOW into ASK; nothing in volition can loosen a decision.
+- Represent the intention–action gap: a blocked intention names what it waits for, and a subordinate intention records the waiting (obtain approval, obtain access).
+
+## Consequences
+- "What did the mind want, which wants conflicted, which won and why" is a query, and so is "why did it not act".
+- Formation weights are hand-set; they are recorded, not claimed to be right, and can be studied with experiments.
+- More events and rows per interaction; thresholds, reinforcement, decay and a cap on active wants bound accumulation.
+- Explicit request recognition is literal English; other requests produce wants without means.
+
+## Alternatives considered
+- Asking a model whether to act: rejected; decisions about pursuit and constraints must be deterministic and replayable.
+- Commitments as policy rows: rejected; policy is authority outside cognition, commitments are cognitive state and must never grant.
+- A single "intent" record with flags: rejected; the distinctions (wanting without intending, intending without authority) are the point.

docs/adr/0013-planning-execution.md

@@ -0,0 +1,26 @@
+# ADR-0013: Validated plans and a stateless, restart-safe executor
+
+Date: 2026-09-15  
+Status: Accepted
+
+## Context
+Intentions need multi-step work: diagnose before acting, ask for access, act, check the result, try something else. The obvious designs are an agent loop that lets a model call tools until it is satisfied, or an in-memory workflow engine. The first puts authority and state inside a model; the second loses state on restart and invites duplicate actions.
+
+## Decision
+- A plan is a stored dependency graph of typed steps (capability, request capability, verify, monitor, wait, internal) with expectations, preconditions, assumptions, budget, completion criteria, abort conditions and the alternatives considered. Replans are new revisions; the old plan is kept and linked.
+- Validation is Go: acyclic dependencies, registered and unlocked capabilities only, schema-valid parameters, targets derived from parameters, read-only checks, closed vocabularies. Model proposals are parsed into the same structure and validated; fields claiming approval or completion are ignored and reported.
+- Deterministic strategies first (direct action with verification, diagnosis with a scoped log request, escalation that does not repeat a failed action); a model only when none applies; failed strategies are not reused.
+- The executor holds no plan state in memory. It claims a step with a conditional update, acts only through `capabilities.Service.Invoke` or `RequestCapability`, records the outcome and moves on. Every status transition is conditional on the expected previous status. A step found executing with an expired lease is resolved from records by origin; a non-idempotent step with no record is blocked for verification, never repeated.
+- Observe → act → verify: expectations become predictions with `verification` criteria, resolved by read-only observation; misses are prediction errors that weaken the supporting belief and trigger reconsideration.
+- Long-running steps persist their next run time; the executor is one scheduler-owned loop woken after cycles and by the event bus.
+
+## Consequences
+- A restart, a duplicate scheduler or a second daemon cannot run a step twice, and a crash mid-action cannot lead to a blind repetition.
+- Plans are inspectable as graphs with estimates, alternatives and validation, and every action links back to its step, plan and intention.
+- The deterministic strategies are narrow; broader objectives need model proposals, which may fail validation and then never run.
+- Verification is built in only for `service.restart`.
+
+## Alternatives considered
+- Model-driven tool loops: rejected; they make the model the authority and the storage of reasoning state.
+- An in-memory engine with checkpoints: rejected; checkpoints between an action and its record are exactly where duplicates come from.
+- Unconditional status writes with a global lock: rejected; conditional updates give the same safety without a lock and work across processes.