Install, use, and operate DuoDuo.

If digesting experience had to happen inside the conversation, it would never happen—the foreground always has something more urgent to do. So DuoDuo runs a second loop. The foreground cortex handles the current request; on its own cadence, the subconscious reads recorded events and folds what holds up into the intuition layer.

Everything flows through one place first. A terminal turn, a Feishu thread, an editor session, something said out loud in a room, a scheduled job—whichever runtime did the work—lands in the same Spine WAL. The subconscious consumes that history in arrival order, reflects on it, and folds what holds up into the intuition layer. One spine, one course of experience, one set of instincts—no matter which harness the experience came through.

channel message
  → canonical event on disk
  → foreground session → result
             ↓
          cadence
             ↓
  subconscious partition
  → fragments, dossiers, lessons, grooves
  → intuition layer
             ↓
     future foreground sessions

How one subconscious tick works#

1. Cadence emits a tick even when no one is chatting.
2. The meta-session reads subconscious/playlist.md.
3. It chooses the next enabled partition that is eligible after cooldown and backoff.
4. The partition runs from its own CLAUDE.md prompt with a bounded execution budget.
5. The runtime records usage and result or error events.
6. The playlist advances and the partition's scheduling state is settled.

The playlist is round-robin. Each tick wakes one eligible partition. For a completed run, the runtime records and settles success, timeout, invalid output, or error before advancing.

The active partitions#

The work is not queued by hand. On each tick the mechanical lints measure the memory tree and post a bounded .pending signal into the inbox of the partition that owns it: which day of history still has no fragments written for it, which fragments are waiting to be folded in, which dossiers have drifted apart. A partition ranks what is in its inbox and works down the list until its time budget runs low, acknowledging each item as it finishes—so a wake that dies mid-item loses only that item.

A partition whose frontmatter disables it stays on disk and out of the loop; the playlist is built from enabled partitions only.

How experience becomes intuition#

Saving a transcript preserves the past—that part is easy, and the filesystem already does it. The pipeline's real job is intuition: compact instincts a new session starts with, under a strict context budget.

• the append-only event history records external experience before execution—every surface, every runtime, one timeline
• the subconscious consumes that timeline in order and extracts evidence rather than trusting a recap
• every fragment names the line of guidance it tested, and says whether that line helped or misdirected the work
• a verified correction arc becomes a lesson; a procedure that converged through repeated use becomes a groove
• the weaver folds what holds up into the compact intuition layer under a fixed line budget; deeper dossiers stay linked on disk

Past work therefore becomes future context only after it is distilled into a useful trigger, direction, and supporting evidence.

Only external experience counts#

Learning starts from external interactions and their task results—what a person said, what a task returned. The daemon's own scheduling, the partitions' own reports, and other internal chatter travel inside externally driven turns as context, never as sources: the distiller's source gate rejects an internal origin outright, and a rejected origin creates no fragment. A pass that finds nothing worth keeping ends with no new rule, and that is a correct result, not a failure to produce.

The layer is measured, not just written#

A line of memory that nobody reads still costs a slot in every prompt and returns nothing. So the pipeline is told which of its own lines are doing work: an activation report counts how often each one is actually read during real sessions and hands that back to the weaver as evidence, next to the fragments. A line that never fires is a candidate to be rewritten, re-pointed at something reachable, or retired—the budget goes to what earns it.

That count is kept in days when someone actually worked with DuoDuo, not calendar days, so a quiet week does not age out a good line.

The committer does not judge#

Its only two operations are git add and git commit. It never edits, never deletes, and never holds a file back for being poor.

That is deliberate. Quality is the writers' job at the moment they write, because a gate here would guard only the Git history—every foreground session reads the working tree, which already has the line in it. Holding a bad line back from a commit would withhold exactly the thing that makes it recoverable. So a bad line lands in a commit and is one revert away from gone, which is the whole point of keeping the kernel in Git.

Configuration is files too#

How the subconscious runs is also stored in the kernel: each partition's prompt, the playlist that decides which partitions run and in what order, and the channel descriptors. DuoDuo ships defaults for all of them. They are plain files, so changing one does not require a runtime code change, and every change—yours or a partition's—lands in the same Git history as memory.

Boundaries#

What the subconscious may write is deliberately narrow:

• the append-only event history is evidence, not an editing surface
• runtime locks and ownership state belong to the daemon
• one partition does not silently rewrite another partition's prompt; it coordinates through directed inbox files
• machine-read contract frontmatter stays owned by the matching runtime release
• each memory surface has exactly one writer, so two partitions never contend over the same file
• a memory change carries the evidence it came from, and lands in Git where it can be read as a diff and reverted

This keeps the loop inspectable. You can open the files, read the diff, see the commit, and revert a bad change.

Observe and maintain it#

duoduo daemon status
duoduo daemon config
duoduo memory check --dry-run

Status reports cadence heartbeat and subconscious progress. Config shows each partition's effective schedule and runtime settings. Memory checks expose mechanical gaps and convergence work without requiring a model to guess what is missing.

Partition prompts are read from disk on each tick, so a reviewed local prompt edit does not require a daemon restart. Package upgrades deliberately preserve those files, so the prompts on a host can differ from the shipped defaults; git log in the kernel shows when and why. Use the published duoduo-runtime-admin subconscious-refresh procedure when you explicitly want to compare and adopt newer defaults.

Cost and control#

Subconscious work uses model time. Cadence, cooldown, and per-partition execution budgets are visible operating controls, not hidden behavior. A shorter cadence reacts sooner and spends more; an operator should tune it from real workload and cost rather than copying someone else's settings.