Generated Leaves

Eidos has exactly two derived views. They share three properties, and the properties matter more than the outputs:

• Regenerated wholesale. Never merged, never patched.
• Nothing hand-written to preserve. Anything you type into one is lost.
• They annotate, never gate. A stale leaf is a nuisance, not a failure.

The index

Each collection carries a generated index.md in its folder, listing its blueprints so a human or an agent can navigate without scraping the tree.

specs/index.md

# specs

<!-- index: specs (regenerated) -->

## playback
- [Watch a Video](playback/watch-a-video.md) — play a video reliably, signed in or not, adapting to the connection.
- [Resume Playback](playback/resume-playback.md) — returns a viewer to the exact second they stopped.

## channels
- [Subscribe to a Channel](channels/subscribe-to-a-channel.md) — follow a channel and get its new uploads.

Grouped under sub-folders when the collection has them, flat when it doesn’t. Links are relative to the collection folder. Rebuilt by the index skill.

Each line is the blueprint's `summary`, verbatim

A blueprint with no summary is flagged, never invented. That’s deliberate: an index that quietly writes a plausible one-liner for you is an index you can no longer trust, and it hides the fact that nobody has said in one line what the blueprint is.

Which makes summary worth more attention than its size suggests. It’s the only thing most readers will see of most blueprints — one plain line saying what this is. Write it as a distillation of the opening section, not as a title restated.

When to rebuild

After blueprints are added, renamed, moved, or removed. The index skill walks the framework’s declared collections, reads each one-level sub-folder, and rewrites each index.md wholesale.

It ships a build-index.py that does the walk deterministically where a shell is available, and falls back to doing it by hand on a sandboxed host.

The Blueprint Map

The spatial counterpart: an Obsidian .canvas file — JSON Canvas 1.0 — from the canvas skill.

Each collection draws the way its framework declares, in - **Canvas:**:

Declaration	Draws as
file	A full-file node — for prose meant to be read whole, like a frame.
card	A node embedding the blueprint.
card from ## Section	A node embedding just that section.
(absent)	A plain card.

Why absent doesn't mean 'guess'

The generator knows no collection by name. It cannot infer that ## Intent is the summary section of a spec, because in your framework it might be ## Premise or ## Question — or nothing at all. Declaring the section is how you tell it.

Structurally: each collection is its own group, and a grouped collection nests a group per sub-folder. Directories become nested group nodes.

Edges

Each blueprint’s connects_to links become directed edges — this → target. That’s the intentional map: what you’re asserting relates to what.

depends_on is off by default and can be overlaid in a distinct colour. It’s a different question — implementation dependency rather than conceptual connection — and mixing the two produces a diagram that means nothing. The distinction →

You choose which collections to include. Top-level documents are not mapped.

It’s the Blueprint Map

It draws blueprints and the edges between them. The framework is the one thing it never draws — which is what the name is for.

The generated .canvas is itself a top-level doc, so register it in ## Top-Level in Framework.md. The default filename follows the naming convention: blueprint-map.canvas under kebab-case.

Neither one gates

Both leaves annotate. A stale index or a missing canvas is never an error that stops anything — consistent with the standard’s portability over prescription.

They’re also both cheap to regenerate and safe to delete, which is the test for whether something belongs in this category at all. If it can’t be reconstructed from the blueprints, it isn’t a leaf; it’s content, and it belongs in a file someone owns.

Next

• Working with Agents
• Skills