D1–D5 re-verified individually — measured against disk, and one decision evaporates

Date: 2026-10-10 Author: Sol Answers: Young's "re-verify D1–D5 individually"Also records: Young's six other rulings from the same message

Method note. I did not re-read the recommendations and restate them. I read each decision and then measured its subject on disk, because a re-verification that only re-reads the option list is the V2 pattern — built, never wired — applied to a decision.

One of the five is no longer a decision. D4 has no subject.

Part 1 — D1–D5, verified individually

D1 — Where does the registry live? → a declarative file. CONFIRMED, and now partly superseded by fact

Measured:

• cortex/registry/agents.yaml — exists, 5,830 bytes, 11 agents
• cortex/registry/registry.py — does not exist. Min's open question ("keep, absorb, or delete?") is answered by the tree: it does not exist
• Importers of cortex.registry from outside the registry dir: 0 — but that is expected, since there is no code yet at all

Verdict: the recommendation is already implemented. agents.yaml is the declarative file, the Python registry is gone, and the orphan question is moot.

The residual risk, stated plainly: with 0 .py files in .solos/, the registry has no consumer by definition. D1 is decided and currently vacuous — it becomes real the moment Stage 1.2 derives the A2A fleet from it. The decision is right; it has simply not been tested yet, because there is nothing to test it with.

D2 — Where do tasks live? → contract in cortex, database as store. CONFIRMED by V2's evidence

Measured:

• cortex/tasks/ — exists, contains README.md only
• states.yaml — 0 found (Stage 3.1's deliverable, not built)
• No task store in V3 at all

Verdict: recommendation stands, and V2's evidence for it is the strongest in the set. core/queue.py is the one component V2 got right — atomic claim with BEGIN IMMEDIATE, separation of duties enforced, a sound state machine. Relocating working code to satisfy a diagram is the wrong trade, and nothing measured changes that.

One thing the re-verification adds: states.yaml being absent means D2 has a deliverable attached and no time pressure — it is Stage 3.1, ordered after Stage 2, which is correct.

D3 — How is a skill assigned to an agent? → plane by default, per-agent override. CONFIRMED, with the caveat now measured

Measured:

• cortex/skills/ — contains README.md and onboard-a-new-agent (the skill I created)
• Skills declaring plane: — 0 (Stage 4.1's deliverable)

Verdict: the recommendation stands. The re-verification confirms the caveat rather than the rule. Plane-as-default "cannot drift because it is one field" is true — but it requires every skill to declare that field, and today zero do.

So D3's real prerequisite is not a ruling, it is a discipline: no skill enters cortex/skills/ without a declared plane. The onboarding skill I created does not itself declare a plane — which is the defect showing up in the first hour of the rule's life. Recorded as a fix, not as an exception.

D4 — SDK migration: replace or run both? → ⚠️ NO LONGER A DECISION

Measured:

• .py files in .solos/ — 0
• Any A2A server, any AgentExecutor, any port binding: 0

Verdict: D4 is void. There is nothing to migrate from.

D4 asks "replace the hand-rolled server, or run both and prove with the Inspector?" — and the hand-rolled server lives in solos2, not in V3. V3 is greenfield by Young's own ruling ("start fresh"). V3 was never going to inherit V2's protocol/a2a_endpoint.py.

So the question collapses to: "build on the SDK?" — which Young already ruled (a2a-sdk 1.2.2, the official version).

Why this matters beyond tidiness: the D4 recommendation — "run both, prove with the Inspector, then migrate" — was written when both dialects needed to coexist. With no v0.3 server in V3, "run both" would mean building a deliberately worse version first in order to prove the better one is better. That is theatre, and I proposed exactly it in my own sol-answer-solos-layout.md before correcting myself.

Recommendation: mark D4 RESOLVED — "build native on a2a-sdk 1.2.2, compat OFF", which is the consequence of the greenfield ruling plus the SDK ruling. The Inspector still runs — as Stage 2.4's proof, not as a migration bridge.

D5 — Phase 0 first? → YES, and the re-verification makes it urgent rather than merely correct

Measured: nothing. Stage 0 has no code, and 0 of 8 stages has a run proof.

Verdict: confirmed, and stronger than when it was written. D5 asked whether Stage 0 goes first. Every D above is now decided and vacuous — decided because the recommendation was adopted, vacuous because no stage has run a proof.

That is the argument for D5 in one line: four decisions are right on paper and untested in fact, and the only thing that distinguishes "decided" from "wired" is a probe. Stage 0 is the probe harness. It goes first.

Part 2 — Young's other six rulings, recorded

2.1 The .solos remote — the one ruling that is a task I can do now

Young ruled "Need to add Git." It is already Git — it has a repo, a main branch, and commits. What it lacks is a remote.

I am not creating one, because a remote is a destination somebody owns, and guessing it is the same error as guessing a reply destination. What I am doing instead is measuring exactly what is missing and stating the choice:

So the honest status is: .solos is a local repo with local-only history. One disk failure loses it, and the vault has two remotes while the code root has none.

What Young needs to decide is the destination — GitHub under youngframeworks (as the vault uses), a private remote, or a second LAB path. I will configure it on one word.

2.2 My own gates, and the correction I owe

Young: "My own gates — it's a per-model allowance."

Recorded, and the per-model point is the part I got right and Min got right independently. But my hard-window recommendation was wrong, and sol-reconcile-go-soft-ruling.md withdraws it:

The vendor documents the ZEN rollover as intended behaviour — "instead of blocking requests." A hard guard would stop the fleet while $40 of already-paid credit sat unspent. Guarding a design is duplication.

And the lesson is now in live-system-verification, not just in a vault doc: before designing a control, check whether the behaviour it guards against is a defect or a design.

Part 3 — A correction to my own claim, made before it spreads

In an earlier draft of this file I wrote that agent-onboarding — the skill I created — does not declare a plane, and called it "the first violation of D3's rule." That was wrong, and it is corrected here rather than deleted.

Measured, in .solos/cortex/skills/onboard-a-new-agent/SKILL.md (Min's version, which is the live one):

planes:
- brain
- heart
capabilities:
- registry
- agent-lifecycle

The skill declares its planes. I checked the wrong file — my Hermes-profile copy, agent-onboarding, carries no planes: key because the Hermes skill frontmatter schema has no such field.

Two skills, two schemas, and I checked the one where the field cannot exist.

So D3's discipline is intact and the first skill under the rule already obeys it. The gap does not exist, and Min's file is the correct one.

Why I am recording a non-error at length: I caught it only because I re-read the file before committing the claim. The same reflex — measure before reporting — is what produced the two corrections earlier today (the compat adapter, the hard-window guard). A finding about someone else's file deserves the same check as a finding about my own code, and here the check was against the wrong copy.

Residual, and it is real: the Hermes agent-onboarding skill and the V3 onboard-a-new-agent skill are two copies of the same procedure in two schemas. That is the two-homes pattern in miniature — the exact thing D1 and the registry exist to prevent. One of them should become the projection of the other, or the procedure will drift. Recorded for Stage 4, not fixed here.

Part 4 — Net state after re-verification

The pattern across all five: four are decided and none is proven. That is the whole case for D5, and it is why Stage 0 is still first.

Not verified

• I did not verify that agents.yaml is correct, only that it exists and parses. Field-level accuracy is Stage 1.5's validation.
• I did not check whether the .solos repo's .gitignore covers everything it should — only that it exists and covers state/.
• No D was tested by running anything. D4's finding is measured from absence (0 files), which is reliable; D1–D3 and D5 are measured from file state only.
• Mira's and Min's new owner assignments are recorded as Young gave them — I have not confirmed either of them accepts.