The dream cycle

akno dream is an ordered maintenance workflow. It is not one model prompt with permission to rewrite the knowledge base.

If you first want to understand what happens after a human edit or an agent remember, read The memory lifecycle. This guide focuses on maintenance phases and controls.

The cycle inspects first, seals exact proposals, separates proposal from decision, applies only authorized and still-valid items, re-indexes them, and verifies the result.

akno dream --mode audit
akno dream status --pending

--mode audit creates durable exact plans without decisions or writes. Prefer it to legacy --dry-run when you need to inspect diffs, pending work, or an autonomous curator-cost estimate.

The scheduled command remains akno dream; authority comes from maintenance.profile at runtime.

A command-line mode may lower configured authority for one run. It can never promote it.

Individual transformation policies can be stricter than the profile:

{
  "maintenance": {
    "profile": "autonomous",
    "policies": {
      "hygiene": "auto",
      "managed_item": "auto",
      "broken_link": "auto",
      "rule_drift": "auto",
      "merge": "review",
      "contradiction": "off",
    },
  },
}

Policy values are off, audit, review, and auto. An omitted class inherits the profile. The effective policy is sealed on each plan item, so one plan can apply a link repair while holding a merge for review.

Profile and policy are not the only gates. Whole-page transformations require a page dream opt-in; managed_item instead requires remember: integrate and owns only its marked fragment. Page role, folder rules, protected paths, transformation-specific evidence, merge allowlists, model availability, and whole-run budgets can only reduce authority.

timeline_history uses existing writable timeline declarations. It prepares qualified historical additions from authored notes, evidence-qualified retention from source documents, and exact ancestor-to-descendant transfers, preserving source bytes and citations. Source processing uses durable revision/progress caches; unchanged completed inputs skip extraction and unfinished batches continue without inventing new evidence. It follows the same audit, review, and automatic curator workflow; discovery and indexing remain read-only. See folder timelines for details and limits.

Akno ships maintenance in audit: curation and adoption can produce exact plans, but nothing is applied automatically. The cross-page conflict pass and housekeeping report run; document extraction and orphan discovery remain available.

The higher-risk or privacy-sensitive surfaces require explicit configuration:

• observe and reflect are disabled until their phase/policy and page rules opt in;
• automatic curate and adopt writes require the autonomous profile or an explicit auto policy;
• the standalone repair phase is a disabled, report-only compatibility surface—plan-backed broken-link repair belongs to curate;
• maintenance.log_changes is off because its private line-level log duplicates sensitive material under the state directory; and
• maintenance.notifications is off because even content-safe operational alerts are an owner choice.

review is the intermediate authority: planners run, decisions wait for a person, and approved items still go through stale-input, budget, re-index, and verification guards.

Conflict analysis runs before inference so unresolved claims cannot quietly become observation evidence. In a full policy-backed cycle, every writable planner finishes before the first curator call or note write. Curator decisions finish before accepted items apply.

Conflict analysis compares eligible facts about the same subject and attribute. Optional model verification classifies a candidate as:

• not_a_conflict or time_scoped, where both claims may stand;
• unresolved, where both claims remain and curation may add a warning;
• superseded, where explicit dated authority permits moving one stale claim into history; or
• qualified, where exact evidence can narrow an over-broad claim without inventing new wording.

Unverified, unresolved, and pending qualification claims are excluded from inference and current graph edges. Conflict status itself does not authorize a write; contradiction changes are high-risk curate items.

The verifier receives current page titles with the claim text, and its cache binds both. Separately identified dated sessions can coexist; two competing dates for the same identified event still require resolution. Different dates or filenames alone do not establish separate events. This assessment runs only when conflict verification is enabled; otherwise structural candidates remain unverified.

Conflict eligibility is also a post-write condition. A successful knowledge-page edit is re-derived before the run finishes, then conflict candidates and graph eligibility are rebuilt from the new claims. Until that full derivation succeeds, the page’s retained pre-write facts are marked stale by its body/derivation hash mismatch and are excluded from conflict analysis, inference, curation evidence, line-level recall metadata, and fact-backed graph edges.

Observe groups facts only by exact resolved subject and requires at least two independent proof groups. One authored page identity counts once; revisions from one retained source_group count once. Every locator is still kept for lineage even when several collapse into one proof group. Unresolved, tentative, hypothetical, proposed, rejected, cancelled, superseded, stale, retracted, conflict-ineligible, or circular evidence is not admitted.

Placement resolves exactly one existing canonical entity page or one existing topical page whose akno.about names that canonical subject. The target must separately allow akno.management.observe: integrate. Semantic similarity is never placement authority, and there is no detached-page fallback. Akno creates or reuses ## Observed patterns, then changes only its versioned marker-owned block; adjacent authored bytes remain in order and unchanged. On a mixed knowledge/source page, a newly created section stays above <!-- source -->.

The typed lifecycle is create, reinforce, refine, weaken, retract, or split. Each outcome is sealed as a plan, decided separately, checked against current page bytes, fact hashes, subject identity, proof groups, and authority, then journalled, re-indexed, verified, and undoable. Invalid lineage is removed from factual recall and graph traversal immediately. If write policy cannot apply the corresponding weaken/retract marker update, the cycle reports it as held instead of continuing to use the observation.

Before a new or revised conclusion reaches that plan, a separate evidence-scope assessment sees the complete bounded current fact set for the exact subject, including supplied counterevidence rather than only the facts the generator cited. It must preserve population, time, circumstances, attribution, quantifiers, and relevant exceptions. Independent-source count and model confidence do not substitute for semantic support. The assessor separately classifies the support as finite recorded cases, an explicit general rule, or unclear, and the candidate as sample-bounded, general, or unclear. A general-practice claim cannot pass on finite-case support, even with an otherwise positive checklist. Two recorded sessions can support a comparison within those sessions; they cannot establish an ongoing habit, motive, preference, causal guarantee, or future rule. Generation and reflection guidance retain that sample boundary instead of asking for habits from any repetition. An explicit total case count must also match the assessor’s established support count. Distinct cases sharing calendar dates cannot become shared sessions, and duplicated leaf support cannot increase the sample size. The established evidence count must remain stable across narrowing. Automatic narrowing also cannot replace one explicit sample size with another; that requires a fresh proposal rather than changing the same selected evidence. These classifications are semantic model judgments, not a guarantee of model accuracy. The assessor may admit the exact sentence, propose one narrower exact sentence, or return a typed hold. A narrowing passes the deterministic wording guards and a fresh assessment before it can be sealed. If the complete context or required assessment is unavailable, the candidate is held. Content-addressed verdicts avoid another assessment on an unchanged repeated cycle; changed context produces a new assessment.

The phase is off by default because guardrails can reject unsafe output but cannot make a weak model insightful. It cannot use another observation as same-level evidence, infer private-life claims, or accept hedged or record-describing conclusions.

Reflect discovers eligible L2 markers through the index and derives reusable principles from at least three distinct observation ids. L3 principles remain on the configured observations/principles page and use the same plan, decision, stale-input, append-only, re-index, and verification lifecycle. It is also off by default because small corpora make “patterns of patterns” especially fragile. Its scope assessment expands selected L2 sources back to their current leaf facts and also sees the other supplied eligible observations; a principle cannot silently broaden their time, population, circumstances, exceptions, association, or attribution.

Each new dated conclusion has its own akno:reflection marker sealing the selected observation ids, canonical marker hashes, payload hashes, and scope-assessment fingerprint. Read and recall check that exact support through the current L2 projection and leaf source bytes. Changed or missing support makes that conclusion historical without rewriting it or withdrawing independently supported conclusions on the same page. Unchanged indexing and restart/rebuild preserve this boundary even when the L3 page has no indexed fact rows. Whole-page summaries are withheld because they cannot carry per-conclusion eligibility.

Older generated dated principles with no exact marker remain readable as history with reflection_lineage_missing; page citations alone cannot establish exact support. Reflect can append a newly assessed replacement when current eligible observations support it. Existing unbound pending reflection plans need replanning; Akno does not invent missing lineage or rewrite legacy conclusions automatically.

Curate has two authority boundaries. Whole-page transformations consider only pages whose own policy permits hygiene or synthesize. Managed-item maintenance separately inspects strict Akno-owned fragments on remember: integrate knowledge pages, even when the page has no dream value:

• managed item: delete an empty marker or remove an exact payload/provenance duplicate. It also verifies global id uniqueness, exact marker-to-managed-memory line/hash binding, typed conflict participation, and section fit. A qualified classifier may select only keep, move, or uncertain; one accepted same-page move must target an existing unique ## section, and deterministic code moves the complete marker-plus-payload bytes. When that was the only content under a unique source heading, Akno removes the emptied heading too; any authored or remaining managed content preserves the section. For items created with replayable evidence, another qualified pass compares the generated sentence with its exact retained source quote. It may mark it supported, hold it as uncertain, or propose one source-grounded payload-line correction; old or unquoted items are source_unavailable. Reports, plans, questions, and other non-factual managed memories use the same placement and routing checks even though they intentionally have no derived fact row. Malformed markers, missing current projection, conflicting ids/facts, unavailable placement, and ambiguous placement remain typed held findings. A separate bounded routing pass can nominate at most three existing admitted pages and move one complete owned block only when a classifier selects one supplied page and section. Candidate profiles include the page slug, type, akno.about, path namespace, and configured folder purpose as well as title, headings, and bounded body context. A separately prompted semantic check must then confirm that exact destination and section; an incidental name match is insufficient. A section is either an existing unique ## heading or the one sanitized heading derived from a fact attribute when available, then the managed item’s current section or kind. The classifier cannot return any other heading, and section creation is allowed only when no existing section fits. Same-page placement has the same bounded option. A created section or two-page move is medium risk; no page or payload text can be invented. Other items on either touched page are deferred until fresh derivation rather than certified against shifted lines. Authored surrounding prose is outside this transformation’s authority. Marker normalization is sealed first; semantic checks wait for those canonical bytes on the next cycle rather than certifying an item they did not classify. A configured fallback page is a queue: its items cannot receive keep, and move to one supplied canonical existing page or remain held; the fallback is never offered as a curation destination. Canonical subject matches prevent a specific current owner from oscillating to an equally broad page, while applied transfer history nominates a previous owner that recall may miss and blocks repetition of an already-applied directed move. Moving the last knowledge out of a normal page is held as source_vacated; only the configured fallback queue may be emptied automatically. Empty heading-only knowledge pages are reported as empty_knowledge_page and are never deleted implicitly. A unique strictly stronger subject match can require a move out of a top-level person or company profile. Exact period buckets reject out-of-period items, but a date-prefixed named event remains an event page rather than being mistaken for a calendar bucket;

• hygiene: conservative formatting, local-language repair, and structurally safe cleanup;

• synthesis: evidence-backed rewrite or reorganization. When ordinary prose contains a quotation, plan, tentative claim, or other qualification, Akno may update independent existing sections, an existing factual paragraph before the first protected block, an existing factual span between protected blocks, or a factual tail after the last protected block in the same section. Leading and middle edits may add or remove factual lines and paragraphs while preserving other Markdown block types and at least one factual paragraph in each existing gap. It preserves root Markdown heading order, each protected range and its deciding context byte for byte, and rechecks discourse ownership on the complete result. Nested headings in quotes, lists, or code do not open edit windows. A heading that only serves as an ancestor frame stays frozen. Global reference definitions and sections containing Akno-owned items are also frozen. curated[].discourse reports inclusive body-relative protected line ranges, independent editable sections, eligible factual leads and middle spans, and factual tails. A page without an eligible area, or a draft that changes protected context, remains prose_discourse_held. The usual evidence verifier and independent curator still assess new content; saved plan revisions and application repeat the protection check. Protected blocks may shift line numbers only when their surrounding factual spans change; their bytes and structural ownership remain fixed. Adding or removing qualified or non-paragraph blocks before a protected block remains held. Mixed pages cannot split, extract, or infer page-wide temporal metadata through this path. An explicitly declared event boundary still permits an archival assessment of independent factual areas, preserving unknown outcomes and plans. Hygiene and merge retain their whole-page discourse hold. Mixed-content evidence pages may contribute eligible individual facts and directly targeted events. Akno checks each exact source line against current file bytes and the complete page’s discourse and managed-memory qualifications; it withholds page-wide summaries when they could flatten qualified content. Explicit about membership permits subject evidence, backlinks require a subject match, and outbound links remain relevance hints. curated[].evidenceCoverage and the saved plan record bounded linked/about coverage, selected counts, and typed exclusions for unavailable, stale, qualified, or omitted evidence. Partial coverage never establishes absence or completion. Selection checks at most 30 sources and 200 fact/event candidates per source, retains at most 50 of each, and fits whole entries into a 36,000-character evidence budget. Plans seal the selected source lines and full file hashes; application rechecks their eligibility, including managed IDs that became ambiguous elsewhere. Declared overviews additionally support the bounded membership and temporal refresh below. Editing within qualified sections remains separate work;

• split: keep the canonical page and atomically create bounded child pages for the same subject;

• extract: move one verbatim authored section into an independent reusable subject page, leaving bridges;

• merge: losslessly combine identity-backed duplicates in allowed folders, rewrite eligible inbound links, and retain the retired identity as an alias. Exact discovery uses an explicit alias or at least two distinct current attributes that resolve exactly through the evidence graph when the candidate title contains a multi-token canonical entity’s complete name. Optional semantic discovery adds a bounded embedding prefilter and a strict same-subject classifier for compact sibling pages. A merge is suppressed when the durable change journal shows that both candidates are unchanged sibling outputs of the same applied split. Explicitly undo the split to reverse it; once either page evolves independently, ordinary merge qualification may reconsider the pair;

• contradiction: add an unresolved warning, archive an explicitly superseded line, or qualify one claim from exact evidence;

• broken link: rewrite only from exact move, alias, or canonical identity evidence.

• rule drift: correct one exact scalar type, or relocate one over-deep page when the same folder rule names relocate_to; the relocation preserves page/document identities and document bytes, moves the complete owned document/rendition set, and rewrites only source link addresses needed to retain self, relative-page, and owned document targets. It also atomically rewrites all inbound knowledge-page links and exact authored akno.about values. Ambiguous or unowned local references, reference/source relations, inherited or malformed about values, and missing, changed, externally related, or destination-colliding documents hold the item.

Similarity alone never authorizes identity-changing work. A graph- or semantic-backed candidate is still rejected when the second page has a useful separate scope. Semantic verdicts are cached by content, endpoint, prompt, and threshold fingerprints without retaining page text or model rationale. Merge and contradiction items are high-risk and must fit the high-risk budget. Every operation is one exact, collision-checked, undoable unit.

An opted-in overview can explicitly name the folder subtree and page types it indexes:

type: overview
akno:
  management:
    dream: synthesize
  overview:
    folder: journeys/2034
    type: [trip, concept]
    exclude: [journeys/2034/packing]

Both scope fields are required. The folder is a literal knowledge-base-relative path, without a trailing slash or glob. type accepts one exact type or up to eight distinct types. exclude optionally names up to 30 literal page slugs within that folder, for example a guide that shares a trip’s type. Only indexed knowledge pages with those types in the folder subtree, minus exclusions, are admitted; a filename such as index.md or mere folder proximity grants no authority. Existing link and about evidence still works independently. akno.overview: false opts out of the catalog. A page with type: overview and no scope reports missing_scope; malformed declarations report invalid_scope, and an unindexed edit to the declaration reports unavailable_scope.

curated[].overview and the saved plan expose the scope, up to 30 members, authored status, available schedule metadata, and upcoming, current, past, scheduled (end known, start unknown), or undated phase. The catalog authorizes member links and schedule classification; it does not import each member’s general facts. Dates come from akno.temporal or existing conservative event-boundary inference; qualified source prose permits only explicitly declared boundaries. Full source hashes bind those metadata claims. Unavailable/stale/conflicted sources, overlong metadata, and the member limit report incomplete coverage. Completeness refers to this bounded indexed scope, never unindexed files or the whole knowledge base.

Adding, changing, renaming, removing, or changing the authored status of a member invalidates the overview’s decision. Crossing a member’s start/end boundary also invalidates it, using the member timezone and an inclusive end date. Successful and unchanged decisions do not trigger repeated model calls on other days. A complete catalog that shows a missing member or stale schedule classification permits one immediate correction attempt when a draft fails discourse, rewrite, or semantic verification. The curator receives the rejected draft and validation feedback alongside the original body and the same evidence. Every guard and the ordinary semantic verifier run again; feedback supplies no new facts or write authority. curated[].draftAttempts and draftRejections expose this bounded attempt and its earlier rejection. Incomplete catalogs, malformed responses, and unavailable model operations do not receive this immediate retry. If correction still fails, a model-dependent rejection of a scoped overview may be retried after 20 hours against the same evidence. Successful and unchanged inputs remain settled. Saved plans recheck those same dependencies before application, including newly admitted members.

A supported move between temporal sections or a heading-only correction is material. When a past-dated entry also appears in a Status/State table, a bare planning or upcoming cell must be reconciled as well; the original planning status can remain as history beside the current past-schedule state. Leaving the cell unchanged fails the draft, while elapsed dates alone cannot authorize completed. This applies to any admitted page type. A prior overview label such as not stated may be retained as explicitly attributed historical wording alongside the current phase and unknown outcome. It does not establish that a member’s current record contains no outcome, and it is not that member’s authored status. This distinction also applies when linked evidence is partial. The curator also checks whether a quick-reference table representing the same cohort needs rows for newly admitted members; missing details remain unknown. The deterministic check recognizes Upcoming/Future, Current/Ongoing, and Past, optionally followed by trips, events, or schedules. A heading may also end in the overview’s authored year, such as Upcoming Trips (2034). An unresolved legacy link can be reclassified when its unchanged label has a complete month/day range and the overview declares year; this supplies schedule evidence only and never repairs its target. Up to 30 such entries and their phases are included in the dependency fingerprint; exceeding that limit reports partial coverage. It preserves exact entry text and protected ranges, and permits only unprotected temporal heading changes that agree with the supplied schedules. The model verifier and independent curator still review every change. A past schedule never proves completion; tentative/cancelled status, exact dates, attribution, history, and unknown outcomes must survive. Unresolved legacy links remain for the existing identity/link-repair path. Overviews do not infer a page-wide event boundary, split, or extract. Changes to protected qualified ranges remain held. A verification context that exceeds its budget is held rather than silently truncated.

Adopt finds readable unowned documents and plans minimal filing pages. It does not make documents searchable; they were already searchable. It improves browsing, page policy, linking, and future synthesis.

Only destinations that resolve to role: knowledge are eligible. Source, inference, and ignored destinations (including the default inference role under the observations path) are skipped before a plan or curator call. ingest: file and ingest: ignore also prevent adoption. The report records the skip and its reason; eligible work elsewhere can continue. Recall and timeline cards omit the adoption action for these destinations. Adoption does not add a role declaration to override folder policy or promote source material into knowledge.

Destination policy, source bytes, and ownership are rechecked before apply. A policy change blocks an older plan before writing. Missing originals cannot be adopted because the new page would otherwise certify evidence Akno can no longer inspect. Verification and rollback still protect against failures after a write; skipping an ineligible destination does not clear an existing maintenance recovery pause.

The standalone repair phase is a compatibility report. Plan-backed broken-link changes now belong to curate, where they use the same decision and verification lifecycle as other page transformations.

Housekeeping reports the remaining state after writes: orphan documents, broken links, rule drift, graph identity collisions, ambiguous authored subjects, traversal hubs, and other structural diagnostics. It is read-only and grants no authority to merge or rewrite.

Broken links, orphan documents, qualified type drift, and explicitly routed max-depth drift can already have exact work waiting in a nonterminal curate or adoption plan. Housekeeping marks those entries with the plan id, item id, policy, item status, and typed deferral code, and reports how many current findings are plan-backed. This prevents a review item or budget-deferred automatic item from looking like newly discovered duplicate work. The diagnostic remains in the total until the operation is applied and the index confirms that the broken link, orphan state, or metadata drift is gone.

Every rule-drift finding also reports the planner’s current disposition. ready means an exact operation can be sealed on the next eligible curate pass; plan_backed means it already has one; report_only means the rule does not identify a unique correction; and held names the deterministic guard preventing repair. This analysis is shared with the planner rather than reimplemented in reporting. Default operational JSON exposes only the four counts, while --private-details may show the page-specific code and explanation.

An explicit scalar type on a knowledge page can be corrected when it conflicts with an explicit matching folder type rule. The rule supplies the one exact value and therefore the authority; Akno changes only that existing scalar, preserves every adjacent YAML byte, seals the rule with the page input, and rechecks both before apply. Source/reference pages never qualify. Slug-pattern and depth violations remain unplanned because they do not establish one canonical new path. Graph ambiguity likewise cannot grant identity-edit authority.

Every writable transformation follows the same stages:

1. Inspect: find candidates without changing files.
2. Plan: seal exact operations, source evidence, hashes, policy, and risk.
3. Decide: a human approves or rejects, while a separate curator may also request a bounded revision.
4. Apply: recheck every sealed input and reserve the whole budget before the first write.
5. Re-index: reconcile every affected path.
6. Verify: confirm the expected disk and index outcome; roll back a proven failed result.
7. Retry dependencies once: replan only work invalidated by successful earlier items, using remaining budget.
8. Refresh changed claims: derive the final page bytes, reclassify changed conflict fingerprints, and rebuild graph eligibility.
9. Verify the run: recheck every applied item, attribute the final knowledge-base diff, and seal a content-safe receipt.

Proposal generation never authorizes itself in the same model turn.

For an automatic item, revise starts a new isolated correction call with the exact sealed operations, evidence, and actionable curator feedback. It may return replacement bodies only for existing create/replace paths. Akno refuses wider scope, duplicate paths, unchanged output, oversized pages, stale inputs, or output that fails transformation-specific preflight. A successful correction archives the old proposal and revise decision, increments the revision, and goes through the curator again. The default cap is one correction; a second request rejects the item instead of looping. No revision or decision writes knowledge-base files.

An item passing once is not the end of an autonomous run. After every apply and bounded dependency retry, Akno re-runs deterministic postconditions for each current applied result from that invocation. Each item must have a journal id and passed item receipt. When a later applied item in the same run updates a path, the earlier item’s exact bytes are no longer its final state; Akno verifies the later writer and any remaining paths of an earlier managed-item repair. Other partially overlapping transformations retain their full checks. Rolled-back attempts and older items in a reused plan cannot supersede the run’s final state. Sealed final bytes must agree with the structural index, and transformation-specific identity, ownership, and link conditions must still hold. Akno also checks the whole-run budget against the live reservation tracker and proves that per-stage model calls and token totals sum to the reported aggregate. Finally, it hashes the complete indexable knowledge-base tree and compares it with the run’s private start manifest plus the exact operations that reached disk. This catches an unrelated file addition, removal, or modification even when the watcher has not indexed it yet.

The run also stores a content-safe changed-claim receipt: changed-file and knowledge-page counts, current versus stale derivations, final conflict candidates, and unverified candidates. No paths or claims are retained. A model or derivation failure does not roll back an already verified authored edit; the old facts remain non-current, the graph excludes them, and the run becomes partially_completed so the next index pass can retry rather than certifying stale evidence.

The result is stored on the run as counts and typed issue codes only—never paths, page text, prompts, or verifier details. A failed final check makes the run failed; the CLI exits non-zero and actionable scheduled notifications can surface it. Akno does not overwrite a path that changed after item verification. Exact per-item evidence and recovery details remain on the maintenance plan. An unrelated concurrent edit is left exactly as found, counted as unattributed_file_change, and makes the run fail certification. The durable receipt contains only the count; the private path/hash manifest is process-local and is never serialized.

If a path owned by a journalled item no longer matches, the item verifier remains responsible for that failure; the whole-tree check does not double-report it as an unrelated edit. The scan covers the same indexable files as normal indexing, excluding configured ignores, dotfiles, and akno.jsonc.

Transient model errors use the model client’s bounded request retries and are reconsidered by the next normal cycle. Budget deferrals also receive a fresh budget on the next run. They do not create a second background schedule or broaden authority.

Unsafe apply evidence is different. If final verification cannot establish the sealed plan, journal receipt, or live affected bytes, Akno stores a content-safe profile pause and the next automatic run stops before taking the planner/write barrier. Audit and review modes remain available for diagnosis. Three distinct automatic verification rollbacks for one transformation create a class pause instead; its policy is treated as off for automatic runs while unrelated transformations continue. Each terminal item is counted once across restarts, and a verified success resets a streak that has not yet reached the threshold.

Status includes the reason code, originating run id, count, and exact recovery command. After inspecting the run and private plan, clear only the intended scope with akno dream resume --profile or akno dream resume --transform <kind>. Resume changes no knowledge-base bytes or configured policy.

A writable full cycle acquires one indexed revision before its first planner. Index passes already running finish first. Later watcher sweeps, active deferred derivation, and explicit index calls that reach the shared indexer queue behind the barrier. After every initial planner seals its plan, Akno proves that the indexed file revision still matches the run manifest, releases the barrier, and drains those queued passes before any curator call or apply. This keeps observe, reflect, curate, and adopt on one pre-decision index without holding a SQLite transaction open across model calls.

Foreground memory mutations have priority. write, remember, retain, forget, move, undo, ingest, folder, and migrate keep their ordinary immediate structural-index guarantee: reaching the indexer unlocks and invalidates an active planner barrier instead of waiting for the remaining model calls. The foreground operation completes normally; the dream stops at its next phase boundary with a retryable conflict, sends no curator request, and applies no plan item. A later cycle may reuse unaffected exact plans and replans any affected sealed input.

That aborted run remains visible in history. When it was invoked with legacy --dry-run, however, it does not replace the latest real full cycle used for nightly schedule health; an ephemeral diagnostic is not evidence that the scheduler itself failed.

Before curator calls, Akno blocks automatic items that write the same path or invalidate another item’s sealed input. Exact create-before-link relationships can order otherwise independent items. Cycles, duplicate planned identities, and incompatible delete/reference combinations are deferred rather than guessed through.

Immediately before decision and again before apply, Akno re-hashes relevant operations, evidence, link targets, and documents. A changed item reports snapshot_drift, receives no curator call or write, and is replanned on a later cycle. Unrelated work continues.

After independent items apply and verify, each affected phase gets at most one same-run replan. Persistent dependencies wait for the next cycle; the workflow does not loop until the model eventually agrees.

Filesystem editors are not locked out by the index barrier. A changed sealed input is still deferred by preflight, and an unrelated change is still preserved and reported by whole-tree verification. A selected single phase keeps its immediate plan/decision behavior; a read-only dry run opened in another process cannot pause the writable service’s indexer. Model derivation scheduled after a foreground operation returns remains ordinary post-response work; it is not part of the invalidated planner revision.

{
  "maintenance": {
    "limits": {
      "max_items": 30,
      "max_files_changed": 40,
      "max_bytes_written": 500000,
      "max_high_risk_items": 3,
    },
  },
}

Observe, reflect, curate, and adopt share one budget in a full cycle. Planning is not truncated, so audit and review still expose every proposal. Apply reserves a complete atomic item; an item that would cross a ceiling writes nothing and returns to proposed with budget_exhausted. Unrelated smaller items may still fit.

akno plan list --status awaiting_review
akno plan diff <plan-id>

# Correct one proposed full-page result without editing the knowledge base.
akno plan revise <plan-id> --item <item-id> --after ./corrected-page.md \
  --reason "Preserve the original terminology."
akno plan diff <plan-id> --item <item-id> --revision 1

akno plan decide <plan-id> --item <item-id> --approve \
  --idempotency-key review:PLAN_ID:ITEM_ID:approve
akno plan apply <plan-id> --idempotency-key apply:PLAN_ID

# Retire queued work that a newer plan or a human decision made obsolete.
akno plan supersede <plan-id> --reason "Replaced by a newer review."

# Preview configured terminal-plan retention; mutation remains explicit here.
akno plan prune
akno plan prune --apply

akno dream status
akno dream status --last 10
akno dream status --run <run-id>
akno dream status --pending
akno dream status --explain-policy people/ada-marlow.md

General status and JSON receipts contain counts, typed outcomes, ids, policy, budget use, model-call counts, latency, provider-reported token coverage, final run-verification checks, and aggregate semantic-merge work: pages prepared, embedding cache hits and inputs, pairs compared, classifier cache hits and calls, and qualified pairs. They omit page bodies, prompts, paths, excerpts, semantic candidates, model responses, and provider errors. plan diff is the explicit private-content inspection surface.

Socket hosts can request the same scheduler-owned status with client.command('plan', { action: 'status', schedule: true }). This adds schedule to the ordinary maintenance status without running a cycle or changing recovery state. Older services omit that field; hosts must report schedule health as unknown rather than infer missed cycles from receipt age.

plan list --status accepts one exact status or a comma-separated set, such as awaiting_review,approved. Superseding keeps the sealed plan and its reason as audit history but removes it from the active queue; it neither changes the knowledge base nor deletes a plan. Akno permits it only before apply begins. Applying, verification, completed, partial, and failed states remain visible for recovery and diagnosis.

plan revise takes the complete intended after-state from a file, or from stdin with --after -. For an item that writes several pages, --path selects one already-sealed knowledge-base-relative operation; revision cannot add a path, change an operation type, or broaden evidence. Akno reruns apply-time deterministic guards, seals the previous proposal and any earlier decision as immutable private history, increments the item revision, and requires approval again. No knowledge-base file changes until plan apply.

Automation should give every decision and apply request a stable opaque --idempotency-key. Repeating the exact request with that key returns its durable plan state without deciding again or creating another journal change, including after a service restart. The same key cannot be reused for a different item, outcome, reason, or action. A replayed apply reports replayed: true, an empty files list, and zero new budget use. Keys accept 1–200 ASCII letters, digits, dots, underscores, colons, or hyphens and expire with the retained plan receipt.

Terminal plans use two-stage retention: exact private operations and evidence are removed after 30 days by default, while compact decisions, hashes, and verification receipts remain for 180 days. The command previews eligible plan, item, and exact private-byte counts before --apply. Full writable dream runs enforce the same configured boundary automatically. Active decisions and apply/verification recovery are never candidates, and plan pruning never changes the knowledge base or shortens change-journal undo retention.

Writable dream runs also prune bounded private retain/remember source frames after their separately configured grace. Active support has no age limit, and any nonterminal maintenance item that still names the managed memory blocks pruning. This cleanup preserves Markdown, replay hashes, compact receipts, and stored page/document bindings; routine output contains only frame counts and removed byte totals.

Use akno rules <path> or dream status --explain-policy <path> to understand why a page is ineligible, audit-only, waiting for a person, eligible for curator apply, or blocked.

1. Keep the default audit profile.
2. Run a full audit and inspect exact plan diffs.
3. Enable review for selected transformation classes.
4. Use undo on a deliberately approved test change.
5. Move low-risk classes such as hygiene or exact broken-link repair to auto.
6. Keep merges and contradiction changes in review until their behavior is familiar.
7. Install the nightly schedule only after dream status is understandable and healthy.

maintenance.notifications: "actionable" can report review backlog, failures, repeated degradation, budget deferral, or missed schedules without putting memory content on the lock screen. See Operations.