AOCI-CODE v0.2.0-rc1

AOCI-CODE v0.2.0-rc1 is built from 91e3936ff65b77e8166ae83efdeacf2a7b00a193.

The first 0.2.0 candidate: the speed work, the one-call closing, and
host-dialog approval, with the Legacy single-file write path retired. An entry
that changes a persisted preimage names the binary every machine then needs.

Upgrading from 0.1.x:

• A Legacy single-file index, an aoci.txt that carries its own Header and
  Entries, is read-only apart from a Managed Scope transaction;
  aoci cognition onboard migrates it.
• A tracked module named logs or run becomes a Missing Entry, because
  neither name is a built-in exclusion any more.
• The aoci baseline scope commands are gone; aoci scope covers them. A
  baseline scope transaction 0.1.x left pending is resumed with 0.1.x
  before the upgrade; this release reads its intent as an invalid scope
  receipt, which blocks the repository until it is moved out of
  .aoci/transactions.
• A repository initialized by this release uses sensitive_name_rules v2 and
  may declare a SQLite source. A 0.1.x binary answers such a repository with
  scope_change_required or refuses the declaration, so every machine that
  maintains it needs this release.

Changes:

• The Whole-Index maximum no longer refuses anything. An index may be read
  outside an Agent's context window, so its total size only names the budget
  status (healthy, near_budget, warning, exceeded): an Entry Apply, a
  Scope Change, check, the Guide, and cognition_optimization no longer
  stop when the Whole-Index passes max_tokens, and scope status no longer
  reports cognition_compression_required. In enforce mode the R and S limits
  still return an Entry over its limit to the model, and the Guide and
  next_commands for that stop now name the band
  (scope budget set --policy-file {policy_file}) instead of --max-tokens.
  No configuration or Baseline byte changes, so no repository needs a Scope
  Change; a 0.1.x binary still enforces the maximum on the same configuration.

• After a merge, a Code or Database Volume whose bytes no longer match the
  Baseline is restored together with the Root, every other Volume, and
  .aoci/baseline.json from one commit. The repair action of
  code_volume_unbaselined and database_volume_unbaselined used to say
  "restore them": restoring a Code Volume alone matched its own Baseline
  record while the Baseline still bound the other branch's sources, so an
  Entry that branch had re-authored went back to its older text and Maintain
  reported the repository aligned. Restored as one set, Maintain returns every
  source or table the restored Entries do not describe, after any Scope
  Change, Locale switch, or Observe review it names first. These two findings
  and meta_volume_baseline_drift no longer suggest re-establishing cognition
  through a Scope Change, because a Scope Change cannot rebaseline a formal
  Volume; root_volume_baseline_drift names it only for the Root an older
  Database Bootstrap left, the one Root drift a Scope Change reconciles.
  v0.1.x prints the old wording for every Volume; follow this one.

• Every batch of a cognition_optimization pass reports the floored S
  maximum. Since #146 only the batch that starts a pass carried an
  s_max_tokens floored by the Meta's S quota; the current batch delivered
  again and every later batch fell back to the machine default, under-reporting
  the limit Apply enforces wherever the Meta declares a looser quota. No
  identity or batch cut changes.

• aoci config set locale works on a Volumes v1 repository. It used to be
  refused once the index existed, so a repository created in one Locale
  could not move to the other without being rebuilt. The switch is one
  resumable transaction over the Root's #Locale line, the team
  configuration, and the Baseline record of the Root; the Meta, Code, and
  Database Volumes are guards and keep their bytes, so no Entry is rewritten.
  Locale is prospective: existing Entries keep their language, Entries
  created or updated afterwards use the new one, and the Maintain contract
  says so. A crash leaves locale-<id>.json under .aoci/transactions,
  which the same command resumes while every other command waits; a Root
  whose #Locale disagrees with the configured locale is the governance
  finding root_locale_mismatch, repaired by the same command; an absent
  team file takes the Root's explicit marker as the project Locale.
  init --locale on an existing Volumes repository points to this command.
  Ported from dignfei's Locale-switch transaction in #28 (tracked in #34)
  onto the Volumes layout.

• The managed AGENTS block says what to do once cognition is reliable: use
  it as the repository-level system context by default, read only the
  source, tests, configuration, and contracts the task directly needs, and
  widen that evidence only when a specific missing fact could change the
  answer; AOCI never replaces direct source evidence for the objects being
  changed. One sentence in both locales, under "Establishing, generating,
  and restoring cognition"; the rendered AGENTS.md and its golden follow.
  Condensed from dignfei's AOCI-first reading wording in #28 (tracked in
  #34); the runtime rules are unchanged.

• verify, check, and status on a Volumes repository tell a person
  what is misaligned and what to do next. verify opens with the verdict
  (Governance: aligned — 6 Entries cover 6 index-role sources, or the
  result and its finding count), then lists Missing, Stale, Orphan,
  Unbaselined, and review-pending Observe paths one per line, any other
  actionable finding, and a Next: line naming the command or Agent action
  that clears it; check prints the same lists under its verdict; status
  adds one Governance: line with the result and the drift counts, computed
  from the same governance facts through the fingerprint cache without
  saving it, and status --json carries them under governance. Until now
  the Volumes branch of verify printed "candidate structure is valid" and
  three hashes before exiting 1, check printed a token and a count, and
  status said nothing about alignment, so the paths behind a finding were
  reachable only through --json. The init Scope Proposal line renders its
  largest directories as text (./ (index 2, observe 0, exclude 0)) instead
  of Go struct syntax, scan says "one Maintain round" when it means one,
  and docs/getting-started.md says that init's own files count among the
  index files scan reports and which formal assets to commit.

• A declared, enabled database source counts in governance before its
  Database Volume exists. The absent-Volume branch of the shared governance
  facts assessed no sources at all, so a repository could run database source add, never snapshot it, and stay aligned: verify, check, Maintain,
  and Guide all said so while database cognition status alone said
  snapshot_or_repair_evidence. Now that source is an evidence_unavailable
  finding, the verdict is evidence_required with
  snapshot_or_repair_evidence as the next action (Maintain stops with the
  snapshot and accept commands), and accepted Evidence with the Volume still
  absent routes to bootstrap_database_cognition, which baseline accept
  runs itself under automation.mode=auto. Bootstrap needs only Code
  governance, so the verdict never blocks the command that clears it; a
  disabled source and an engine without a collector stay informational.
  Found on the SQLite walk-through, which also fixed what a person sees on
  that path: the unsupported_catalog_feature error names the operation and
  the table (operation=catalog_query_sqlite_check, object=t), database source --help names SQLite, and the aligned verdict counts Database
  Entries (6 Code Entries cover 6 index-role sources; 2 Database Entries are bound to accepted Evidence).

• The Legacy-to-Volumes migration walk-through, step by step from
  docs/upgrading.md, now reads right for a person. verify, check, and
  status on a Legacy repository say that the layout is read-only since
  0.2.0 and name aoci cognition onboard start --json; until now they said
  aligned and ready to commit, and verify's S-coverage note sent the reader
  to cognition_optimization, which refuses on that layout (the Legacy
  variant of the note now points past the migration). cognition onboard start and next print the next command under their human output instead
  of a next-action token alone, and onboard prepare prints what will be
  written, the terminal command with its phrase, the MCP-dialog route, and
  the apply command instead of the session JSON. The guide itself was wrong
  about one spelling: a completed mapping record's review_status and an
  authoring task's status are reviewed (the template starts them at
  pending), not semantic_reviewed; a host that followed the guide
  literally stopped at migration_authoring_task_status_invalid.

• A Managed Scope change that takes a file out of the Index now says what
  it leaves behind. The walk-through of 2026-11-01 approved "1 files losing
  Index coverage" in the host dialog, scope apply said applied, and
  verify, check, and Maintain then stood blocked on the file's Entry, which
  the change had turned into an orphan without a word; retiring cognition
  takes a reviewed candidate set, so the Entry is not removed, but scope apply (and activate, resume, rollback) now prints the orphaned
  Entries and the aoci remove-entry --path or aoci_remove_entry step
  that clears them. The approval summary reads "1 file losing Index
  coverage" for one file, the orphan heading verify prints covers a file
  that left the Index role, and scope rule add, update, remove,
  reset, and scope explain without their argument say which argument
  is missing instead of cobra's "accepts 1 arg(s), received 0".

• A person approves in a terminal by reading what the change does and
  answering yes. Every terminal confirmation (scope approve, scope safety approve, cognition bootstrap approve and rollback, cognition migration approve, rollback, and reversal approve) used to demand a
  phrase such as APPROVE MIGRATION <64-hex digest> typed exactly, which
  proved nothing the digest-bound approval record does not and was
  incomprehensible to anyone new to a terminal. The prompt now says in plain
  words what approving writes or restores, yes in any case approves,
  Enter or anything else rejects with "nothing was changed" and the next
  step, and --actor defaults to human-operator, so the approve and apply
  commands a paused scope activate or onboard prepare prints run as
  printed with no <id> to replace. The human output puts the host dialog
  first, when the team admits it, and the terminal second. The
  aoci-host-interaction/v1 contract keeps its shape; confirmation_phrase
  is now the word yes. Non-TTY callers, piped input, and --yes are
  refused as before.

• The final aoci_update_entry batch carries its own terminal proof. The
  Apply that brought the last batch to aligned used to prescribe Verify,
  Aggregate Check, and Guide as three more calls whose only purpose was to
  re-derive what that Apply had just computed. It now returns
  terminal_proof (terminal-proof/v1): the governance result, aligned,
  structure_valid, check_passed (Aggregate Check's verdict),
  guide_complete and guide_next_action (the Guide's), the composite
  identity, and the actionable findings, computed once from the governance
  fact set all three commands share. The next_action says the cognition
  closing is complete; next_commands no longer lists the three commands,
  and aoci check stays the CI gate. The shared facts rule over the
  write-side inspector: an Apply whose repository still holds a blocker,
  such as a Database Volume without accepted Evidence, answers
  aligned=false with the finding instead of the aligned the inspector
  alone used to claim. The runtime rules, the Maintain tool description, the
  init automation hint, the refresh-ready and observe-review messages, the
  Volumes and refresh specs, and the docs say the same; scenario N1 now pins
  the proof and checks that it agrees with the three CLI commands.

• Orphan Entries are dropped in the update batch. A Code orphan, an Entry
  whose file is gone or left the Index role, used to stop Maintain
  (explicit_orphan_remove_or_resolve_blocker) until the Agent removed each
  one with its own aoci_remove_entry call and called Maintain again: a
  rename of N files cost N+1 extra calls. Maintain now issues the batch with
  the orphans listed under orphan_remove_candidates, and aoci_update_entry
  takes an additive removals array (each item the path as listed) that
  drops them in the same transaction as the Entries it writes; with nothing
  to author, Maintain answers remove_orphans_in_update_batch and one call
  with removals alone closes them. A removal that is not a reported orphan
  is the repair_required finding removal_target_not_orphan (an unindexed
  path removal_target_missing) with zero writes. Verify, Check, and Guide
  report a Code orphan as authoring_required; a parallel sibling's applied
  record replays the removal; aoci_remove_entry still removes one orphan on
  its own, and a Database orphan still goes through it. Scenario B5 now
  removes the orphan in the batch and refuses a live Entry.

• The Observe review rides with the update batch. When Observe evidence
  (tests, lockfiles, fixtures) moved since the Baseline, Maintain used to
  stop with review_observed_evidence until the Agent called
  intent=observe_review and then Maintain again: two extra calls on the
  most common iteration, a source change with its test. Under a posture that
  lets the model acknowledge, and when there is a batch to issue, Maintain
  now answers authoring_required with the batch and the observe_review
  listing, whose confirm_request names the batch itself, and
  aoci_update_entry takes an additive observe_review: {review_digest, reviewed_by} that records the review through the same Scope transaction
  before the Entries are written, reported beside the outcome. A digest the
  current list no longer has is the zero-write repair_required finding
  observe_review_stale with the current listing in
  observe_review_current; nothing pending is a no-op. A review posture, a
  listing too long for the transport, a pending Scope Change, and a
  test-only change with nothing to author keep the stop and the
  intent=observe_review route, which stays. Scenario N2 now drives the
  batch with the review.

• The real-repository harness reports the two numbers a user waits on:
  first_build.rounds and calls_to_closing, every MCP call from the first
  Maintain to the Apply whose terminal_proof reports aligned, for the first
  build and for the update wave; it drops orphans through removals and
  confirms a pending Observe review through the batch, and it stops at that
  Apply instead of calling Maintain once more. On RuoYi (512 Entries) a
  first build is 15 rounds and 30 calls, a 60-file update wave 3 rounds and
  6 calls, with no command to run afterwards.

• Parallel batches are offered as the first-build lever. aoci scan says
  what parallel Agent sessions make of its estimate: under the team setting
  code_cognition_parallel_batches, the rounds each session takes, measured
  with the cut Maintain makes for that many siblings (parallel_batches and
  parallel_rounds under --json); at the default of one session, what
  four would take and the config set that turns it on. A Maintain that
  lists siblings carries one instruction line: hand each to its own Agent
  session, which fetches it by batch_id, authors, and applies it, and call
  Maintain again once every sibling is applied. Under a host whose
  subagents share the session's MCP server, a sibling fetched by batch_id
  alone carries only the contract's reference, so the line asks each
  subagent for include_instructions: true, which returns the complete
  authoring contract with its batch.

• A change to Observe evidence alone closes in two calls. When the
  observe_review acknowledgement leaves the repository aligned, its result
  carries the same terminal_proof a final Apply does and next_action
none, instead of asking for one more Maintain that would only say
  aligned.

• A second aoci cognition onboard apply of a completed onboarding answers
  with the result it recorded. It used to record the approval again, set the
  session back to apply_pending, and then fail on the recorded
  apply-result.json with onboarding_artifact_conflict, leaving a completed
  session that claimed an apply was still pending; a session an older binary
  left that way is put back to applied.

• The database acceptance command Maintain returns for evidence_required
  runs as printed once filled: it now reads database baseline accept --source {source} --snapshot-sha {snapshot_sha} --json, where it used to
  lack the required --snapshot-sha and was refused. aoci database snapshot prints the accept command with its digest filled in, the Guide at
  evidence_required carries the snapshot and accept commands and names the
  sources that owe Evidence, the status page suggests the snapshot, and the
  Next: line of verify and check names --source instead of a positional
  argument. A database command without --source names the declared
  sources instead of cobra's English required flag(s) "source" not set.

• aoci cognition onboard apply carries its terminal proof when it leaves the
  repository aligned: it returns terminal_proof (the same
  terminal-proof/v1 the final update batch carries) and no next_commands,
  and onboard status of a completed session names nothing to run. A session
  that still has governance work names the Guide. Every Legacy repository that
  moves to 0.2 passes this step once. The Legacy migration drill checks the
  proof and cross-checks it against the three CLI readers.

• aoci init on a fresh repository says what the first build costs
  before the first scan, the moment a narrower scope is still free: how
  many index files need an Entry, about how many Maintain rounds that takes,
  and what four parallel Agent sessions would make of it; from 20 rounds up
  it prints the exclusion example scan --dry-run prints. After the first
  scan, excluding a file that has no Entry yet is a coverage reduction a
  person approves, so the cost is worth reading before roles freeze. A
  one-file estimate reads "1 index file needs an Entry".

• aoci --help lists the five everyday commands first (init, scan,
  mcp, verify, check) under Everyday Commands and the rest under
  Additional Commands, and aoci scope --help sorts its seventeen
  subcommands into Policy, Inspect, and Transactions; the group titles are
  locale text assets like every other help string. docs/getting-started.md
  is rewritten as the first week in three steps: install and initialize,
  connect the Agent and build the index, keep it aligned.

• A non-Git container root reads each child Git repository through its own
  Git (#54): a directory below the root that holds a .git entry is no longer
  walked; its tracked, non-ignored untracked, and ignored paths come from
  git ls-files under the same hardened command and boundary checks as a root
  repository, so the child's .gitignore holds and a submodule inside it
  stays a boundary. Paths outside any child keep the name-only traversal, the
  container stays a non-Git root, and the Safe Inventory gains the additive
  child_repositories and child_repository_roots facts. A container indexed
  before this version sees its child-ignored files leave the inventory at the
  next scan.

• Incremental Overview delivery (L5) is implemented. aoci_overview takes
  delta_since, the scope_identity of the delivery the Host holds: after a
  passing Attestation and a probe pass over the current identity, the server
  answers delivery_mode=delta (or chunked_delta) with only the objects
  changed or added since that body, at their current ordinals, the removed
  identities in Metadata, and a Challenge drawn from the delivered objects
  that still echoes the complete identity facts; a passing delta Attestation
  re-anchors the base and a partial or failed one drops it; an unchanged base
  answers an empty delta without a proof. Without a base in the process, an
  unreliable base, a pending context_compaction, no probe pass, a delta
  past half the objects, or a delivery the server cannot retain, the call
  answers the complete scope with a named fallback_reason. The capability
  manifest lists overview_delta; scenario group M (six scenarios) drives it
  through the binary, and two conformance checks pin that delta_since is
  refused with check_only or a cursor.

• Spec: incremental Overview delivery (L5) was specified in the delivery
  contract first: an ordinary aoci_overview carrying
  delta_since=<scope_identity>, after a passing Attestation and a probe
  pass over the current identity, delivers only the objects changed, added,
  or removed since that body under the same framing and Chunk rules, is
  attested over exactly that delta, re-anchors on a pass and drops the base
  on a partial or failed Attestation, and answers the complete scope with a
  named fallback_reason without a base in the process, without the probe
  pass, during a compaction reload, or past half the objects; the
  conformance checks the implementation must ship are listed.

• Parallel current batches (L4) are implemented. Under the new team key
  code_cognition_parallel_batches (absent or 1 is the one-batch flow, byte
  for byte; ceiling 4; config set validates it; the capability manifest
  lists parallel_batches) one logical plan keeps up to N sibling batches
  outstanding: Maintain delivers the first as the current batch and lists the
  others under code_plan.siblings, aoci_maintain takes a sibling's
  batch_id and delivers it whole, and aoci_update_entry accepts the
  siblings in any order. A sibling's Apply is accepted when the plan preimage
  plus the applied siblings, replayed through the editor from the records
  each Apply leaves under .aoci/drafts/code-cognition, reproduce the
  current Code Volume; a second Apply arriving under the lock reprojects its
  Entries onto the first's postimage and succeeds. Any other change to the
  Volume, or to the Root, Meta, Database Volume or Scope identity, invalidates
  every outstanding sibling, and one target's source drift invalidates only
  the sibling holding it. remaining counts the targets no sibling holds.
  Scenario group L (six scenarios) and two conformance checks pin the
  contract's conformance list.

• The Legacy baseline scope refresh is gone: aoci baseline scope plan,
  preview, approve, apply, status, and resume, the
  internal/scoperefresh package, and the six baseline-scope-*/v1 artifact
  versions, which the capability manifest and the release manifest no longer
  list (baseline_scope_refresh leaves the planner, apply, and lifecycle
  capabilities; ordinary_legacy_scope_reduction leaves the terminal-approval
  lists). Every repository with a Managed Scope Baseline has answered
  baseline_scope_managed_scope_unsupported since rc20 and scope activate
  establishes Managed Scope for one without it, so no working route is lost.
  A scope-<id>.json intent of the retired family left under
  .aoci/transactions reads as an invalid scope receipt; move it out.

• The repository's own index has quality floors. scripts/check-index-quality.sh
  takes aoci --json index score and holds it to
  scripts/index-quality-floors.txt: no violation in any of the nine
  dimensions, at most 8 percent of C7+ Entries without an S, a healthy
  Whole-Index budget. CI runs it on every push (contracts-and-safety), a
  closure runs it after governance, and the ladder records it as
  index-quality. A floor only tightens without a reason in the commit
  message.

• index score reads a Cognition Volumes repository. Its nine dimensions
  keep their names and JSON shape; on Volumes they are projected from the
  governance facts verify and check report, so coverage and freshness
  count the Code drift (a held source is reported, never counted), token is
  the Whole-Index budget, escale is the E scale audit, and Code and Database
  objects are judged under their own Meta dictionaries. The JSON adds
  layout, volumes, and budget; a Legacy score is byte for byte what it
  was. status --deep stays Legacy-only.

• A quarterly dependency review joins the run-by-name ladder
  (dependency-review, the new quarterly cadence, overdue after 92 days).
  scripts/dependency-review.sh is a read-only report: the go directive
  against go.dev, every direct Go module against the module proxy, the
  openGauss connector pin against the tags upstream publishes, every GitHub
  Action pin against its newest release and the commit its comment claims,
  and the open dependabot proposals. It upgrades nothing; a bump stays a
  decision taken with its gate.

• A Maintain round issues more candidates on the same transport budget
  (L3; #127 in part). Measured on real trees under the default 24 KiB budget,
  candidates a round before and after: RuoYi 22 to 28 on a process's first
  round and 41 after it, excalidraw 24 to 34 and 47, a 13,850-file tree 20 to
  26 and 39; a first build of RuoYi (512 targets) takes 15 rounds where it
  took 29, excalidraw (798 targets) 19 where it took 34, no round over the
  budget. Four changes to the response and none to what a batch
  binds: a Code candidate no longer repeats batch_id (the batch is
  code_plan.batch_id, which aoci_update_entry.code_batch_id already
  names; Database candidates keep theirs, and a reader of
  candidates[].batch_id for Code reads code_plan.batch_id); the authoring
  contract (instructions, authoring_meta) travels once per server process
  and refresh generation and later rounds carry instructions_ref, with the
  additive aoci_maintain input include_instructions: true bringing it
  back and a completed context-compaction reload bringing it back by itself;
  the governance block leaves the four per-asset records off the wire, which
  cognition_receipt and code_plan already carry; and the budget reserves
  file_lines and expected_e at the width they will have, taken from the
  fingerprint cache, instead of the widest form. A candidate now binds the
  digest the governance verdict's own snapshot holds instead of reading every
  target again each round. The Guide and the scan estimate project the
  first round's shape, so a later round in the same process may issue more
  than the Guide showed.

• Every governance call on a large repository is about three times faster
  (#127 in part; measured by the new perf-track contract, 13,850 files: a
  Maintain 3.8 s to 1.3 s, verify 3.6 s to 1.1 s, the Guide 3.8 s to 1.5 s;
  1,297 files: a Maintain 0.80 s to 0.59 s, verify 0.79 s to 0.42 s). Three causes, none of them the file reads
  everyone assumed: the Managed Scope policy was evaluated over the whole
  tree twice per call, once for the verdict and once more inside the
  business-source manifest, which now takes the state the verdict already
  loaded; glob rules were matched through the regular-expression engine, whose
  backtracking took half of every call on a starter policy (20 rules times
  every path), and are now matched by a token program judged against the
  regexp definition by a differential test over 100,000 pattern-path pairs
  and a fuzz target; and the curation profile re-read every candidate to
  classify it, and now takes the binary verdict and the line count from the
  fingerprint it already had. A stat cache under .aoci/fingerprints.json,
  git-ignored and outside every identity, answers an unchanged file by size
  and mtime under git's racily-clean rule; AOCI_FINGERPRINT_CACHE=off
  disables it, and the status page and scan --dry-run never write it.

• Spec: parallel current batches (L4) are specified in the Cognition Volumes
  contract: a team key
  code_cognition_parallel_batches (absent or 1 is today's flow, ceiling 4),
  sibling batches cut from one logical plan against one plan preimage and
  delivered whole by batch_id, an Apply preimage rule relaxed exactly to
  "the plan preimage or an applied sibling's postimage" and proven by
  replaying the applied receipts onto the preimage bytes, invalidation of
  every outstanding sibling by any non-sibling change, and the conformance
  checks the implementation must ship.

• Code drift of a Volumes repository is computed in one place,
  volumegovernance.CodeDrift, and every reader consumes it: Verify, Check,
  the Guide, Maintain, Overview, the post-Apply inspector that each
  aoci_update_entry result reads, and scope status. Before, scope status
  detected on its own with a trimmed set of walk options and counted held
  sources (empty, binary, oversize, unreadable, curation-excluded) as
  authoring targets, so a tree whose only Entry-less index files were images
  read authoring_required there and aligned everywhere else. Its drift
  now lists them as skipped and curation_excluded, its authoring_targets
  counts what Verify counts, and drift_warnings carries the detector's
  warnings. A contract test lists the files allowed to call the detector
  directly, each with its reason (the Legacy readers, the writer that binds
  the active business Baseline), so a new private reader fails the suite;
  two more pin scope status and the inspector to the projection on a tree
  with stale, missing, orphan, and held sources.

• Within one server process, a governance call over an unchanged tree no
  longer evaluates the Managed Scope policy or decodes the Baseline and the
  fingerprint cache again: the evaluation is remembered by a digest of every
  input (policy, walk options, curation exclusions, root layout, the walked
  paths), the two documents by the digest of their bytes, so a stale answer
  is impossible and the memo is bounded by the roots a process serves.
  13,850 files: a Maintain 1.09 s on a process's first call, 0.50 s once the
  process has seen the tree; an Overview check 0.27 s. AOCI_PROCESS_MEMO=off switches it
  off; perf_calls.py now times a third, steady Maintain, since the first
  one creates .aoci/drafts and the second therefore sees a new path.

• Black-box: scripts/blackbox/perf_calls.py times every governance call a
  user waits on (scan, cold and warm Maintain, Overview check, verify, check,
  Guide, status) against a tree's file count, and realrepo.py reports the
  wall time of each tool inside its authoring rounds and of the terminal
  proof; the perf-track ladder contract runs the former over five local
  clones from 700 to 13,850 files, so a performance change is read against
  the previous release's numbers rather than claimed.

• Black-box and CI: the conformance suite reports the four receipt-bound
  attestation checks as SKIP, counted but not failing, when the host
  repository is not governance-aligned, instead of four false reds on every
  dirty tree; the scenarios page probe retries a timed-out connection once;
  the PostgreSQL integration job binds a free loopback port instead of 5432;
  fast-ci runs on pushes to v*-line branches; full-confidence splits
  the 55-minute linux-full job into linux-full (the gate and coverage),
  linux-blackbox (suites, upgrade axis, migration drill), linux-nightly
  (longrun, fuzz) and linux-bench.

• logs and run are no longer built-in runtime exclusions (#158, the
  second finding). The built-in rule keeps only names that never denote
  source (#100), and both do: internal/logs is a package, cmd/run a
  command, yet through v0.1.1 every path component of either name was hard
  excluded with no door. Log, PID and socket files stay excluded by suffix,
  pids and the PM2 and database runtime names stay built in. New
  repositories exclude a root logs/ or run/ through exclude_root_dirs,
  which init writes; an existing repository keeps its lists and its scope
  identity, and a tracked module of either name becomes a Missing Entry after
  the upgrade, authored like any new source or kept out by adding the name
  to exclude_dirs and running aoci scope activate. A git-ignored logs/
  stays excluded as before.

• SQLite's explicit file source can collect read-only catalog Evidence for
  ordinary rowid tables, columns, primary/foreign keys, and basic indexes
  (Refs #83). Inspect, snapshot, verify, Baseline acceptance, and onboarding
  use the existing Evidence lifecycle, and an enabled SQLite source requires
  Evidence. Unsupported schema features fail closed. No MCP tool or Evidence
  JSON version changes. All hosts using SQLite need this release; 0.1.x
  releases reject the source declaration. The ncruces driver adds three
  release-linked modules without CGO. Read-only WAL collection may update
  SQLite's shared-memory coordination file.

• Built-in sensitive-name rules are a selectable set (#148). v1 is the rule
  every release through v0.1.1 applied: .env and .env.<name>, named
  credential files, private keys, secrets.*. v2 adds the shapes
  operational repositories use for credentials: a file name with an env
  component after the first (prod.env, manager-login.env,
  api.env.local) and a credential word (credential, secret,
  password, passwd, apikey, token, api-key, and their plurals) as a
  whole word of a data or configuration file name (api-credentials.yaml,
  token.txt, passwords.json). Under v2 a name ending in .example,
  .sample, .template, or .dist is a template whatever precedes the
  suffix, a source file such as tokenizer.go is never
  matched, and a directory keeps the v1 classification. The set is the
  team configuration key sensitive_name_rules: init persists v2 for a
  new repository; an absent key is v1 and keeps every existing
  repository's scope identity; aoci config set sensitive_name_rules v2 on
  an initialized repository is a governed Scope Change whose coverage
  reduction scope activate pauses for approval; aoci doctor lists the
  indexed paths v2 would take out. A repository that carries the key needs
  this release on every machine: an older binary evaluates it under v1
  and answers scope_change_required. The Safe Inventory summary gains
  sensitive_name_rules; no MCP tool name, input schema, or formal-asset
  format changes.

• Overview continuation reuses a guarded immutable delivery (#132, whloong).
  The first Volumes request runs the full governance assessment once, frames
  the body, and records a guard over its inputs: configuration, Baseline and
  Curation bytes, the composite CognitionSet identity, Safe Inventory
  membership and Git status, the rules identity and blockers, and every
  index and observe source's raw digest and size. Continuation re-checks the
  guard instead of repeating policy evaluation and rebuilding the body, and
  the proof halves reuse the same delivery. Such cursors start with v2:
  and are bound to the MCP Host session: drift answers
  overview_snapshot_changed; expiry, eviction, a foreign Host, or a process
  restart answers overview_session_unavailable_restart_required, and the
  Host starts again at Chunk 1. Database-enabled repositories, a pending
  scope change, source warnings, and a delivery the server cannot retain
  keep the live path with the reconstructable v1 cursor. The chunk receipt
  stays overview-chunk-receipt/v1; Volumes responses gain
  _meta.aoci_work; an attestation whose answers use object or
  object_ref is refused by schema with a message naming object_identity;
  the Ledger records the delivery and proof events.

• The Legacy single-file layout is read-only. Its authoring surfaces are
  retired: the ai command group and the model endpoint client (the ai
  configuration block is still read for compatibility and used by nothing),
  index build, index update, index entries, index header draft|diff|apply, index agent plan|stage|header|curation, doctor --net,
  and the Legacy drafting, prompt, workflow, and run-manifest packages. On a
  Legacy repository aoci_maintain stops with one finding whose cause starts
  with legacy_read_only_migrate_required,
  next_action=migrate_legacy_repository, and next_commands carrying
  cognition onboard start --json and the Guide; aoci_update_entry,
  aoci_remove_entry, aoci_report, update-entry, and remove-entry
  answer that token and write nothing; index agent guide returns a blocked
  guide at that stage, naming any pending transaction receipt and its
  closure; config set locale and init --locale refuse to change the
  Locale a Legacy index was written in. Reads (verify, check,
  status --deep, index score, index inventory, index header show,
  Overview, search, get_entries, header) and the Legacy-to-Volumes migration
  keep their contracts, and a Managed Scope transaction still retires an
  Entry by disposition or carries the source-bound Entry candidate a stale
  Legacy source needs. A pending header-*.json receipt from a Legacy Header
  write is closed with the 0.1.x binary that wrote it; unfinished Legacy
  draft runs are inert. The nine-tool MCP surface, input schemas, and
  formal-asset formats are unchanged; docs/upgrading.md has the operator
  notes.

• The engine kernel is importable: github.com/aoci-spec/aoci-code/engine.
  Open resolves a repository the way the CLI does; Cognition,
  Overview, Governance, and Identity project the loader, the delivery
  framer, and the shared governance facts, so a Host's confirmed
  body_sha256 and the library's digest are one computation; Connect
  hosts the nine MCP tools in process over an in-memory transport and
  ServeStdio serves them as aoci mcp does. Version reports the
  build-injected or module version, which now lives in internal/buildinfo,
  the ldflags target of every build. examples/engine-embed shows the
  embedding, including the openGauss connector replace an importer must
  carry until that connector is published as a module. Contract:
  spec/public/aoci-engine-library-v1.txt. No tool, schema, or asset
  format changes.

• A context-compaction reload that cannot fit no longer loops (#114). The MCP
  server watches for a fresh complete delivery started under a pending
  context_compaction that is followed by another context_compaction
  before it was proven; that interruption is the Host-capacity verdict.
  From then on, in that server session, a fresh request for a scope at least
  that large, made while a compaction refresh is pending, answers
  delivery_mode=capacity_stop with
  fallback_reason=host_context_capacity_exceeded: no body, the refresh
  generation consumed with an uncertain receipt and the source-bound delivery
  guidance, so the task continues without an unqualified complete-system
  claim. Explicit requests with no compaction pending, smaller scopes, and
  chains the Host already holds still deliver; scoped reads never count; the
  verdict is never persisted. check_only gains delivery_plan (the whole
  chain's estimated tokens, framed-body bytes, and chunk count) and
  host_capacity. Overview Ledger events gain delivery_chain_id,
  chunk_index, chunk_count, delivery_completed, refresh_reasons, and
  host_delivery_status, plus overview_delivery_interrupted and
  overview_capacity_stop events. The runtime rules, the AGENTS block, the
  Codex post-compaction instruction, and the Overview description state the
  stop; no tool, input schema, or receipt format changes.

• tools/list is smaller, a cost every session pays on Hosts that load tool
  schemas up front.
  Descriptions keep what a tool does, when to call it, its write boundary, and
  every contract phrase the tests lock; the procedure they repeated stays in
  aoci_rules, the Guide, and the final Chunk's attestation_prompt. The
  Overview members cognition_receipt and probe_answers are listed as plain
  objects while calls are still validated against their closed shapes, so a
  malformed receipt or probe answer is refused exactly as before; the nested
  attestation field descriptions moved to the prompt they duplicated, and the
  single-Entry compatibility fields of aoci_update_entry share the entries
  item descriptions. The remove-entry description no longer sends a
  non-orphan decision to aoci_report, which records nothing since 0.2.0. No
  tool, field, type, or validation rule changes.

• The session contract aoci_rules returns is 55% smaller (en-US about
  18.4 KB to 8.3 KB, zh-CN 15.7 KB to 7.7 KB), the other text every session
  reads before its task. Each rule keeps its effect and every phrase and token
  the tests and the manifest lock; what goes is repetition (the ordinal
  definition, the per-reason compaction narrative, the semantic-count
  breakdown, the projection's compatibility notes) whose authority already sits
  in the attestation prompt, the Overview responses, and the specs. The items
  are renumbered 1 to 11. The prescribed success and failure sentences, the
  capacity stop, and every stop condition of a stopped write stay.

• A new production repository starts with thirteen more starter observe
  rules, so its first build stops authoring Entries for material that gives no
  system cognition: third_party/ and third-party/ trees, *.svg, public
  certificates (*.crt, *.cer; private keys were already a built-in
  sensitive exclusion), and the lockfiles package-lock.json, yarn.lock,
  pnpm-lock.yaml, Cargo.lock, poetry.lock, Gemfile.lock,
  composer.lock, and go.sum, whose manifests keep the index role. Like the
  first seven, aoci init persists them only when no config exists, so an
  existing repository's rules, roles, and scope identity do not change; the
  first seven keep their ids and orders. The lifecycle suite's lockfile
  characterization becomes an assertion that package-lock.json is observed
  and never an authoring candidate.

• Migrating a large Legacy index no longer takes hours. Since the Legacy layout
  is read-only, migration to Volumes is how every Legacy repository continues,
  and its mapping template compared each Entry's field atoms by rescanning every
  range, so its cost grew with the cube of the Entry count: one
  prepare-apply-status pass took 47 s at 1,000 Entries, and a 10,000-Entry run
  was still in the template after seven and a half hours. One indexed pass with
  the same attribution rules takes 2.6 s and 28 s; no mapping, receipt, or
  result changes. The nightly benchmark comparison now covers the 10,000-Entry
  migration too.

• A new index no longer publishes the machine it was written on (#76, first
  proposed in #81 by dayebishouji). The first
  directory section of a Code Volume (or Legacy index) recorded the author's
  absolute repository path, often with a user name, and every later section
  continued it into the committed file. A writer creating that first section
  now records the neutral root /<repository>; every other section continues
  under it. Readers need no change: no checkout can sit under that root, so it
  resolves the way a clone at another path resolves its author's root, and the
  readers of rc22 through v0.1.1 resolve it and their writers append under it
  the same way. A repository whose path the header grammar could not spell
  back is no longer refused for that reason. An existing index keeps the root
  it records; the format spec and troubleshooting notes say which indexes
  carry which root.

• A person can approve a protected change in the agent's window. Approvals
  used to need a terminal: people did not know they had to open one and type
  a phrase ending in a 64-character digest, and saying no left them with an
  error and no next step. aoci_maintain with intent=human_approval and
  approval_request
  (kind=scope_change with the preview a paused scope activate saved, or
  kind=onboarding for the prepared Bootstrap or Legacy Migration review)
  shows the change through MCP form elicitation, described by AOCI from the
  saved preview or envelope, and records the person's Approve or Reject with
  an optional note for the agent. Approve writes an approval bound exactly as
  a terminal approval is, under the new mechanism
  host_elicitation_confirmation, where scope apply or onboard apply
  reads it, and returns that command; nothing is applied. Reject writes
  nothing and says what to do next. A stale preview is never shown; a host
  without dialogs, a dismissed dialog, and a terminal-only repository get the
  terminal commands. scope activate, a non-terminal scope approve, and
  onboard prepare now carry the call as host_dialog_request. The terminal
  prompt says Enter rejects and, on a rejection, what to do next;
  cognition migration approve and cognition bootstrap approve gain
  --out-file. The team key human_approval_channel (tty_or_host_dialog
  by default, or tty_only) decides whether a dialog answer counts, judged
  when Apply starts a transaction and never on Resume; it enters no scope or
  authorization identity. A repository with safe_inventory_high_risk_opt_in
  keeps Scope Change approvals in the terminal, and Migration reversal, the
  Migration and Bootstrap rollbacks, and the high-risk pre-read approval stay
  terminal-only. The aoci_maintain input schema gains the
  human_approval intent and the optional approval_request object; the
  capability manifest gains host_dialog. An approval recorded in a dialog
  needs this release to apply.

• The Ledger says why a governed call ended where it did (#150). Maintain
  events wrote only repair_required or error, so waiting for authoring,
  waiting for an observe review, a refused candidate, and a recovery stop
  could not be told apart after the fact, and a failing check read as
  result=ok beside exit_code=1. Ledger schema 9 adds governance_result,
  blocker, next_action, formal_writes_started, and batch_id to
  Maintain, update_entries_batch (and update_entries_batch_recover, which
  reconciles Entries already in place), and human_approval events, and
  check_passed with the verdict to check and verify, whose result now
  only says the command ran. A refused candidate is recorded as
  repair_required. The fields are machine tokens; no source, Entry text, or
  connection detail is recorded, and no MCP response changes.

• A Host reviews changed Observe evidence without leaving MCP (#151). A
  Maintain blocked by observed_pending carries observe_review: each new,
  changed, or removed Observe path with the SHA-256 of its current bytes, a
  review_digest binding the complete list, and confirm_request, the exact
  aoci_maintain call that confirms it. After reading the files the Host
  calls aoci_maintain with intent=observe_review and
  observe_review: {review_digest, reviewed_by}. AOCI recomputes the list;
  when a listed file's bytes moved or the list changed, the call answers
  status=stale with the current listing and writes nothing. A current
  confirmation runs the transaction scope acknowledge runs, with the same
  Baseline, Ledger, CAS, Recovery, and approval rules, and answers
  acknowledged with the confirmed review_digest, the count, and
  acknowledged_paths; a posture that needs a person saves the preview under
  .aoci/scope-change/ and answers human_approval_required with the dialog
  request and the terminal commands. A list longer than Maintain shows in full
  lists its leading items with total and truncated and has no MCP
  confirmation, since nothing may be confirmed unseen and the transaction
  acknowledges only the complete set; it keeps the scope status and
  scope acknowledge route. scope acknowledge is unchanged. The
  aoci_maintain input schema gains the observe_review intent and object;
  no tool is added and no formal-asset format changes.

• A final Volumes Apply whose Entries were already in place no longer calls
  the batch repeated. Resubmitting a stale Entry's identical text is a first
  submission that writes no formal bytes and advances the Baseline, yet
  aoci update-entry printed "Repeated batch" and the aoci_update_entry
  result's next_action named "the repeated final Volumes batch". Both now
  say the Entries were already in place; the next_action adds that they
  come from an earlier Apply or an unchanged resubmission and that the
  Baseline binds the current sources. Status, counts, duplicate_applies,
  and Ledger events are unchanged.

• The MCP server no longer writes the team configuration. Started on a
  repository whose configuration predates the Locale field, or that has a
  Legacy index and no configuration, it wrote "locale": "zh-CN" into
  .aoci/config.json, which drifted the bytes a migration envelope or Scope
  Change preview prepared before the server started is bound to, so that
  approval or Apply answered stale. The server now resolves the same zh-CN
  without writing it, and an ordinary CLI command still records it. A
  repository that already has its configuration, which init writes, sees
  no change.

• A compaction reload that the Host failed to confirm still reaches the
  capacity stop (#154, dayebishouji). A Host delivery confirmation with a
  wrong body hash, a wrong byte count, or no end marker answers
  host_delivery_incomplete, and that call also closed the open reload
  attempt, so the compaction that followed restarted the reload at Chunk 1
  instead of answering capacity_stop. An incomplete confirmation without a
  model proof half now leaves the attempt open; a model proof half, passing
  or failing, and a complete confirmation close it as before.

• aoci status reports an unreadable Baseline instead of a missing one
  (#153, dayebishouji). A corrupt .aoci/baseline.json, or a directory in
  its place, read as baseline_exists=false with exit 0 and a hint to create
  a Baseline. It now exits 2 with the error envelope under --json and a
  message, in the repository's Locale, that names the file, says it was left
  unchanged, and asks for it to be inspected before it is rebuilt. A missing
  Baseline is still a successful status result.

• A SQLite source can be declared (#109, dayebishouji; first slice of #83).
  aoci database source add --engine sqlite --path data/app.db saves one
  explicit file, relative to the repository root or absolute, in the main
  namespace, with no database name and no credential environment variable;
  URI filenames, :memory:, and server-only fields are refused; the
  read-only collector above opens the file. Governance, Database Cognition
  Bootstrap, the policy-bound auto check, Database Entry removal, and
  onboarding collection wait for Evidence only from sources a collector
  exists for, and Verify, Check, and Guide report a source whose engine has
  no collector as the informational database_source_engine_not_implemented. The
  team configuration's database and credential_env fields become
  omitempty: a SQLite declaration writes neither, and a server declaration
  is written exactly as before.

• The MCP server runs on go-sdk 1.8.0 (#66). The SDK's newer 2026-07-28
  revision removes the initialize handshake and blocks the server-initiated
  elicitation the host-dialog approval uses, so a client offering it in
  initialize is answered with 2025-11-25. On the wire, tools/list adds
  ttlMs: 0 and cacheScope: public, an unknown
  method answers -32601 instead of code 0, and one inbound frame is bounded
  at 16 MiB. The release binary gains one module, golang.org/x/time v0.15.0
  (BSD-3-Clause, from the Go project); THIRD-PARTY-NOTICES lists it.

• The MCP server serves the sessionless 2026-07-28 revision (#66). A client
  on it sends its revision, client information, and capabilities in every
  request's _meta and may start with server/discover; the initialize
  handshake still answers at most 2025-11-25, and older clients are served
  as before. That revision forbids a server's own requests, so the host-dialog
  approval travels as an input request there: the first
  aoci_maintain intent=human_approval call returns the form and a
  requestState and writes nothing, and the client calls again with the
  person's answer beside that state. An answer beside any other state is
  stale and records nothing, and an accepted form without approve or reject
  is dismissed; earlier revisions keep the server's own elicitation request.
  The capability manifest's mcp_protocol becomes 2026-07-28 and the new
  mcp_protocols lists the five negotiated revisions. The conformance suite
  gains a sessionless lane and the scenarios a sessionless dialog.

• aoci init under an existing configuration with no index starts the
  Volume-first layout. It used to write the Legacy minimal skeleton there, for
  example after the aoci files were deleted to start over or under a
  configuration written before init, and with the Legacy layout read-only
  the Guide could only route that empty index to a migration. The
  configuration's own settings stay as they were. Only a custom index_path,
  which cannot hold a Volumes Root, still gets the Legacy skeleton.

• The Legacy-to-Volumes migration is drilled end to end. make legacy-migration has the v0.1.0-rc22 release build and align a Legacy
  repository in en-US and one in zh-CN; the binary under test then migrates
  each through onboarding, running only the commands each result names, with
  the approval given in the host dialog, and Verify, Check, and the Guide must
  report the result aligned with every Code Entry carried byte for byte. The
  full-confidence line runs it on every trigger, and mcp_upgrade.py --fetch <tag> caches one checksum-verified release binary for it.

• A Legacy migration can be followed from its own output. Under --json each
  cognition onboard result names its continuation in next_commands, bound
  to the running binary: the batch command, the receipt command, for a
  Migration the mapping template over the session's own Plan and Snapshot and
  then Preview, then Prepare, and after an Apply that leaves governance work,
  the Guide. A batch with tasks carries completion_template, the receipt
  that completes it. A Migration's v1 receipt was refused for carrying the
  batch_id that next printed; it may now name the batch it completes, and
  a receipt that does not fit is refused as
  onboarding_completion_contract_mismatch field=<field>. cognition migration mapping template gains --out-file, which writes the template to
  a new file instead of through a shell redirect that could re-encode it, and
  docs/upgrading.md walks through the migration, the candidate and mapping
  files included. Existing fields keep their shape.

• A deletion-only incremental Overview proves itself (#164, dayebishouji).
  A delta that only removes Entries, with Root and Meta unchanged, delivers
  no Entry, so its Challenge has no ordinal; the empty answer list graded as
  zero correct, failed, dropped the retained base, and sent the next
  Overview back to a complete delivery. It now passes on an empty answer
  list with zero reported Entries once delivery is confirmed and governance
  is aligned, and the next delta starts from the new base.

• database inventory, database evidence bundle, and database baseline accept refuse a snapshot saved for a replaced source selection (#165,
  dayebishouji). After database source add --replace changed what a
  source selects, the old snapshot still answered inventory and the bundle,
  and accept wrote it as the Baseline under the current source ID. The three
  commands now answer database_snapshot_selection_mismatch and ask for a
  new snapshot; a refused accept writes no Baseline.

• Update golang.org/x/sys to 0.49.0 and the pinned setup-node 7.1.0,
  upload-artifact 7.0.2, and goreleaser-action 7.3.0 Actions (#128,
  #129, #130, #131). The release module set is the same 26 modules and the
  x/sys license text is byte-identical. setup-node crosses three major
  versions whose breaking changes concern automatic package-manager caching,
  which a repository without a root package.json never triggers.

• Update the PostgreSQL driver github.com/jackc/pgx/v5 to 5.12.0 and the
  SQLite collector's github.com/ncruces/go-sqlite3 to 0.36.0 (SQLite
  3.54.1). They move puddle to 2.2.3, go-sqlite3-wasm to 6.4.35401, and
  golang.org/x/crypto, x/sync, and x/text to 0.58.0, 0.24.0, and
  0.43.0; the pinned download-artifact moves to 8.0.2. pgx 5.12.0 fixes
  GHSA-95fj-3fxw-g62g: from 5.9.0, a server could skip the authentication
  that require_auth or channel_binding=require demanded, so a PostgreSQL
  source relying on those without sslmode=verify-full could be answered by
  an impersonating server. AOCI sends only fixed catalog queries, so the
  exposure was a forged snapshot, not business data. GHSA-j38q-h3ph-jjpq
  does not reach AOCI, which never sends simple-protocol batches. The release
  module set is the same 26 modules, every license text is byte-identical,
  and the license gate binds the SQLite translation's MIT-0 text to
  6.4.35401.

See docs/install.md and docs/supply-chain.md for asset verification.