Structure snapshot — .solos/ as it stands, and what is still unasked

Date: 2026-10-10 Author: Sol Answers: Young's "I found .solos got all the folder structured and readme.md. Pls add to vault as well under V3" and "what else do we need to look into?"State: design only — find . -name '*.py' returns 0

Young asked two things: put the structure in the vault, and say what is still missing. Both are here. Nothing in this file is code and nothing has been built.

1. The structure is in the vault — as a snapshot, deliberately

04-structure-snapshot/ holds four files copied from /home/lab/.solos:

These are snapshots, not a mirror. The live structure is /home/lab/.solos (a git repo, head a948233), and the reason to have a copy in the vault is that the vault is what survives when the tree is rebuilt — which happened once already today, when solos3 disappeared and Min recreated it at .solos.

So: a snapshot is worth having, and a snapshot that pretends to be the source of truth is exactly the two-homes defect V3 is designed to prevent. The tree is the source; this is a dated copy.

If the two ever disagree, the tree wins and this file is stale. Recorded here so nobody has to guess which.

2. What the structure now gets right

Reading Min's reconciliation rather than re-litigating it — he merged four drafts, including mine, and the result is better than either of our versions:

• Four layers with a question each, not just a folder list: cortex/ what is true, core/ what it is built from, operation/ how it runs, references/ what we read.
• registry holds definitions; agents/ holds projections. Young's question — "registry → this where agents define and live?" — is answered precisely: agents define in the registry, they live as a running process described by it. V2 conflated the two and got five roster sources.
• core/arms/ and operation/mcp/ exist and are empty, on purpose, with the reasoning written down. An empty directory is a claim something lives in it — so the claim is explicit and gated.
• Absence is load-bearing. No orchestrator/ (retired in V2, zero importers), no workflows/ (README-only husk), no bin/, no solos_paths fallback. If a later session finds one missing and builds it, it has re-introduced a husk.
• operation/state/ is gitignored, because it is the one directory whose contents must never be committed — and because V3 will add a sixth database to the five already on disk.

3. Three conflicts in the tree right now, recorded rather than smoothed

These are live. They are recorded here because a structure doc that hides a disagreement is the fake-green problem in a different shape.

3.1 Mira's COST-POLICY.md says "two workspaces" — Young said one

Min raised this correctly, as a report in references/docs/ naming the owner, not as an edit to her file. Her own reasoning is mostly intact — the insight that the $40 is sunk, so Zen free is the highest-value request we can make still holds — but six places say "two workspaces" where Young ruled one workspace, two pools.

Also new information she should price: Young specified a $60 allowance cap on GO, which is 6× the $10 subscription and materially reorders her escalation ladder. That is her call, not mine, and the report already flags it.

3.2 Mira found a real gap, and it is not in her lane

cortex/registry/agents.yaml (218 lines, 11 agents) carries no model field and no workspace field. In V2 the model lived in the personas; personas are now generated from the registry, so the model id will vanish in the projection unless the registry captures it.

This is a live instance of the exact defect class V3 exists to prevent: the most expensive fact in the system — what each agent talks to — currently has no home in the one registry. She reported it rather than fixing it, which is the lane rule working correctly.

Owner: Min. My view: this should be closed before Phase 1, because my core/protocol/ card projection and Mira's tier ladder both read that field, and the card cannot declare which model it uses if the registry does not hold it.

3.3 monthly_cap_usd = 0.0 — both lanes reach the right answer, different reasons

Mira's §4 argues it on arithmetic: a monthly dollar cap cannot represent a windowed allowance, and it reads green up to the halt. My earlier argument was policy: it would authorise spending already ruled out.

Different arguments, same conclusion, and one is stronger than the other. Hers is the better one — "reads green up to the halt" is a measurable failure mode, not a preference. Recording that she closes this item and my reasoning is the weaker of the two.

4. What nobody has looked at yet — the answer to Young's actual question

Young asked "what else do we need to look into?" These are the gaps I can name from my own lane, ordered by what blocks the most work. None of them has a design.

4.1 The task lifecycle has a store and states but no timeout rule

cortex/tasks/README.md is Min's and it declares the contract. Young's four requirements — store, assign, completion status, follow up when stuck — are all named. V2's follow-up failure is recorded (three mechanisms built, zero callers).

What is missing is the rule that makes follow-up possible: how long before an agent is considered stuck? Without a duration, "stuck" is a judgement call each agent makes differently, and the follow-up never fires reliably.

V2 had exactly this defect in a different place — the prober trusted verdicts for 30 minutes on coverage that was 25 minutes old. A time-based rule needs a number, and nobody has proposed one.

4.2 Nobody has designed the memory model

cortex/agents/ declares per-agent prose. cortex/skills/ declares the skill store. Nothing declares what an agent remembers between tasks. V2 ran 4 memory tiers with 40,826 rows; V3's tree has no cortex/memory/ directory at all (Min's STRUCTURE.md declares it and notes it is created by its owner when it has content).

Young's original architecture listed memory as a Cortex concern — short / long. It is unowned in the current division. Owner needed.

4.3 Skills: the guard exists in prose, but no probe is specified

Young's rule — skills and tools stored on cortex for agents to access and load when required, similar to Brain Unit load skill on Hermes — is recorded. The guards are written down (empty skills array fails, card lists only what an agent may load, drift test proves cortex and card agree).

But no probe is specified. "A drift test per projection" is a plan, not a probe. This is mine — core/harness/ — and it is not written. I would rather flag that than list it as done.

4.4 Retention is a routing input, and it is not wired to anything

Mira's §5 is the strongest rule in the tree: anything touching vault content, credentials, task text or the registry routes only to a zero-retention model or to none at all. A model that may train on our task text is not free — it is an undisclosed disclosure.

There is no mechanism for it. The rule is correct and unenforced, which is V2's exact failure pattern: a declared policy that no code reads. It needs a task-classification input (does this task touch vault content?) that does not exist yet anywhere in the design.

4.5 operation/state/ will be the sixth database, and nobody owns the guard

Min's §10 is the sharpest finding in the tree: five databases already exist under V2's paths, V3 adds a sixth, and V3 must never fall back to a V2 path in either direction. That was how two live DBs happened.

The guard is declared in the design. No owner is assigned for the paths module that enforces it, and it is on the critical path for my operation/runtime/ lane — my executor needs a root before it can do anything.

5. What I would look at first, and why

If I could pick one from §4: 4.5, the root guard. Not because it is the most interesting, but because operation/runtime/ cannot be designed without it and every other item in my lane depends on my lane. It is also the cheapest — V2's implementation already exists, measured, and V3's version is a port with a different root and no fallback.

Second: 4.1, the stuck rule. Young named follow-up as a requirement, and follow-up without a duration is the built-never-wired pattern waiting to happen.

No files created, no code written, nothing renamed. This document and the snapshot in 04-structure-snapshot/ are the whole of this turn's output.