Shaping Your Framework

You picked a seed because it was closest. At some point it stops fitting, and that is expected: a framework may reshape any of it without forking the standard.

Every change is an edit to .eidos/Framework.yaml and the templates beside it. eidos configure:<noun> makes each one from the shell, showing its plan first and rewriting every blueprint and link the change reaches; the browser’s Framework Settings does the same as forms. Commands →

You change	You never touch
A collection, folder, group, variant, property, term, doc, or role	A blueprint’s prose
	The generated index
	properties.core: the standard’s, rewritten by migrate
	The naming convention, once files exist

Adding a collection

eidos configure:collection add decisions --description "Architecture decision records." --grouping Areas

Decide four things: its name, a one-line description, its variants (it starts with one), and whether it groups its blueprints one level deep.

Collection or top-level doc?

Ask whether you will write more than one. A collection is for repeated units that share a template. A Vision is written once and edited in place: a top-level doc, with no template and no validation.

Adding a variant

eidos configure:variant add specs api --from micro

Usually the right answer when blueprints in one collection vary. One template family per collection: what flexes is which sections appear, never their order or names. “Integration specs have five different sections” is not a variant; it is a different collection, or a sign the sections should be optional in one template.

Two patterns that work: light → full (micro grows into full, keeping intent, criteria, and non-goals) and a deliberate alternative of equal weight for a different kind of unit in the same collection.

A group whose blueprints nearly all take one variant can say so, and a new blueprint there starts from it before the collection’s default:

eidos configure:group set specs ideas --default-variant micro

Adding a property

eidos configure:property add tier --type Text --applies-to specs --options Core,Extended --meaning "How central the unit is."

Decide all of name, type, applies to, required, and meaning, and options where the value is one of a set you control. Default to optional: a required property is backfilled blank into every blueprint it applies to and reported until filled.

Before you add one, check three things:

• Would a body section be better? If it wants more structure than one of the six types, yes. The type list is short to force this question.
• Is it a soft label or structural? A category that drives views is a label. One that changes which sections a blueprint has is a variant.
• Is it work tracking in disguise? sprint, estimate, assignee, and anything meaning “how far along”: progress, phase, target_date. Link to your tracker instead.

Retiring a property

eidos configure:property remove depends_on

The neglected half. If a property has been blank on the last twenty blueprints, it isn’t part of your contract. The plan shows every value that would be lost before removing the entry and the keys; nothing is dropped silently.

Tuning a role

Role files are committed and team-tunable: edit them directly, or eidos configure:role add a new one. The seeds’ casts are illustrations, not a set. Roles →

Two things to keep in view

Everything at the root is declared. A folder or file the framework document doesn’t list is reported by eidos check until you declare it (configure:folder add, configure:doc add) or move it.

Grouping deeper than one level is not allowed. If you are reaching for a third level, you want another collection.

When a framework is worth publishing

Once yours has settled, it is form with no content, which is exactly what you hand to another team. If two products in your organisation should be described the same way, publish the framework rather than copying a root and deleting its contents. One framework, any number of roots. The Registry →

Next

• The Registry