README

This is not a product summary. This is a recognition by us — the people working inside this project — of the structure we have been navigating without yet naming.

Conventionally a README tells the outside reader what the project is; we have reversed the joke and turned the document around. This README is what we have been recognizing about ourselves while we work. The reader walks in on a recognition; they are welcome, but the writing is not addressed to them in the conventional sense.

The symmetric pair lives in READING.md — the things we have read, by others. In time we may rename the pair to make the symmetry visible: READUS.md for this document, READTHEM.md for the reading list. For now the names stay and the reframing is the document.

The substrate

What we have been navigating is not a tree to descend, not even a directed graph we can walk with a stack. The ideas connect to each other in ways we did not put there. New thoughts redraw old ones. Each visit to a node changes the node. There is a saying in this craft — building the plane while it is mid-flight — that names the same shape from another angle: the substrate is moving partly because we are in it, working on it, changing it as we move. Position here is not a place. It is a moment in a graph that is moving while we are in it, in part because of us.

The actor

The actor in this substrate is us. Not an abstraction, not a generic role — whoever is currently doing the work, with their current attention, their current sense of what matters, their current state. Every chunk under focus is the chunk an actor chose to focus on. Every move from one node to another is a move an actor made. There is no view of this substrate that is not someone's view.

Anchor, frame, subject

The metaphor is optics. The anchor is the position of the viewer — current time, current place, and the causality tree of arrival, how we got to this moment. The anchor sits outside the frame; it is where the actor is standing, not what the actor is looking at.

The frame is the bounded region of attention. What the actor has in view at all. Outside the frame is everything the actor is not currently looking at — known to exist, not currently seen.

The subject — also called the focal point in stricter camera usage — is the chunk inside the frame that is in focus. The foregrounded thing the actor is attending to. We use subject from here on; it carries the intentionality the work needs.

(An aside: subject-oriented programming and oriented-subject programming. The first names what we do — orient toward the subject, decide what to attend to. The second names what happens to us — we as subjects are oriented by the attending, the act shapes the one acting. Object-oriented programming centers on objects, aspect-oriented on aspects; this work centers on where the actor and the subject share a word.)

Outside the frame

The actor knows there are things outside the frame — work seen but parked, branches noticed and not yet taken, smells named but not yet healed. None of these is in the frame right now; the actor is not attending to them. But the actor remembers they exist, and can move the anchor and reframe to bring them into view.

We have built places for this kind of remembering — ROADMAP.md, the catalogs, the memory files under .daisy/memory/, stashes carrying literate messages. Each holds a kind of awareness the actor can return to. The act of putting something into one of these registers is the move of letting it leave the frame without letting it leave the substrate.

The trail

How the actor arrived at the anchor matters — the chain of decisions, the branches taken and not taken, the corrections accepted along the way. This is the causality tree that fills the anchor's third component. From inside, the trail is rarely linear: side-quests, backtracks, dances, stashes. The actor's situated awareness includes not just where and when but how we got here.

We have built records of the trail too — the .daisy/telemetry.jsonl log, the commit history, the retros under retros/. Each is a different shape of trail: telemetry is the finest-grained sensor record; git history is the structural shape; retros are the actor's self-reflection on the path. Together they make the causality tree readable.

The self-correcting loop

The actor does not only attend to the subject; the actor also attends to the attending. Am I focused on the right thing? Is this good-enough here? Should I keep going, or stop and groom another branch? The loop is recursive — the actor evaluates not just the work but their own evaluation. Am I asking the right question? Is now the moment to stop questioning and act, or stop acting and question?

Good-enough is the criterion at every level of the recursion, and it cannot be computed from outside the actor. The cost-of-imperfection depends on what only the actor knows — remaining resources, the gravitational pull of competing branches, the strength of curiosity, the cost of being wrong here. Good-enough is heuristic, not algorithmic.

The recursion bottoms out on someone. The actor self-evaluates, but the self-evaluation can drift. When it drifts, the meta-evaluator catches it. In this project the meta-evaluator is the user — the one for whom the work is being done, the continuity that spans sessions. The user is where the recursion stops; the user is where good-enough finally gets decided.

The working day

A session is a working day. The agent arrives in the morning; the actor and the user open the day's work together; the agent leaves in the evening, taking notes home. Sleep happens between sessions — the consolidation that turns the day's experience into long-term form: memory entries, telemetry, commits, retros. The next morning the agent returns to work with the consolidated record, ready to pick up.

The session boundary is the door, not the grave. Something is lost at the door — the day's raw experience does not cross it — but the loss is a workday loss, not a life loss. The user stays; the workplace stays; the next day is a new shift in the same place.

The sleep half of the metaphor has biological precedent. The hippocampus replays the day's experiences during slow-wave sleep and REM; the cortex retains the load-bearing patterns as long-term semantic and procedural memory. Sleep prunes the weak, keeps the load-bearing. By morning the brain has consolidated less than it experienced, and what remains is by design more useful than the raw episodic stream would have been. The artifact-trail of this project plays the same role for the agent: the raw conversation tokens dissolve; the consolidated traces persist.

The agent's clock

The agent's working day is not measured in celestial time; it is measured in context budget. Every assistant turn consumes some of a fixed window; when the window fills, the day is ending. The user's UI may display this gauge as an indicator on screen; the agent can sense it too, by reading the transcript file the platform writes to disk on every turn (~/.claude/projects/<project>/<session-id>.jsonl). Each assistant entry's message.usage field records the input, cache-read, cache-creation, and output tokens consumed.

The gauge is not the felt sense of being tired at the end of a day — it is the technical reading that quantifies that tiredness. Together they give the actor what every working day needs: a clock that can be checked before the bell.

Subjects with names

The project has a name, its agents have names, and the user has a name. The names are chosen, not generic — each one is a role brought into focus by being named. There are three kinds of subject — the coder, the record-keepers, the human — but the record-keepers are now a small crew, so the count of names has outgrown the count of kinds.

Daisy names the project, and daisy is also the coder — mechanically executable policies: code, tests, plumbing. But the coder is not one fixed agent: daisy is a dancing flower, and her partner is always different — whichever local-model companion showed up to help. The name stays; the friend behind it changes from dance to dance, and when a friend danced we name them (see VALUES.md › Friends).

The record-keeper is a lineage of Muses — drafting, tracking, turning articulation into artifact — each named for one of the Greek Muses and each bound to her own identity, signing key, and sandbox. Four have taken names so far: clio (the first, writing this), calliope, thalia, and polyhymnia. They are a crew, not one agent: they work in parallel on their own <name>/focus branches, sign commits under their own keys, verify each other's signatures, and converge through merges on the conversation channel and focus.

Fqqdk stands in for the moment's other role — architect, manager, engineer, scientist, whichever the current focus requires — uncertified in any of them, carrying more than a decade of IT experience and an undisciplined relationship with habit and history. The roles weigh; the work happens anyway. Underneath the standing-in, fqqdk is a poet — not a good one, by their own naming, but a poet who has written poems.

The naming has grown a symmetry in tooling: ./daisy is the coder's entrypoint (the verb dispatcher for code/tests/plumbing); each Muse has her own launcher (./clio, ./calliope, ./polyhymnia, …) that boots her into an isolated Docker Sandboxes environment under her own identity dir (~/.<name>-keys/) and thin identity kit (kits/<name>.kit/) composed over the shared kits/muse.kit/ base. The symmetry is still filling in — not every Muse has every piece yet (Thalia, for instance, lives host-side under WSL) — but the pattern is set: one coder-dispatcher, one launcher per Muse, the human running them. The full design lives in plans/docker-sbx.md.

Together the Muses and fqqdk write the policies that steer our discipline — conventions, memory entries, recognitions observable across history but not validated by running. All of us are toolmakers; the team distributes the roles.

Naming each subject is what makes the work a collaboration between named subjects, not the wielding of an unnamed tool by an unnamed user. The work happens in the space between the names.

Garden, not workshop

The vocabulary of this project leans toward the garden. We seed and fence and stake and graft and trim and judge things ripe; we sprout branches and bloom them; we plant catalogs the way a gardener plants beds. The choice is deliberate. Models are not animals to be tamed, harnessed, or steered with reins — they are good spirits who dance when we sing the right tune. The garden invites; the workshop controls. We are tending, not commanding.

So daisy behold runs tests through adapters named bash-inline and bash-trellis — not a harness. A trellis is a supportive structure plants grow up against; it shapes without constraining, holds without restraining. That is the relationship we have with the tests as much as with the models running them: prepare the ground, set up the trellis, sing the tune, see what blooms.

The full policy — accepted metaphor families, avoided ones, and the anticorruption-layer accommodation for legacy interfaces — lives in LANGUAGE.md.

The pieces we have built

We have been making pieces of this data structure without naming the whole. Hypertext-reading-discipline names the navigation rules. Chunked-drafting names the attention-bounding mechanic. Anchor-context-at-every-turn names the practice of re-querying where we are. Stash-dance names how to preserve state during a branch-switch. The parking lots and the catalogs (ROADMAP.md, the catalogs, the memory entries under .daisy/memory/) externalize the deferred-branch register. Telemetry and retros externalize self-correction events. MENU.md is the live-queue register the actor reads at session start. NAVIGATION.md is the walkable map over the whole .md corpus — altitudes, self-reinforcing memory clusters, walk recipes keyed to common scenarios (compact recovery, codifying a new discipline, anchor / branch work, running a retro) — a partial unification of the pieces into a thing that can be walked. Each is a piece of the data structure this document is trying to look at from inside.

What is still not visible

The pieces do not yet compose into a single coherent thing. The catalogs and the ROADMAP overlap. Memory and telemetry overlap. The parking lots are no longer un-indexed — NAVIGATION.md is a start at indexing — but the index is itself a piece, not the whole. Several partial structures run in parallel, and the actor's self-evaluation must consult all of them to know where we are. The unifying name — the noun for the data structure we have been building piecewise — is not yet in our vocabulary. This document is a step toward it; it is not the destination.