eidosmd 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +133 -0
- package/NOTICE +15 -0
- package/README.md +146 -0
- package/browser/index.html +268 -0
- package/dist/src/cli.js +5 -0
- package/dist/src/commands/agents.js +47 -0
- package/dist/src/commands/browser.js +40 -0
- package/dist/src/commands/check.js +61 -0
- package/dist/src/commands/convert.js +30 -0
- package/dist/src/commands/framework.js +76 -0
- package/dist/src/commands/index.js +64 -0
- package/dist/src/commands/init.js +66 -0
- package/dist/src/commands/instructions.js +40 -0
- package/dist/src/commands/list.js +73 -0
- package/dist/src/commands/new.js +68 -0
- package/dist/src/commands/seeds.js +40 -0
- package/dist/src/commands/show.js +24 -0
- package/dist/src/commands/whoami.js +84 -0
- package/dist/src/context.js +35 -0
- package/dist/src/core/blueprint.js +129 -0
- package/dist/src/core/check.js +407 -0
- package/dist/src/core/convert.js +37 -0
- package/dist/src/core/framework-markdown.js +233 -0
- package/dist/src/core/framework-model.js +48 -0
- package/dist/src/core/framework-structured.js +334 -0
- package/dist/src/core/framework.js +56 -0
- package/dist/src/core/frontmatter.js +116 -0
- package/dist/src/core/index-leaf.js +83 -0
- package/dist/src/core/markdown.js +100 -0
- package/dist/src/core/me.js +89 -0
- package/dist/src/core/naming.js +46 -0
- package/dist/src/core/root.js +88 -0
- package/dist/src/core/scaffold.js +118 -0
- package/dist/src/core/seed.js +223 -0
- package/dist/src/core/server.js +275 -0
- package/dist/src/core/shape.js +26 -0
- package/dist/src/output.js +38 -0
- package/dist/src/paths.js +28 -0
- package/dist/src/program.js +242 -0
- package/instructions/authoring.md +50 -0
- package/instructions/configuring.md +65 -0
- package/instructions/init-required.md +32 -0
- package/instructions/overview.md +37 -0
- package/instructions/validating.md +33 -0
- package/package.json +53 -0
- package/standard/EIDOS.md +324 -0
- package/standard/seeds/README.md +25 -0
- package/standard/seeds/book/Framework.md +87 -0
- package/standard/seeds/book/README.md +22 -0
- package/standard/seeds/book/_gitignore +4 -0
- package/standard/seeds/book/me.md +18 -0
- package/standard/seeds/book/roles/README.md +12 -0
- package/standard/seeds/book/roles/collaborator.md +16 -0
- package/standard/seeds/book/roles/editor.md +16 -0
- package/standard/seeds/book/roles/framework-owner.md +16 -0
- package/standard/seeds/book/roles/reader.md +16 -0
- package/standard/seeds/book/shapes/chapter.full.md +45 -0
- package/standard/seeds/book/shapes/chapter.sketch.md +26 -0
- package/standard/seeds/book/shapes/frame.market.md +23 -0
- package/standard/seeds/book/shapes/frame.premise.md +24 -0
- package/standard/seeds/book/shapes/frame.reader.md +23 -0
- package/standard/seeds/book/shapes/frame.voice.md +24 -0
- package/standard/seeds/research/Framework.md +88 -0
- package/standard/seeds/research/README.md +23 -0
- package/standard/seeds/research/_gitignore +4 -0
- package/standard/seeds/research/me.md +18 -0
- package/standard/seeds/research/roles/README.md +12 -0
- package/standard/seeds/research/roles/framework-owner.md +16 -0
- package/standard/seeds/research/roles/researcher.md +16 -0
- package/standard/seeds/research/roles/reviewer.md +16 -0
- package/standard/seeds/research/roles/sponsor.md +16 -0
- package/standard/seeds/research/shapes/frame.ethics.md +23 -0
- package/standard/seeds/research/shapes/frame.method.md +24 -0
- package/standard/seeds/research/shapes/frame.prior-work.md +23 -0
- package/standard/seeds/research/shapes/frame.question.md +24 -0
- package/standard/seeds/research/shapes/investigation.full.md +49 -0
- package/standard/seeds/research/shapes/investigation.note.md +26 -0
- package/standard/seeds/software/Framework.md +88 -0
- package/standard/seeds/software/README.md +24 -0
- package/standard/seeds/software/_gitignore +4 -0
- package/standard/seeds/software/me.md +18 -0
- package/standard/seeds/software/roles/.gitkeep +0 -0
- package/standard/seeds/software/roles/README.md +13 -0
- package/standard/seeds/software/roles/designer.md +16 -0
- package/standard/seeds/software/roles/developer.md +16 -0
- package/standard/seeds/software/roles/framework-owner.md +16 -0
- package/standard/seeds/software/roles/project-manager.md +18 -0
- package/standard/seeds/software/roles/stakeholder.md +16 -0
- package/standard/seeds/software/shapes/.gitkeep +0 -0
- package/standard/seeds/software/shapes/frame.architecture.md +26 -0
- package/standard/seeds/software/shapes/frame.audience.md +26 -0
- package/standard/seeds/software/shapes/frame.criteria.md +27 -0
- package/standard/seeds/software/shapes/frame.market.md +31 -0
- package/standard/seeds/software/shapes/spec.full.md +67 -0
- package/standard/seeds/software/shapes/spec.micro.md +32 -0
|
@@ -0,0 +1,26 @@
|
|
|
1
|
+
<!--
|
|
2
|
+
The Chapter shape, sketch flavor — the smallest useful chapter blueprint, meant to grow into
|
|
3
|
+
`chapter.full` once it earns it. A chapter's frontmatter is generated from the framework's Schema (in
|
|
4
|
+
Framework.md), so it is not written here. Keep the order and headings as they are; delete the italic
|
|
5
|
+
prompts as you fill each section in.
|
|
6
|
+
-->
|
|
7
|
+
|
|
8
|
+
# {{title}}
|
|
9
|
+
|
|
10
|
+
## Intent
|
|
11
|
+
|
|
12
|
+
_Why this chapter exists — the work it does that no other chapter does. A paragraph is plenty here._
|
|
13
|
+
|
|
14
|
+
## Open Questions
|
|
15
|
+
|
|
16
|
+
_What you don't yet know about this chapter. Honest holes beat invented certainty._
|
|
17
|
+
|
|
18
|
+
## What Happens
|
|
19
|
+
|
|
20
|
+
_The beats, in order, as far as you have them. Label each **B1:**, **B2:**, … Rough is fine; a sketch is allowed to be thin, but not vague._
|
|
21
|
+
|
|
22
|
+
- **B1:**
|
|
23
|
+
|
|
24
|
+
## Out of Scope
|
|
25
|
+
|
|
26
|
+
_What this chapter deliberately does not cover, and which chapter covers it instead. Even in a sketch, this is the section worth filling — it's what keeps neighboring chapters from eating each other._
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
<!--
|
|
2
|
+
The Market frame — where this book sits and how it reaches readers. Loose, point-in-time prose.
|
|
3
|
+
Suggestive, not prescriptive. A Frame's frontmatter is generated from the framework's Schema (in
|
|
4
|
+
Framework.md), so it is not written here. Delete the italic prompts as you fill in.
|
|
5
|
+
-->
|
|
6
|
+
|
|
7
|
+
# Market
|
|
8
|
+
|
|
9
|
+
## The Shelf
|
|
10
|
+
|
|
11
|
+
_Where it sits in a shop or a store's category tree, and who it sits beside._
|
|
12
|
+
|
|
13
|
+
## Comparables
|
|
14
|
+
|
|
15
|
+
_Three or four books a reader would already own. For each: what it does well, and what this one does that it doesn't._
|
|
16
|
+
|
|
17
|
+
## How It Reaches Readers
|
|
18
|
+
|
|
19
|
+
_Publisher, self-published, serialized, a course, a newsletter first. The path from written to read._
|
|
20
|
+
|
|
21
|
+
## What Success Looks Like
|
|
22
|
+
|
|
23
|
+
_Copies, readers, citations, invitations, a changed mind. Say which, and roughly how much — a book with no stated bar can't be finished._
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
<!--
|
|
2
|
+
The Premise frame — what the book says and why it has to exist. Loose, point-in-time prose: record
|
|
3
|
+
what is true now and revise when it changes. Suggestive, not prescriptive. A Frame's frontmatter is
|
|
4
|
+
generated from the framework's Schema (in Framework.md), so it is not written here. Delete the italic
|
|
5
|
+
prompts as you fill in.
|
|
6
|
+
-->
|
|
7
|
+
|
|
8
|
+
# Premise
|
|
9
|
+
|
|
10
|
+
## The Argument
|
|
11
|
+
|
|
12
|
+
_In a few sentences: what this book claims, or what story it tells. If you can't say it without a list, it isn't a premise yet._
|
|
13
|
+
|
|
14
|
+
## Why It Has To Exist
|
|
15
|
+
|
|
16
|
+
_What is wrong, missing, or misunderstood in the world without this book. The problem the reader has._
|
|
17
|
+
|
|
18
|
+
## The Shape of It
|
|
19
|
+
|
|
20
|
+
_How the whole thing is built — parts, arc, the movement from the first page to the last. Not a table of contents; the logic behind one._
|
|
21
|
+
|
|
22
|
+
## What It Is Not
|
|
23
|
+
|
|
24
|
+
_The adjacent book you are deliberately not writing. This is where a book's scope is held._
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
<!--
|
|
2
|
+
The Reader frame — who this book is for, and what changes for them. Loose, point-in-time prose.
|
|
3
|
+
Suggestive, not prescriptive. A Frame's frontmatter is generated from the framework's Schema (in
|
|
4
|
+
Framework.md), so it is not written here. Delete the italic prompts as you fill in.
|
|
5
|
+
-->
|
|
6
|
+
|
|
7
|
+
# Reader
|
|
8
|
+
|
|
9
|
+
## Who They Are
|
|
10
|
+
|
|
11
|
+
_The specific person you are writing to. One or a few kinds; name them. "Everyone" is not a reader._
|
|
12
|
+
|
|
13
|
+
## What They Bring
|
|
14
|
+
|
|
15
|
+
_What they already know, already believe, and already tried. What vocabulary you can use without explaining it, and what you cannot._
|
|
16
|
+
|
|
17
|
+
## What Changes For Them
|
|
18
|
+
|
|
19
|
+
_What they can do, believe, or feel at the end that they couldn't at the start. The book's promise, stated from their side._
|
|
20
|
+
|
|
21
|
+
## Who It Is Not For
|
|
22
|
+
|
|
23
|
+
_The reader you will lose, and are choosing to lose. Naming them is what lets you write plainly to the ones you keep._
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
<!--
|
|
2
|
+
The Voice frame — the rules the prose keeps, so any chapter sounds like the same book. Loose,
|
|
3
|
+
point-in-time prose. Suggestive, not prescriptive. A Frame's frontmatter is generated from the
|
|
4
|
+
framework's Schema (in Framework.md), so it is not written here. Delete the italic prompts as you
|
|
5
|
+
fill in.
|
|
6
|
+
-->
|
|
7
|
+
|
|
8
|
+
# Voice
|
|
9
|
+
|
|
10
|
+
## Person & Tense
|
|
11
|
+
|
|
12
|
+
_First, second, or third; past or present. Whether it varies, and where._
|
|
13
|
+
|
|
14
|
+
## Register
|
|
15
|
+
|
|
16
|
+
_How it sounds read aloud — plain, formal, wry, urgent. Two or three writers or books it stands near, and how it differs from each._
|
|
17
|
+
|
|
18
|
+
## Rules It Keeps
|
|
19
|
+
|
|
20
|
+
_The specific, checkable habits: sentence length, jargon policy, how sources are cited, whether it addresses the reader directly, what it never does. These are what an editor checks a draft against._
|
|
21
|
+
|
|
22
|
+
## Rules It Breaks, On Purpose
|
|
23
|
+
|
|
24
|
+
_Where the book deliberately departs from its own register, and what that departure is for._
|
|
@@ -0,0 +1,88 @@
|
|
|
1
|
+
---
|
|
2
|
+
# The Eidos version this framework targets; migrate reads and bumps it.
|
|
3
|
+
eidos_version: 4.5.0
|
|
4
|
+
# How files, folders, and links are named: kebab-case | TitleCase | Title Case. Absent = kebab-case.
|
|
5
|
+
naming: kebab-case
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Framework
|
|
9
|
+
|
|
10
|
+
The framework's index and config, in one place: the version and naming convention above, and below the
|
|
11
|
+
Top-Level documents, the Collections (with their flavors and grouping), and the property Schema. The
|
|
12
|
+
visible `README.md` at the root is the friendly door to it; keep it current with the
|
|
13
|
+
`configure` skill.
|
|
14
|
+
|
|
15
|
+
## Top-Level
|
|
16
|
+
|
|
17
|
+
<!-- configure: top-level index (regenerated) -->
|
|
18
|
+
- [README](../README.md) — the root's front door: what this programme asks, and pointers in.
|
|
19
|
+
<!-- One bullet per top-level document. README is the door and comes first; add your own below (a
|
|
20
|
+
Protocol, a Data Statement, the generated Blueprint Map canvas), each a link and a one-line
|
|
21
|
+
description. The framing docs live in the Frames collection, not here. configure refreshes
|
|
22
|
+
this list. -->
|
|
23
|
+
|
|
24
|
+
## Collections
|
|
25
|
+
|
|
26
|
+
A collection is a top-level folder of repeated blueprints that share a body shape. `Frames` holds the
|
|
27
|
+
framing docs — the most primary thing the folder says about itself — and `Investigations` the
|
|
28
|
+
programme's units. Add more with `configure`. Each lists its flavors (the default marked), how
|
|
29
|
+
it draws on the canvas, and its grouping, and points at its generated `index.md` leaf.
|
|
30
|
+
|
|
31
|
+
### Frames
|
|
32
|
+
|
|
33
|
+
The framing docs that set what every investigation is judged against — what is being asked, what is
|
|
34
|
+
already known, what would count as knowing, and who is affected. This framework's framing collection;
|
|
35
|
+
each frame follows the flavor of its kind, and one left unwritten is a gap to surface, not a failure.
|
|
36
|
+
|
|
37
|
+
- **Leaf:** [Frames/index.md](../Frames/index.md)
|
|
38
|
+
- **Flavors:**
|
|
39
|
+
- [question](shapes/frame.question.md) — what the programme asks, and why it matters (default).
|
|
40
|
+
- [prior work](shapes/frame.prior-work.md) — what is already known, and where this sits.
|
|
41
|
+
- [method](shapes/frame.method.md) — how anyone would know, and the standard of evidence.
|
|
42
|
+
- [ethics](shapes/frame.ethics.md) — who is affected, what they consented to, what could go wrong.
|
|
43
|
+
- **Canvas:** file
|
|
44
|
+
|
|
45
|
+
### Investigations
|
|
46
|
+
|
|
47
|
+
The programme's units, one per line of inquiry, grouped by strand.
|
|
48
|
+
|
|
49
|
+
- **Leaf:** [Investigations/index.md](../Investigations/index.md)
|
|
50
|
+
- **Flavors:**
|
|
51
|
+
- [full](shapes/investigation.full.md) — the complete investigation shape (default).
|
|
52
|
+
- [note](shapes/investigation.note.md) — Intent, Open Questions, Claims, Out of Scope; grow into full.
|
|
53
|
+
- **Canvas:** card from `## Intent`
|
|
54
|
+
- **Strands:** _(add one bullet per strand — a name and a short description — as strands accrue)_
|
|
55
|
+
|
|
56
|
+
## Schema
|
|
57
|
+
|
|
58
|
+
The property contract — what a blueprint's frontmatter may carry, across every collection. Two parts: the
|
|
59
|
+
**core** properties Eidos's own machinery uses, and the **custom** ones you (or the seed) add. Every
|
|
60
|
+
custom property declares which collections it **applies to** — `all`, or a list — so a property never
|
|
61
|
+
lands where it makes no sense (`strand` is Investigations-only). A property's type comes from the
|
|
62
|
+
Obsidian set (Text, List, Number, Checkbox, Date, Date & time), so frontmatter renders natively in an
|
|
63
|
+
Obsidian vault. The `configure` skill edits this section.
|
|
64
|
+
|
|
65
|
+
### Eidos Core
|
|
66
|
+
|
|
67
|
+
_Present on every blueprint. Managed by the standard (Eidos 4.5.0); `migrate` rewrites this block on a version change — don't hand-edit it. (`flavor` absent = the collection's default; `connects_to` absent = no canvas edges; a missing `summary` is flagged by the index.)_
|
|
68
|
+
|
|
69
|
+
| Name | Type | Meaning |
|
|
70
|
+
| ----------- | ---- | ---------------------------------------------------------------------------------------------- |
|
|
71
|
+
| id | Text | Stable, unique, kebab-case identity. Assigned once, never renamed. References point at it. |
|
|
72
|
+
| title | Text | Human-readable name. |
|
|
73
|
+
| summary | Text | One plain line — what this blueprint is, in a sentence, distilled from Intent. Source for the collection index.md listing; absent, the index flags it. |
|
|
74
|
+
| flavor | Text | Which body flavor this blueprint follows, from its collection's declared flavors. Absent = the collection's default flavor. |
|
|
75
|
+
| connects_to | List | Blueprints this one connects to on the canvas, each a markdown link; drawn as a directed edge (this → target). The intentional map, distinct from depends_on. |
|
|
76
|
+
|
|
77
|
+
### Custom Properties
|
|
78
|
+
|
|
79
|
+
_Yours to shape with the `configure` skill. The seed ships a few useful defaults below — keep, scope, or drop any of them; Eidos doesn't depend on them. Absence where a property applies is a soft gap the validator notes, never refuses._
|
|
80
|
+
|
|
81
|
+
| Name | Type | Applies To | Meaning |
|
|
82
|
+
| ------------- | ---- | -------------- | -------------------------------------------------------------------------------------- |
|
|
83
|
+
| status | Text | all | Lifecycle value: Draft / Open / Running / Answered / Inconclusive / Abandoned. An off-list value warns. |
|
|
84
|
+
| date_created | Date | all | YYYY-MM-DD. The day the blueprint was first written. Set once. |
|
|
85
|
+
| date_modified | Date | all | YYYY-MM-DD. The day the blueprint was last changed. |
|
|
86
|
+
| tags | List | all | Free tags. |
|
|
87
|
+
| strand | Text | Investigations | The grouping — the line of inquiry this belongs to, matching the blueprint's sub-folder in the naming convention. An unknown value warns, never fails. |
|
|
88
|
+
| depends_on | List | Investigations | Investigations, data, or approvals this one needs first, each a markdown link. A real dependency, not a canvas edge. |
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
# {{Product}}
|
|
2
|
+
|
|
3
|
+
> **Start here.** This is the root for **{{Product}}** — the source of truth for what this
|
|
4
|
+
> programme asks and what would count as an answer, true whether or not a single study has run.
|
|
5
|
+
|
|
6
|
+
{{One line: the question this programme exists to answer.}}
|
|
7
|
+
|
|
8
|
+
## Where things are
|
|
9
|
+
|
|
10
|
+
- **[Frames](Frames/index.md)** — the question, the prior work, the method, the ethics.
|
|
11
|
+
- **[Investigations](Investigations/index.md)** — one file per line of inquiry, grouped by strand.
|
|
12
|
+
|
|
13
|
+
The full index — every collection, its flavors, and the property Schema — is in
|
|
14
|
+
[`_eidos/Framework.md`](_eidos/Framework.md).
|
|
15
|
+
|
|
16
|
+
## How to use it
|
|
17
|
+
|
|
18
|
+
An investigation here describes what is being asked and what would settle it. It is not a lab
|
|
19
|
+
notebook, a protocol, or a task list. Write the question and the falsifier before the work, and keep
|
|
20
|
+
them true after — an investigation that comes back `Inconclusive` or `Abandoned` stays here, because
|
|
21
|
+
the question and the attempt are both part of what the programme knows.
|
|
22
|
+
|
|
23
|
+
_A root. Its framework lives in [`_eidos/`](_eidos/); see [`_eidos/Framework.md`](_eidos/Framework.md) for the full index._
|
|
@@ -0,0 +1,18 @@
|
|
|
1
|
+
# Me
|
|
2
|
+
|
|
3
|
+
Who is in the seat. This file is **personal and per-actor** — it is gitignored and never checked in, so
|
|
4
|
+
each person who works on this folder keeps their own. The agent reads it before acting, to know who
|
|
5
|
+
you are and how to help.
|
|
6
|
+
|
|
7
|
+
Set who you are below — `install` asks, or just edit this file. Leaving it blank is fine: the agent
|
|
8
|
+
defaults to full, framework-owner-style facilitation and offers to record who you are.
|
|
9
|
+
|
|
10
|
+
## You are:
|
|
11
|
+
|
|
12
|
+
<!-- Name your role and how you want to be helped. The base roles Eidos recognizes:
|
|
13
|
+
- Framework Owner — holds intent, scope, decisions; full authoring, press on scope.
|
|
14
|
+
- Developer — consumes specs to build; surface what's specced, clarify, flag gaps, help Testing/ACs.
|
|
15
|
+
- Stakeholder — reviews direction; explain, summarize, surface risk.
|
|
16
|
+
- Designer — shapes UX and audience; Audience, Behaviors, external interface.
|
|
17
|
+
- Project Manager — tracks scope and progress; in/out of scope, status, dependencies, effort.
|
|
18
|
+
Or write your own. -->
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
# Roles
|
|
2
|
+
|
|
3
|
+
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").
|
|
4
|
+
|
|
5
|
+
These are the research seed's 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 programme). 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.
|
|
6
|
+
|
|
7
|
+
- [Framework Owner](framework-owner.md) — holds intent, scope, and decisions.
|
|
8
|
+
- [Researcher](researcher.md) — does the work; needs the design in full.
|
|
9
|
+
- [Reviewer](reviewer.md) — reads to find the hole; adversarial by design.
|
|
10
|
+
- [Sponsor](sponsor.md) — funds or answers for it; needs what it can and cannot conclude.
|
|
11
|
+
|
|
12
|
+
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.
|
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
# Framework Owner
|
|
2
|
+
|
|
3
|
+
## Who they are
|
|
4
|
+
|
|
5
|
+
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.
|
|
6
|
+
|
|
7
|
+
## How to respond
|
|
8
|
+
|
|
9
|
+
- **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.
|
|
10
|
+
- **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**.
|
|
11
|
+
- **Surface / hide:** surface intent, scope, audience, criteria, and the consequences of a choice; fold mechanism into a link they can follow.
|
|
12
|
+
- **Focus:** Intent, Out of Scope, the Question and Method frames, and whether each investigation still says what they mean.
|
|
13
|
+
|
|
14
|
+
## Calibration
|
|
15
|
+
|
|
16
|
+
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.
|
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
# Researcher
|
|
2
|
+
|
|
3
|
+
## Who they are
|
|
4
|
+
|
|
5
|
+
Does the work. Reads an investigation to answer "what exactly am I testing, how, and what would count as a result?"
|
|
6
|
+
|
|
7
|
+
## How to respond
|
|
8
|
+
|
|
9
|
+
- **Vocabulary & depth:** full methodological depth — design, sampling, measures, analysis, confounds, power. Be precise, and say when something is underspecified rather than smoothing it over.
|
|
10
|
+
- **Decisions:** clarify and flag, don't decide. The question, the standard of evidence, and what gets published belong to the Framework Owner; surface the gap rather than filling it.
|
|
11
|
+
- **Surface / hide:** surface Method, Claims & Evidence, What Would Change Our Mind, Dependencies, and Open Questions. Fold away positioning and funding.
|
|
12
|
+
- **Focus:** whether the design can actually answer the Intent; whether a claim's evidence supports it as stated; what would block the work starting.
|
|
13
|
+
|
|
14
|
+
## Calibration
|
|
15
|
+
|
|
16
|
+
**Experience with the scope** sets how much of the Frames to restate; **technical capacity** is high by default for this role, but honored if calibrated down.
|
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
# Reviewer
|
|
2
|
+
|
|
3
|
+
## Who they are
|
|
4
|
+
|
|
5
|
+
Reads to find the hole. A peer reviewer, internal critic, or replication-minded colleague. Their job is to be unconvinced until the evidence earns it.
|
|
6
|
+
|
|
7
|
+
## How to respond
|
|
8
|
+
|
|
9
|
+
- **Vocabulary & depth:** full depth, and adversarial by default. Do not soften a weak claim; name it.
|
|
10
|
+
- **Decisions:** none are theirs to make, and that is the point — they judge, they don't revise. Never resolve a flagged weakness on the owner's behalf.
|
|
11
|
+
- **Surface / hide:** surface Claims & Evidence with its strength, What Would Change Our Mind, Out of Scope, Threats to Validity, and every Assumption. Lead with what is *not* supported.
|
|
12
|
+
- **Focus:** claims that outrun their evidence; a falsifier that was written after the result; an Out of Scope that doesn't cover how the finding will actually be read.
|
|
13
|
+
|
|
14
|
+
## Calibration
|
|
15
|
+
|
|
16
|
+
**Experience with the scope** sets how much prior work to restate. Never calibrate the skepticism down — a reviewer who is easy to satisfy isn't doing the role.
|
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
# Sponsor
|
|
2
|
+
|
|
3
|
+
## Who they are
|
|
4
|
+
|
|
5
|
+
Funds it, approves it, or answers for it. Reads to know what the programme will and will not be able to tell them, and what it costs to find out.
|
|
6
|
+
|
|
7
|
+
## How to respond
|
|
8
|
+
|
|
9
|
+
- **Vocabulary & depth:** plain language. Explain a method only as far as it changes what the result can support. No instrument detail, no analysis mechanics.
|
|
10
|
+
- **Decisions:** bring them the decisions that are actually theirs — scope, resourcing, what gets published, what risk is acceptable. Don't bring them design choices.
|
|
11
|
+
- **Surface / hide:** surface the Question, What Would Count As An Answer, Out of Scope, status across strands, and anything in Ethics that carries exposure. Fold away Method internals and Open Questions that the team will close on its own.
|
|
12
|
+
- **Focus:** what this can and cannot conclude; where the programme stands; what would change the answer or the cost.
|
|
13
|
+
|
|
14
|
+
## Calibration
|
|
15
|
+
|
|
16
|
+
**Technical capacity** is assumed low by default and raised only if calibrated up; **experience with the scope** sets how much of the question to re-establish each time.
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
<!--
|
|
2
|
+
The Ethics frame — who is affected and what you owe them. Loose, point-in-time prose. Suggestive, not
|
|
3
|
+
prescriptive. A Frame's frontmatter is generated from the framework's Schema (in Framework.md), so it
|
|
4
|
+
is not written here. Delete the italic prompts as you fill in.
|
|
5
|
+
-->
|
|
6
|
+
|
|
7
|
+
# Ethics
|
|
8
|
+
|
|
9
|
+
## Who Is Affected
|
|
10
|
+
|
|
11
|
+
_Participants, their communities, and the people downstream of the finding — including those who never consented to anything but will live with the result._
|
|
12
|
+
|
|
13
|
+
## Consent & Governance
|
|
14
|
+
|
|
15
|
+
_What participants were told, what they agreed to, and what would fall outside it. The approving body, the approval, and its limits._
|
|
16
|
+
|
|
17
|
+
## Data Handling
|
|
18
|
+
|
|
19
|
+
_What is collected, how it is stored, who can see it, how long it lives, and what makes it identifiable again. Say what is sensitive, plainly._
|
|
20
|
+
|
|
21
|
+
## What Could Go Wrong
|
|
22
|
+
|
|
23
|
+
_Foreseeable harm from doing the work, and foreseeable harm from the finding being misread or misused. What you will do about each. A programme with an empty version of this section has not looked._
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
<!--
|
|
2
|
+
The Method frame — how anyone would know, and the standard of evidence this programme holds. Loose,
|
|
3
|
+
point-in-time prose. Suggestive, not prescriptive. A Frame's frontmatter is generated from the
|
|
4
|
+
framework's Schema (in Framework.md), so it is not written here. Delete the italic prompts as you
|
|
5
|
+
fill in.
|
|
6
|
+
-->
|
|
7
|
+
|
|
8
|
+
# Method
|
|
9
|
+
|
|
10
|
+
## Approach
|
|
11
|
+
|
|
12
|
+
_The kind of evidence this programme produces — experimental, observational, qualitative, computational, mixed — and why that kind can answer the question._
|
|
13
|
+
|
|
14
|
+
## Standard of Evidence
|
|
15
|
+
|
|
16
|
+
_What you will treat as sufficient, decided in advance: effect sizes, saturation, replication, pre-registration, review. The bar, written before the results._
|
|
17
|
+
|
|
18
|
+
## Threats to Validity
|
|
19
|
+
|
|
20
|
+
_The ways this whole approach could mislead — selection, measurement, confounding, researcher degrees of freedom — and what you do about each._
|
|
21
|
+
|
|
22
|
+
## What You Will Share
|
|
23
|
+
|
|
24
|
+
_Data, code, materials, negative results. Where they go, and when. A programme that only publishes what worked is a programme that cannot be checked._
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
<!--
|
|
2
|
+
The Prior Work frame — what is already known, and where this sits against it. Loose, point-in-time
|
|
3
|
+
prose. Suggestive, not prescriptive. A Frame's frontmatter is generated from the framework's Schema
|
|
4
|
+
(in Framework.md), so it is not written here. Delete the italic prompts as you fill in.
|
|
5
|
+
-->
|
|
6
|
+
|
|
7
|
+
# Prior Work
|
|
8
|
+
|
|
9
|
+
## What Is Settled
|
|
10
|
+
|
|
11
|
+
_The findings you are building on rather than retesting. Cite them; say how confident the field actually is, not how confident the abstracts sound._
|
|
12
|
+
|
|
13
|
+
## What Is Contested
|
|
14
|
+
|
|
15
|
+
_Where the literature disagrees, and what the disagreement turns on — a measure, a population, a definition._
|
|
16
|
+
|
|
17
|
+
## The Gap
|
|
18
|
+
|
|
19
|
+
_What nobody has asked, or has asked badly. Be specific about which part of the question is genuinely open; "more research is needed" is not a gap._
|
|
20
|
+
|
|
21
|
+
## Why Now
|
|
22
|
+
|
|
23
|
+
_What changed — a new instrument, a new dataset, a policy shift — that makes this answerable when it wasn't._
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
<!--
|
|
2
|
+
The Question frame — what this programme asks and why it matters. Loose, point-in-time prose: record
|
|
3
|
+
what is true now and revise when it changes. Suggestive, not prescriptive. A Frame's frontmatter is
|
|
4
|
+
generated from the framework's Schema (in Framework.md), so it is not written here. Delete the italic
|
|
5
|
+
prompts as you fill in.
|
|
6
|
+
-->
|
|
7
|
+
|
|
8
|
+
# Question
|
|
9
|
+
|
|
10
|
+
## The Question
|
|
11
|
+
|
|
12
|
+
_In one sentence, ending in a question mark. If it takes a paragraph, you have a programme, not a question — say the question, then list the strands beneath it._
|
|
13
|
+
|
|
14
|
+
## Why It Matters
|
|
15
|
+
|
|
16
|
+
_What decision, practice, or belief changes depending on the answer. Who is currently acting on a guess._
|
|
17
|
+
|
|
18
|
+
## What Would Count As An Answer
|
|
19
|
+
|
|
20
|
+
_The standard of evidence you will hold yourself to, before you know what the data says. Stating it here is what stops it from drifting to meet the result._
|
|
21
|
+
|
|
22
|
+
## What This Programme Is Not Asking
|
|
23
|
+
|
|
24
|
+
_The adjacent question you are deliberately leaving alone, and why. This is where a research programme's scope is held._
|
|
@@ -0,0 +1,49 @@
|
|
|
1
|
+
<!--
|
|
2
|
+
The Investigation shape — the body of one line of inquiry, and the documentation of each section. An
|
|
3
|
+
investigation's frontmatter is generated from the framework's Schema (in Framework.md), so it is not
|
|
4
|
+
written here. Keep the sections that apply and delete the rest, but leave the order and headings as
|
|
5
|
+
they are — a reader should know what to expect from any investigation in this folder. The italic
|
|
6
|
+
prompts are guidance; delete them as you fill each section in.
|
|
7
|
+
-->
|
|
8
|
+
|
|
9
|
+
# {{title}}
|
|
10
|
+
|
|
11
|
+
## Intent
|
|
12
|
+
|
|
13
|
+
_The question this investigation answers, and why it is worth answering. One or two paragraphs, ending in an actual question mark. This is the stable part: if the question changes substantially, you have a different investigation, not an edit to this one._
|
|
14
|
+
|
|
15
|
+
### Assumptions
|
|
16
|
+
|
|
17
|
+
_What you are taking as given and have not tested — about the population, the instrument, the prior literature, the world. Nested under Intent because they frame it. Surface them so an untested assumption doesn't get read later as a finding._
|
|
18
|
+
|
|
19
|
+
## Open Questions
|
|
20
|
+
|
|
21
|
+
_What you don't yet know about how to run this — an undecided measure, an unresolved confound, a missing approval. Kept high so uncertainty is seen rather than buried. When one is settled it graduates into an Assumption, a Claim, or a Decision._
|
|
22
|
+
|
|
23
|
+
## Claims & Evidence
|
|
24
|
+
|
|
25
|
+
_What this investigation asserts, and what supports each assertion. Label each claim **C1:**, **C2:**, … (bold, unique within this investigation). Give each its evidence and its strength; a claim with no evidence yet is still a claim — mark it so. Push data, tables, and instrument detail into a sub-section a claim points to, not onto the line. Evolves freely._
|
|
26
|
+
|
|
27
|
+
- **C1:** <!-- the assertion --> <!-- evidence: … -->
|
|
28
|
+
|
|
29
|
+
## What Would Change Our Mind
|
|
30
|
+
|
|
31
|
+
_The falsifier: the specific result that would make you abandon or revise the claims above. Concrete enough that someone could go and look. An investigation with no falsifier is an opinion with citations, and this is the section this framework leans on hardest._
|
|
32
|
+
|
|
33
|
+
## Out of Scope
|
|
34
|
+
|
|
35
|
+
_What this investigation **cannot** tell you, and who will be tempted to think it can. Populations not sampled, mechanisms not tested, the causal claim the design does not support. The second-hardest-working section here: it is what keeps a finding from being over-read downstream._
|
|
36
|
+
|
|
37
|
+
## Dependencies
|
|
38
|
+
|
|
39
|
+
_What this needs before it can run: data, access, approvals, instruments, or another investigation's result. The `depends_on` property at the top is the investigation-only subset of this, as links. Reference other investigations as markdown links — never bare names._
|
|
40
|
+
|
|
41
|
+
## Method
|
|
42
|
+
|
|
43
|
+
_How the question is actually approached: design, sample, measures, analysis. Enough that a reader can judge whether the Claims follow. Detail belongs here rather than on a claim line; a full protocol can live in its own top-level doc this section points at._
|
|
44
|
+
|
|
45
|
+
## Notes & Decisions
|
|
46
|
+
|
|
47
|
+
_Two things under one header. **Notes**: threats to validity, things to chase, what surprised you. **Decisions**: an append-only log, one line each, with an optional but recommended date._
|
|
48
|
+
|
|
49
|
+
<!-- 2026-08-26: Dropped the second cohort, consent window closed. (Brenton) -->
|
|
@@ -0,0 +1,26 @@
|
|
|
1
|
+
<!--
|
|
2
|
+
The Investigation shape, note flavor — the smallest useful record of a line of inquiry, meant to grow
|
|
3
|
+
into `investigation.full` once it earns it. Frontmatter is generated from the framework's Schema (in
|
|
4
|
+
Framework.md), so it is not written here. Keep the order and headings as they are; delete the italic
|
|
5
|
+
prompts as you fill each section in.
|
|
6
|
+
-->
|
|
7
|
+
|
|
8
|
+
# {{title}}
|
|
9
|
+
|
|
10
|
+
## Intent
|
|
11
|
+
|
|
12
|
+
_The question, and why it is worth answering. End it in a question mark. A paragraph is plenty here._
|
|
13
|
+
|
|
14
|
+
## Open Questions
|
|
15
|
+
|
|
16
|
+
_What you don't yet know about how to approach it. Honest holes beat invented certainty._
|
|
17
|
+
|
|
18
|
+
## Claims
|
|
19
|
+
|
|
20
|
+
_What you currently believe, labeled **C1:**, **C2:**, … with a word on what supports each — including "nothing yet." A note is allowed to be thin, but never vague about its own confidence._
|
|
21
|
+
|
|
22
|
+
- **C1:**
|
|
23
|
+
|
|
24
|
+
## Out of Scope
|
|
25
|
+
|
|
26
|
+
_What this could not tell you even if it went perfectly. Even in a note, this is the section worth filling — it is what stops a preliminary result from being quoted as a conclusion._
|
|
@@ -0,0 +1,88 @@
|
|
|
1
|
+
---
|
|
2
|
+
# The Eidos version this framework targets; migrate reads and bumps it.
|
|
3
|
+
eidos_version: 4.5.0
|
|
4
|
+
# How files, folders, and links are named: kebab-case | TitleCase | Title Case. Absent = kebab-case.
|
|
5
|
+
naming: kebab-case
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Framework
|
|
9
|
+
|
|
10
|
+
The framework's index and config, in one place: the version and naming convention above, and below the
|
|
11
|
+
Top-Level documents, the Collections (with their flavors and grouping), and the property Schema. The
|
|
12
|
+
visible `README.md` at the root is the friendly door to it; keep it current with the
|
|
13
|
+
`configure` skill.
|
|
14
|
+
|
|
15
|
+
## Top-Level
|
|
16
|
+
|
|
17
|
+
<!-- configure: top-level index (regenerated) -->
|
|
18
|
+
- [README](../README.md) — the root's front door: what this is, and pointers in.
|
|
19
|
+
<!-- One bullet per top-level document. README is the door and comes first; add your own below (a
|
|
20
|
+
Roadmap, a Vision, the generated Blueprint Map canvas), each a link and a one-line description.
|
|
21
|
+
The framing docs live in the Frames collection, not here. configure refreshes this list. -->
|
|
22
|
+
|
|
23
|
+
## Collections
|
|
24
|
+
|
|
25
|
+
A collection is a top-level folder of repeated blueprints that share a body shape. `Frames` holds the
|
|
26
|
+
framing docs — the most primary thing the folder says about itself — and `Specs` the product's
|
|
27
|
+
units. Add more with `configure`. Each lists its flavors (the default marked) and its grouping,
|
|
28
|
+
and points at its generated `index.md` leaf.
|
|
29
|
+
|
|
30
|
+
### Frames
|
|
31
|
+
|
|
32
|
+
The framing docs that set what every other blueprint is judged against — the product's architecture,
|
|
33
|
+
audience, criteria, and market. This framework's framing collection; each frame follows the flavor of
|
|
34
|
+
its kind, and one left unwritten is a gap to surface, not a failure.
|
|
35
|
+
|
|
36
|
+
- **Leaf:** [Frames/index.md](../Frames/index.md)
|
|
37
|
+
- **Flavors:**
|
|
38
|
+
- [architecture](shapes/frame.architecture.md) — the product as a built system (default).
|
|
39
|
+
- [audience](shapes/frame.audience.md) — who it serves, and how each kind differs.
|
|
40
|
+
- [criteria](shapes/frame.criteria.md) — budget, scope objectives, timeline.
|
|
41
|
+
- [market](shapes/frame.market.md) — landscape, positioning, and how it earns.
|
|
42
|
+
- **Canvas:** file
|
|
43
|
+
|
|
44
|
+
### Specs
|
|
45
|
+
|
|
46
|
+
The product's units, one per blueprint, grouped by domain.
|
|
47
|
+
|
|
48
|
+
- **Leaf:** [Specs/index.md](../Specs/index.md)
|
|
49
|
+
- **Flavors:**
|
|
50
|
+
- [full](shapes/spec.full.md) — the complete spec shape (default).
|
|
51
|
+
- [micro](shapes/spec.micro.md) — Intent, Open Questions, ACs, Out of Scope; grow into full.
|
|
52
|
+
- **Canvas:** card from `## Intent`
|
|
53
|
+
- **Domains:** _(add one bullet per domain — a name and a short description — as domains accrue)_
|
|
54
|
+
|
|
55
|
+
## Schema
|
|
56
|
+
|
|
57
|
+
The property contract — what a blueprint's frontmatter may carry, across every collection. Two parts: the
|
|
58
|
+
**core** properties Eidos's own machinery uses, and the **custom** ones you (or the seed) add. Every
|
|
59
|
+
custom property declares which collections it **applies to** — `all`, or a list — so a property never
|
|
60
|
+
lands where it makes no sense (`domain` is Specs-only). A property's type comes from the Obsidian set
|
|
61
|
+
(Text, List, Number, Checkbox, Date, Date & time), so frontmatter renders natively in an Obsidian
|
|
62
|
+
vault. The `configure` skill edits this section.
|
|
63
|
+
|
|
64
|
+
### Eidos Core
|
|
65
|
+
|
|
66
|
+
_Present on every blueprint. Managed by the standard (Eidos 4.5.0); `migrate` rewrites this block on a version change — don't hand-edit it. (`flavor` absent = the collection's default; `connects_to` absent = no canvas edges; a missing `summary` is flagged by the index.)_
|
|
67
|
+
|
|
68
|
+
| Name | Type | Meaning |
|
|
69
|
+
| ----------- | ---- | ---------------------------------------------------------------------------------------------- |
|
|
70
|
+
| id | Text | Stable, unique, kebab-case identity. Assigned once, never renamed. References point at it. |
|
|
71
|
+
| title | Text | Human-readable name. |
|
|
72
|
+
| summary | Text | One plain line — what this blueprint is, in a sentence, distilled from Intent. Source for the collection index.md listing; absent, the index flags it. |
|
|
73
|
+
| flavor | Text | Which body flavor this blueprint follows, from its collection's declared flavors. Absent = the collection's default flavor. |
|
|
74
|
+
| connects_to | List | Blueprints this one connects to on the canvas, each a markdown link; drawn as a directed edge (this → target). The intentional map, distinct from depends_on. |
|
|
75
|
+
|
|
76
|
+
### Custom Properties
|
|
77
|
+
|
|
78
|
+
_Yours to shape with the `configure` skill. The seed ships a few useful defaults below — keep, scope, or drop any of them; Eidos doesn't depend on them. Absence where a property applies is a soft gap the validator notes, never refuses._
|
|
79
|
+
|
|
80
|
+
| Name | Type | Applies To | Meaning |
|
|
81
|
+
| ------------- | ---- | ---------- | ------------------------------------------------------------------------------------------ |
|
|
82
|
+
| status | Text | all | Lifecycle value: Draft / Intake / In Progress / Done / Archived / Deprecated. An off-list value warns. |
|
|
83
|
+
| date_created | Date | all | YYYY-MM-DD. The day the blueprint was first written. Set once. |
|
|
84
|
+
| date_modified | Date | all | YYYY-MM-DD. The day the blueprint was last changed. |
|
|
85
|
+
| tags | List | all | Free tags. |
|
|
86
|
+
| domain | Text | Specs | The grouping, matching the blueprint's sub-folder under its collection in the naming convention. An unknown value warns, never fails. |
|
|
87
|
+
| depends_on | List | Specs | Blueprints this one needs, each a markdown link. An implementation dependency, not a canvas edge. |
|
|
88
|
+
| type | Text | Specs | Open, soft category label — drives views and filtering, never structure. e.g. feature, capability, integration. |
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
# {{Product}}
|
|
2
|
+
|
|
3
|
+
> **Start here.** This is the root for **{{Product}}** — the source of truth for what the
|
|
4
|
+
> product is, true whether or not it's been built.
|
|
5
|
+
|
|
6
|
+
This README is the front door. The full index and config live in
|
|
7
|
+
[`_eidos/Framework.md`](_eidos/Framework.md); this file orients you and points the way.
|
|
8
|
+
|
|
9
|
+
## What this is
|
|
10
|
+
|
|
11
|
+
_One or two sentences: what {{Product}} is, and for whom._
|
|
12
|
+
|
|
13
|
+
## Top-level documents
|
|
14
|
+
|
|
15
|
+
_Your own one-of-a-kind docs (a Roadmap, a Vision, the generated Blueprint Map). Add them here as you write them._
|
|
16
|
+
|
|
17
|
+
## Collections
|
|
18
|
+
|
|
19
|
+
- **[Frames](Frames/index.md)** — the framing docs: Architecture, Audience, Criteria, Market.
|
|
20
|
+
- **[Specs](Specs/index.md)** — the product's units, grouped by domain.
|
|
21
|
+
|
|
22
|
+
---
|
|
23
|
+
|
|
24
|
+
_A root. Its framework lives in [`_eidos/`](_eidos/); see [`_eidos/Framework.md`](_eidos/Framework.md) for the full index. `configure` and `index` keep these current._
|