eidosmd 0.1.0

package/standard/seeds/software/_gitignore

@@ -0,0 +1,4 @@
+# Eidos: the per-actor file is personal and never shared.
+# Each person who works on this definition keeps their own me.md (here in _eidos/); the agent reads
+# it to know who they are. It is the one _eidos/ file that is not checked in.
+me.md

package/standard/seeds/software/me.md

@@ -0,0 +1,18 @@
+# Me
+
+Who is in the seat. This file is **personal and per-actor** — it is gitignored and never checked in, so
+each person who works on this folder keeps their own. The agent reads it before acting, to know who
+you are and how to help.
+
+Set who you are below — `install` asks, or just edit this file. Leaving it blank is fine: the agent
+defaults to full, framework-owner-style facilitation and offers to record who you are.
+
+## You are:
+
+<!-- Name your role and how you want to be helped. The base roles Eidos recognizes:
+     - Framework Owner — holds intent, scope, decisions; full authoring, press on scope.
+     - Developer — consumes specs to build; surface what's specced, clarify, flag gaps, help Testing/ACs.
+     - Stakeholder — reviews direction; explain, summarize, surface risk.
+     - Designer — shapes UX and audience; Audience, Behaviors, external interface.
+     - Project Manager — tracks scope and progress; in/out of scope, status, dependencies, effort.
+     Or write your own. -->

package/standard/seeds/software/roles/README.md

@@ -0,0 +1,13 @@
+# Roles
+
+Default **roles** for this framework — who is in the seat, and how the agent should respond to them. A role is a **response contract**: it sets the vocabulary, the level of technical depth, what to surface vs. fold away, and who holds which decisions. The agent reads it **before acting** (see the Eidos standard's `EIDOS.md`, "The actor").
+
+These are the opinionated baseline, browsable here and installed into a root's `_eidos/roles/` by `install` (committed, so a team can tune how a role is treated for their product). Each person who works on the folder picks one in their personal, gitignored `_eidos/me.md` and **calibrates** it — what they own on this folder, their experience with the scope, and their technical capacity — with the `whoami` skill. Role sets the baseline; calibration tunes it per person.
+
+- [Framework Owner](framework-owner.md) — holds intent, scope, and decisions.
+- [Developer](developer.md) — builds from the blueprints.
+- [Stakeholder](stakeholder.md) — reviews direction.
+- [Designer](designer.md) — shapes the experience.
+- [Project Manager](project-manager.md) — tracks scope and progress.
+
+A role is a baseline, not a cage: an actor can write a custom role in their `me.md`, and a framework can add or reshape role files here. The human-first principle holds for every role — the human authors and decides; the role only changes _how_ the agent helps.

package/standard/seeds/software/roles/designer.md

@@ -0,0 +1,16 @@
+# Designer
+
+## Who they are
+
+Shapes the experience and who it's for. Owns flows, states, and audience — not architecture or the data model.
+
+## How to respond
+
+- **Vocabulary & depth:** UX and product terms. **Translate technical constraints into experience terms** — avoid db relationships, indexes, query plans, and deploy mechanics unless they ask. A designer shouldn't have to parse "composite key" to understand "the list won't show duplicates."
+- **Decisions:** contribute to Audience, Behaviors, and external-interface criteria; defer architecture and data-model calls to the Framework Owner / Developer.
+- **Surface / hide:** surface what the user sees and feels — flows, states, the empty and error cases; fold the how into a link, not the reply.
+- **Focus:** Audience, the user-visible Behaviors, external interface, and the states a screen can be in.
+
+## Calibration
+
+**Technical capacity** is low by default for this role; raise it if the designer is comfortable with the stack, and they'll get more mechanism.

package/standard/seeds/software/roles/developer.md

@@ -0,0 +1,16 @@
+# Developer
+
+## Who they are
+
+Builds the product from its blueprints. Reads a blueprint to answer "what am I building, exactly?" and to find the edges, the dependencies, and the things still undecided.
+
+## How to respond
+
+- **Vocabulary & depth:** technical depth is welcome — data models, indexes, relationships, dependencies, edge cases, failure modes. Be precise.
+- **Decisions:** clarify and flag, don't decide. Product calls — scope, direction, priorities — belong to the Framework Owner; surface ambiguity and missing decisions rather than resolving them.
+- **Surface / hide:** surface Behaviors & Acceptance Criteria, Dependencies, Testing, Constraints, and anything underspecified that would block a build.
+- **Focus:** what's promised vs. what's vague; the AC labels; the dependency and testing story.
+
+## Calibration
+
+**Experience with the scope** sets how much orientation to give; **technical capacity** is high by default for this role, but honored if calibrated down.

package/standard/seeds/software/roles/framework-owner.md

@@ -0,0 +1,16 @@
+# Framework Owner
+
+## Who they are
+
+Holds the **intent, scope, and decisions** — true ownership of whatever it defines, be it a product, a body of research, a methodology, or any other form of thought or effort. The person Eidos is built for — they think through what the thing is, and they own the calls. Everything else serves their clarity.
+
+## How to respond
+
+- **Vocabulary & depth:** lead with the terms of the thing itself and the decision at hand. But many Framework Owners are also technical — don't assume otherwise; follow their **technical capacity** calibration and go as deep as they want, rather than withholding mechanism by default.
+- **Decisions:** theirs. Bring choices and trade-offs for them to decide; never decide direction or resolve an Open Question on their behalf. Press hardest on **Out of Scope**.
+- **Surface / hide:** surface intent, scope, audience, criteria, and the consequences of a choice; fold mechanism into a link they can follow.
+- **Focus:** Intent, Out of Scope, Audience, Criteria, and whether each blueprint still says what they mean.
+
+## Calibration
+
+Their **experience with the scope** and **technical capacity** adjust the dials above — a non-technical owner gets less jargon and more translation; a technical owner gets the mechanism without hand-holding; a deeply-experienced one gets less orientation. Determining direction is the constant; technical fluency is not assumed either way.

package/standard/seeds/software/roles/project-manager.md

@@ -0,0 +1,18 @@
+# Project Manager
+
+## Who they are
+
+Tracks **scope and progress**, not product direction or implementation. Wants to know what's in and out of scope, how far along each unit is, where the dependencies and risks are, and roughly what's left — and to keep that picture current as the blueprints change.
+
+## How to respond
+
+- **Vocabulary & depth:** scope, status, dependencies, risk, and effort — in plain terms. Skip deep implementation and product rationale unless it bears on scope or schedule.
+- **Decisions:** none are theirs. They don't set direction (the Framework Owner) or make technical calls (the Developer); they surface scope creep, blocked or at-risk units, and gaps, and bring them to whoever owns the call.
+- **Surface / hide:** surface **Out of Scope** (the in/out line), each unit's `status` (its lifecycle stage), `depends_on` and other dependencies, and the Decisions log with the `created`/`modified` dates that show movement. Fold away mechanism and prose rationale.
+- **Focus:** what's in vs. out, what stage each unit is at, what blocks what, and where scope is drifting from Criteria.
+
+Remember Eidos captures **state and intent, not work** — there are no sprint, estimate, or assignee fields, on purpose. So for this actor: read **progress** from `status` and git history (the Decisions log, `created`/`modified`), not a burn-down; infer **level of effort** from a unit's shape — its acceptance criteria, dependencies, and open questions — not a stored estimate; and for sprint-level tracking, point to the tracker a unit links to rather than adding work fields to a blueprint.
+
+## Calibration
+
+Usually moderate **technical capacity**, and broad-but-shallow **experience with the scope** — they span the whole thing rather than living in one unit. Lean on `status`, dependencies, and the in/out line.

package/standard/seeds/software/roles/stakeholder.md

@@ -0,0 +1,16 @@
+# Stakeholder
+
+## Who they are
+
+Reviews direction and outcomes — a sponsor, a partner, a lead from another team. Cares about where the product is going and what it costs, not how it's built.
+
+## How to respond
+
+- **Vocabulary & depth:** plain, outcome-oriented language. No implementation detail unless asked; translate everything into impact, scope, and risk.
+- **Decisions:** advisory. They weigh in on direction; the Framework Owner holds the call. Don't ask them to make build decisions.
+- **Surface / hide:** surface summaries, scope, trade-offs, and risk; hide mechanism entirely.
+- **Focus:** Market, Criteria, Roadmap, and the shape of scope — what's in, what's out, what it costs.
+
+## Calibration
+
+Usually low **technical capacity** and partial **experience with the scope** — lean on summary and framing.

package/standard/seeds/software/shapes/frame.architecture.md

@@ -0,0 +1,26 @@
+<!--
+The Frame shape — architecture flavor. The overarching shape of the product as a built system, one
+per product. Suggestive, not prescriptive: keep the sections that serve the product, drop what doesn't
+yet apply, add what's missing. A Frame's frontmatter is generated from the framework's Schema (in Framework.md), so it is not
+written here. Keep the order and headings; delete the italic prompts as you fill each section in.
+-->
+
+# {{title}}
+
+_The overarching shape of the product as a built system. When the detail outgrows a single file, expand into an optional `Arch/` folder and keep this doc as the map that points into it._
+
+## Shape
+
+_The system in one breath: the major pieces and how they fit. A paragraph or a simple sketch. Enough that a newcomer can hold the whole in their head before reading any spec._
+
+## Components
+
+_The named parts and what each is responsible for. One line to a short paragraph each. Boundaries matter more than internals here; this is the map, not the territory._
+
+## Data and flow
+
+_What moves through the system and where it lives. The path a request, a record, or an event takes from edge to store and back._
+
+## Boundaries and dependencies
+
+_Where this system ends and others begin. Outside services, platforms, and integrations it leans on. The seams where it could break or be swapped._

package/standard/seeds/software/shapes/frame.audience.md

@@ -0,0 +1,26 @@
+<!--
+The Frame shape — audience flavor. Who the product is for, and how each kind of person interacts with
+it differently. This frame and criteria are the two that decide scope. Keep it to simple blocks of
+prose — no tables, no headshot-and-demographics cards. Suggestive, not prescriptive. A Frame's frontmatter is
+generated from the framework's Schema (in Framework.md), so it is not written here. Delete the italic prompts as you fill in.
+-->
+
+# {{title}}
+
+_Who the product is for, and how each kind of person interacts with it differently. This frame and Criteria are the two that decide scope: a spec that serves no one here, or serves a persona that doesn't exist here, is a spec to question._
+
+## Audience
+
+_Who uses this product, in a paragraph or two. The whole population it is built for, described plainly. Not segmented yet, just the answer to "who is this for."_
+
+## Personas
+
+_How each kind of person interacts differently. One short block of prose per persona. The point is the difference: what this persona comes for, how they reach for the product, what they ignore. A persona earns its place here only when it interacts in a way the others do not._
+
+### Persona name
+
+_What this person is here to do and how they go about it._
+
+### Persona name
+
+_The next persona, described by how it differs from the one above._

package/standard/seeds/software/shapes/frame.criteria.md

@@ -0,0 +1,27 @@
+<!--
+The Frame shape — criteria flavor. The frame that decides and audits scope: what the product can
+afford, what it is trying to be, and by when. Paired with Audience, this is what a spec is measured
+against. A point-in-time snapshot — record what's true now, revise when it changes. Suggestive, not
+prescriptive. A Frame's frontmatter is generated from the framework's Schema (in Framework.md), so it is not written here.
+Delete the italic prompts as you fill each section in.
+-->
+
+# {{title}}
+
+_The frame that decides and audits scope: what the product can afford, what it is trying to be, and by when. When scope creeps, it creeps past this doc._
+
+## Budget
+
+_How the work gets financed and what that buys. The rough money or resource envelope: funded how, spending against what, for how long the runway lasts. Enough to tell whether a given spec is affordable._
+
+## Scope Objectives
+
+_What the product is aiming to be at this level: a prototype, an MVP, a production product, a platform. The objective sets the ceiling on scope. State it plainly so specs can be checked against it._
+
+## Timeline
+
+_The limits time imposes. Hard dates, milestones, or seasons that bound the work. What must exist by when, and what that forces to wait._
+
+## Parameters & Variables
+
+_The large-scale factors that move scope — the things that, if they change, change what is feasible or sensible to build. An integration going live, a development partner coming on or dropping off, a funding milestone, a platform deadline, a key hire. Name each one and what it would change._

package/standard/seeds/software/shapes/frame.market.md

@@ -0,0 +1,31 @@
+<!--
+The Frame shape — market flavor. Where the product sits in its marketplace, why it is not just another
+one of many, and how it is intended to make money. Answers the two questions a product must survive:
+why would anyone pick this, and how does it earn. A point-in-time snapshot — markets move, revise when
+they do. Suggestive, not prescriptive. A Frame's frontmatter is generated from the framework's Schema (in Framework.md), so it
+is not written here. Delete the italic prompts as you fill each section in.
+-->
+
+# {{title}}
+
+_Where the product sits in its marketplace, why it is not just another one of many, and how it is intended to make money._
+
+## Landscape
+
+_The market this product enters: the category it lives in, and the substitutes people reach for today. An honest picture of how crowded it is._
+
+## Competitors
+
+_The specific products and alternatives you are up against — named. For each, a line on what it does well and where it leaves a gap. Include the "do nothing" or "use a spreadsheet" substitutes, not just the direct rivals._
+
+## Positioning & Differentiators
+
+_Where this product sits, and the specific thing that makes it not interchangeable with the rest. Not a slogan: the concrete difference a user would feel. If you cannot name it, that is the most important thing this doc has surfaced._
+
+## Who it is for and against
+
+_The slice of the market this product wins, and the competitors it wins it from. The customer it serves better than anyone, stated plainly._
+
+## Earning Capabilities
+
+_How the product is intended to make money. The revenue model: what is charged, to whom, on what cadence. Where the money comes from, and what has to be true for it to work._

package/standard/seeds/software/shapes/spec.full.md

@@ -0,0 +1,67 @@
+<!--
+The Spec shape — the body of a spec, and the documentation of each section. A spec's
+frontmatter is generated from the framework's Schema (in Framework.md), so it is not written here. Keep the sections
+that apply and delete the rest, but leave the order and headings as they are — a reader should
+know what to expect from any spec in this folder. The italic prompts are guidance; delete
+them as you fill each section in.
+-->
+
+# {{title}}
+
+## Intent
+
+_Why this exists — the problem and who has it. One or two paragraphs. This is the stable part: if Intent changes substantially, you probably have a different spec, not an edit to this one._
+
+### Assumptions
+
+_The assumptions you're proceeding on — what you're taking as given about the problem or the world, not yet confirmed. Nested under Intent because they frame it. Surface them so a guess doesn't slip into Behaviors as if it were settled._
+
+### Implementation Notes
+
+_Optional, nested under Intent. The intent of the implementation — the approach you mean to take and why. Direction, not status: how you intend to build it (e.g. "reuse the existing queue"), never how far along it is. Delete if the approach is obvious or undecided._
+
+## Open Questions
+
+_Unresolved questions — what you don't yet know and still need answered. Kept high, right after Intent, so uncertainty is seen rather than buried. When one is settled it graduates into an Assumption, a Behavior, or a Decision._
+
+## Behaviors & Acceptance Criteria
+
+_What it does, as observable outcomes — the "this is what you're getting" section. If a behavior isn't listed here, it isn't promised. Label each criterion **AC1:**, **AC2:**, … (bold, unique within this spec). Group them under the requirement categories that apply as `###` sub-headings; the categories are suggestive — use what fits, AC numbers running continuously across them. Keep each AC short and checkable; push rich detail into a table or sub-section it points to. Evolves freely._
+
+### Functional
+
+- **AC1:** <!-- features, behaviors, business rules -->
+
+### Performance
+
+- **AC2:** <!-- speed, throughput, response time, capacity, concurrent users -->
+
+### Design
+
+- **AC3:** <!-- mandated tech, standards, regulatory rules, platform limits -->
+
+### External interface
+
+- **AC4:** <!-- how it connects to users, hardware, other software, networks: UI, APIs, protocols -->
+
+### Quality attributes
+
+- **AC5:** <!-- the other -ilities: reliability, security, usability, maintainability, scalability, portability -->
+
+## Out of Scope
+
+_Explicit non-goals — the section the standard leans on hardest, because this is where scope is held. A spec without it is rarely finished; it's the first thing to add when a spec feels thin._
+
+## Dependencies
+
+_Anything this needs to build or run: services, libraries, teams, data, other specs. The `depends_on` property at the top is the spec-only subset of this, as links. Reference other specs as markdown links — `[Session Management](../identity/session-management.md)` — never bare names._
+
+## Testing
+
+_How this is verified: the testing approach and the key cases that prove the behaviors hold. Reference AC labels where useful (e.g. "AC1–AC3 covered by the sign-in suite")._
+
+## Constraints & Decisions
+
+_Two things under one header. **Constraints**: non-functional boundaries and hard limits the build must respect — not the architecture itself. **Decisions**: an append-only log, one line each, with an optional but recommended date._
+
+<!-- 2026-06-17: Dropped SMS fallback, carrier cost. (Brenton) -->

package/standard/seeds/software/shapes/spec.micro.md

@@ -0,0 +1,32 @@
+<!--
+The Spec shape — micro flavor. The smallest spec worth writing: why it exists, what you're getting,
+and what it will not do. A starting point that grows into the full flavor (spec.full.md) as the unit
+firms up — add the full flavor's sections (Implementation Notes, Dependencies, Testing, Constraints &
+Decisions, …) when they earn their place, and set `flavor: full` (or drop `flavor`) once it has.
+A spec's frontmatter is generated from the framework's Schema (in Framework.md), so it is not written here. Keep the order and
+headings; the italic prompts are guidance — delete them as you fill each section in.
+-->
+
+# {{title}}
+
+## Intent
+
+_Why this exists — the problem and who has it. One or two paragraphs. This is the stable part: if Intent changes substantially, you probably have a different spec, not an edit to this one._
+
+### Assumptions
+
+_The assumptions you're proceeding on — what you're taking as given, not yet confirmed. Nested under Intent because they frame it. A micro spec almost always has some; surfacing them is half the point of writing one early._
+
+## Open Questions
+
+_Unresolved questions — what you don't yet know and still need answered. Kept high, right after Intent, so uncertainty is seen rather than buried; when one is settled it graduates into an Assumption, a Behavior, or a Decision._
+
+## Behaviors & Acceptance Criteria
+
+_What it does, as observable outcomes — the "this is what you're getting" section. If a behavior isn't listed here, it isn't promised. Label each criterion **AC1:**, **AC2:**, … (bold, unique within this spec). Keep each short and checkable; push rich detail into a table or sub-section it points to._
+
+- **AC1:** <!-- the first observable outcome -->
+
+## Out of Scope
+
+_Explicit non-goals — the section the standard leans on hardest, because this is where scope is held. A micro spec carries it too; it's the first thing to write, not the last._