naive-framework 0.0.0-stage → 0.1.0

package/purpose/skills/ambition-tier/SKILL.md

@@ -0,0 +1,205 @@
+---
+type: knowledge
+tags: [everything-ecosystem, skills, ambition-tier]
+ai-model: claude
+created: 2026-05-15
+source: hybrid
+name: ambition-tier
+description: >
+  Run Phase 0Δ — the Project Ambition Gate. Declare the project's ambition tier
+  (hobby / side-project / open-source-tool / venture / enterprise) before
+  Phase 0B research begins. The tier determines the depth and breadth of
+  research that follows; hobby-tier projects don't need venture-tier research,
+  and venture-tier projects can't skip it. Tier is stored in the entity profile
+  frontmatter and may evolve as the project matures. Per SAD v3.3+ amendment §29.
+  MANDATORY TRIGGERS: ambition tier, project ambition, hobby vs venture, what
+  scale is this, 0Δ, ambition gate, hobby project, side project, open source
+  tool, venture, enterprise, how much research do we need, research depth,
+  /ambition.
+---
+
+# Ambition Tier Skill
+
+The methodology workflow for Phase 0Δ — the Project Ambition Gate. Declares the project's ambition tier before Phase 0B research begins.
+
+## Why ambition-tier exists
+
+Per [[../../_ideas/build-roadmap-and-html-orchestration-2026-05-12|build-roadmap §29]], the methodology had implicitly assumed every SAD project is heading toward production scale. That's not true; scale matters; scale determines research depth.
+
+Without declaring the tier:
+
+- **Hobby-tier projects drown in venture-tier research** (over-researching a weekend hack).
+- **Venture-tier projects skip critical research** ("we know the market") and miss load-bearing context.
+
+Naming the tier prevents both failure modes.
+
+## When to invoke
+
+This skill runs at **Phase 0Δ — between Triage and Research**. It runs once per project at project start, and re-runs when the project's ambition evolves (e.g., a hobby becomes a side project; a side project becomes a venture).
+
+Triggers:
+
+- After triage closes and before research begins
+- When the operator asks "how much research do we actually need?"
+- When a project's scale is being reconsidered
+- When the entity profile's `ambition-tier` field needs to be set or updated
+
+## The five ambition tiers
+
+### 1. Hobby
+
+**Description:** Personal exploration. Built for the operator's own use or curiosity. Not intended to scale, ship publicly, or be commercial.
+
+**Research depth:** Light. Prior-art check. Existence check. Minimal context. No competitor breakdown. No market analysis.
+
+**Example deliverables required:**
+- Idea-dump (1 file is fine)
+- Light vision (paragraph; not VISION_SPEC)
+- Implementation as code; minimal spec
+- No required brand or business pillar work
+
+**Typical signs:**
+- "I just want to mess around with this"
+- "It's for me"
+- "I'm not trying to scale this"
+
+### 2. Side project
+
+**Description:** Personal but with intent to ship. May go public, may have a small user base, but not actively pursuing commercialization or growth.
+
+**Research depth:** Moderate. Prior art. Technical feasibility. Light competitor scan. Target-user identification (even if "users like me").
+
+**Example deliverables required:**
+- Idea-dump (multiple if warranted)
+- Light vision spec
+- Version spec with explicit V1 scope
+- Light spec stack (PRODUCT_SPEC at minimum; data/impl/behavioral/verification as code complexity warrants)
+- Brand: identity hypothesis (logo + voice register)
+- Business: light positioning; no formal business model
+
+**Typical signs:**
+- "I want to ship this publicly but not run it as a business"
+- "It's a personal project I want to be proud of"
+- "I might charge for it eventually but not now"
+
+### 3. Open-source tool / public good
+
+**Description:** Built to be used + extended by others. The community is the primary "audience" rather than commercial users. Sustainability via grants, donations, or sponsorships rather than commercial revenue.
+
+**Research depth:** Substantial. Prior art (especially other OSS in the space). Technical feasibility. Community-fit assessment (is there an audience for this OSS work?). License + governance research. Contributor landscape (who else is working in this space?).
+
+**Example deliverables required:**
+- Full spec stack (the spec IS the product for spec-first OSS)
+- Idea map + research synthesis
+- VISION_SPEC + VERSION_SPEC
+- License decision (with rationale)
+- Governance model (BDFL / multi-maintainer / foundation)
+- Contributor docs
+- Sustainability hypothesis
+- Brand: light; identity + voice for OSS audience
+- Business: sustainability model (grants, donations, sponsorships, founder-funded, optional commercial)
+
+**Typical signs:**
+- "I want others to build on this"
+- "This should be a public good"
+- "several product repos, methodology repos"
+
+### 4. Venture / business
+
+**Description:** Built to scale commercially. Has paying customers (or plans to), has growth ambitions, has investors (or plans to).
+
+**Research depth:** Full. Market analysis. Competitor breakdowns. Sizing (TAM/SAM/SOM). Customer research (interviews, surveys, behavior data). Pricing landscape. Regulatory + legal scan. Partnership opportunities. Distribution channels.
+
+**Example deliverables required:**
+- Full spec stack
+- Full Articulate lane traversal (0A → 1C)
+- Articulation closure inventory (per [[../articulation-closure/SKILL|articulation-closure skill]])
+- All three pillars active (Product + Brand + Business)
+- Business model + pricing
+- Sales motion design (if applicable)
+- Investor materials (pitch deck, financial model, data room)
+- Legal posture (incorporation, IP, ToS, privacy)
+
+**Typical signs:**
+- "I'm raising capital for this"
+- "This will be a company"
+- "I'm trying to find PMF"
+
+### 5. Enterprise
+
+**Description:** Built to sell to enterprise customers. Layered on top of venture-tier expectations, with additional concerns specific to enterprise sales motion.
+
+**Research depth:** Venture-tier + enterprise-readiness research. Security + compliance (SOC 2, GDPR, HIPAA, etc.). Procurement patterns (RFPs, vendor onboarding). Integration landscape. Sales motion (long cycles, multiple stakeholders). Partnership landscape (system integrators, channel partners).
+
+**Example deliverables required:**
+- Everything from Venture tier
+- Security policy + compliance roadmap
+- Enterprise sales playbook
+- Reference architecture for enterprise deployment
+- Partnership program design
+- RFP response template
+
+**Typical signs:**
+- "Our target customer is enterprise"
+- "Our sales motion is multi-stakeholder"
+- "We need SOC 2 / GDPR / etc."
+
+## How to run the ambition gate
+
+When this skill is loaded, the AI should:
+
+1. **Surface the current state.** Read the entity profile for any existing `ambition-tier` declaration.
+2. **Walk the tiers with the operator.** Don't assume; ask. The right tier is the one the operator commits to, not the one the AI infers.
+3. **Probe the commitment.** Press on the tier choice gently:
+   - "You said venture — what evidence do you have that this is venture-scale? Do you have a market thesis?"
+   - "You said hobby — but you've also said you want users. That sounds more like side-project."
+   - The probe is in office-hours-mode posture (sharp), but the goal is calibration, not critique.
+4. **Record the tier.** Update the entity profile frontmatter: `ambition-tier: <tier>`. Add changelog entry if tier changed from a previous value.
+5. **Surface what this tier implies.** What research depth is appropriate? What deliverables are required? What can be deferred?
+6. **Update the orchestration HTML.** Per [[../../_ideas/build-roadmap-and-html-orchestration-2026-05-12|§32]], the project's orchestration HTML reflects the ambition tier visibly.
+7. **Close the gate.** Confirm the tier; move to Phase 0B research (which the tier has now calibrated).
+
+## Backfill / missing assets
+
+Follow `operations/skills/_patterns/gate-backfill.md`. Skill-specific notes:
+
+1. **Detect** — entity profile missing `ambition-tier` while research/build runs.
+2. **Declare retrospectively** — tier matches *current* commitment.
+3. **Recalibrate** — trim or expand in-flight work; log over/under-build.
+4. **Freeze** — no venture deliverables on a hobby declaration (or reverse)
+   without explicit tier change + changelog.
+5. **Exit** — `ambition-tier` set; changelog; orchestration HTML updated.
+
+## Tier evolution
+
+Tiers can evolve. Common patterns:
+
+- **Hobby → Side project.** "I want to share this with friends" — slight escalation.
+- **Side project → Open-source tool.** Project gains contributors; community emerges.
+- **Side project → Venture.** Project finds early signal; operator decides to pursue commercially.
+- **Venture → Enterprise.** Product traction surfaces enterprise interest; pivot.
+- **Open-source tool → Open-source + commercial.** Sustainability model adds commercial offering.
+
+Tier de-escalation also happens:
+
+- **Venture → Side project.** Couldn't find PMF; operator decides to keep it as a personal project rather than abandoning it.
+- **Open-source tool → Archive.** Project ages out; community moves elsewhere.
+
+Each evolution is logged in the entity profile changelog with `lifecycle-ambition-change` entries.
+
+## What ambition-tier is NOT
+
+- **Not a value judgment.** Hobby tier isn't lesser than venture tier. They're different shapes for different work. The methodology supports all five.
+- **Not permanent.** Tiers evolve. The declaration is for *current* scale, not forever.
+- **Not a substitute for vision.** The vision tells you what the project could be at full scope. The tier tells you what to commit to *for this version*.
+
+## Relationship to other skills
+
+- [[../triage/SKILL|triage]] runs before ambition-tier
+- [[../friend-mode/SKILL|friend-mode]] for vision expansion (0C) — friend-mode helps see what's possible at the higher tiers
+- [[../office-hours-mode/SKILL|office-hours-mode]] for the tier-commitment probe — sharp framing about what the project actually is
+- Research (Phase 0B) reads `ambition-tier` to calibrate depth
+
+## Status
+
+- **2026-05-14:** Initial authoring per §29 amendment.

package/purpose/skills/telos/SKILL.md

@@ -0,0 +1,52 @@
+---
+type: knowledge
+tags: [everything-ecosystem, skills, purpose, telos, start-with-the-end]
+ai-model: claude-opus-5.5
+created: 2026-10-27T16:04:54Z
+source: hybrid
+name: telos
+description: >
+  Start with the end: help the owner state what the venture is for when it has
+  done its job, how anyone would know (measures), what the owners intend to
+  happen then (hold, sell, list, wind down), and what must be true to leave each
+  phase of the Succession Matrix, each tied to a measure. Records
+  purpose/telos.json. Other layers read it: governance's exit paths and MAD's
+  success measure. The owner writes it; an agent drafts and asks (EE-023).
+  MANDATORY TRIGGERS: telos, start with the end, end in mind, end state, what is
+  this for, north star, long-term goal, exit criteria, phase gate, when do we
+  move to the next phase, what does done look like for the venture.
+---
+
+# Telos: start with the end
+
+Purpose layer (EE-023). Writes `purpose/telos.json`; `node schema/check-telos.mjs` checks it. Covey's habit "begin with the end in mind" and Aristotle's telos, the end a thing exists for, name the same move: decide the end first, then derive every earlier step from it.
+
+## When
+
+- When a venture leaves Discovery (`check-telos.mjs` warns from then on, unless the ambition is hobby).
+- At every phase gate, to write the next phase's exit criteria.
+- When the ambition changes, because the owner outcome may change with it.
+
+## Template
+
+The default is `purpose/templates/telos-based-smart.md`. Write the ambition first, uncensored (BASED: statement, end state, owner outcome), then scope it (SMART: measures and exit criteria). The owner may choose another template.
+
+## Steps
+
+1. **Statement.** One sentence: what the venture is for when it has done its job. Draw on `venture.json` core (promise, promised to); the core is what the venture offers now, the telos is where that leads.
+2. **End state.** What is true in the world when the end is reached. Concrete enough that two people would agree whether it is true.
+3. **Measures.** Two to five, one primary. Each has a kind (revenue, usage or adoption, cost or time saved, compliance met, learning, flow and lead time, impact) and a target. The primary measure becomes MAD's success measure.
+4. **Owner outcome.** What the owners intend once the end is reached: hold, acquisition, IPO, secondary sale, merger, management buyout, or wind-down, and why. Check it fits the ambition and the ownership: investors who bought preferred shares expect an exit. `governance/exit.json` must prefer this path and may not rule it out.
+5. **Exit criteria per phase.** For the current phase and the next, what must be true to leave it. Start from the phase's generic gate in `purpose/frameworks/product-anatomy/phases.json` (Validation: product-market fit, retention holds) and make it this venture's. Every criterion names the measures it serves, so each phase's exit traces back to the end.
+
+## Who decides
+
+The owner. An agent drafts the statement and measures from the core and the venture profile, and asks; it never settles the end on the owner's behalf. Changing the owner outcome is also an `ownership-or-control` decision when there are other owners.
+
+## Sources
+
+- Stephen R. Covey, *The 7 Habits of Highly Effective People* (1989), habit 2: begin with the end in mind.
+- Aristotle, *Physics* II.3 and *Nicomachean Ethics* I (the final cause, telos).
+- Robert G. Cooper, Stage-Gate: each stage ends at a gate with exit criteria.
+
+These still need recording with `find-reference`.

package/purpose/strategic-foundation.json

@@ -0,0 +1,133 @@
+{
+  "version": "0.1.0",
+  "note": "Strategic foundation (EE-051, EE-052): the records a founder keeps in front of them every day, framed by the Five Ws and How plus whether (persevere, pivot, pause or stop; the review is not settled). Each statement is an attribute of a record that already exists; schema/foundation.mjs reports each one for a venture as confirmed (a person wrote or accepted it), drafted by an agent, waiting as a draft, or missing. Changing one ripples through the venture, so its record is gated.",
+  "questions": [
+    {
+      "id": "why",
+      "ask": "Why do you do it?",
+      "statements": [
+        {
+          "id": "problem",
+          "record": "validation-problem",
+          "attribute": "statement"
+        },
+        {
+          "id": "vision",
+          "record": "telos",
+          "attribute": "end_state"
+        }
+      ]
+    },
+    {
+      "id": "what",
+      "ask": "What do you do?",
+      "statements": [
+        {
+          "id": "mission",
+          "record": "venture",
+          "attribute": "core.promise"
+        },
+        {
+          "id": "products",
+          "record": "product",
+          "attribute": "name"
+        }
+      ]
+    },
+    {
+      "id": "who",
+      "ask": "Who do you serve?",
+      "statements": [
+        {
+          "id": "icp",
+          "record": "icp",
+          "attribute": "profiles"
+        },
+        {
+          "id": "promised-to",
+          "record": "venture",
+          "attribute": "core.promised_to",
+          "derived_from": "icp",
+          "note": "The ICP's short form: the primary profile's short, or its who. It takes the ICP's status and is never confirmed on its own, so the two cannot drift (Torian, 2026-10-28)"
+        }
+      ]
+    },
+    {
+      "id": "how",
+      "ask": "How do you do it?",
+      "statements": [
+        {
+          "id": "competence",
+          "record": "venture",
+          "attribute": "core.competence"
+        },
+        {
+          "id": "business-models",
+          "record": "product",
+          "attribute": "business_model"
+        }
+      ]
+    },
+    {
+      "id": "when",
+      "ask": "When do you do it?",
+      "statements": [
+        {
+          "id": "phase",
+          "record": "venture",
+          "attribute": "phase"
+        },
+        {
+          "id": "exit-criteria",
+          "record": "telos",
+          "attribute": "phases"
+        }
+      ]
+    },
+    {
+      "id": "where",
+      "ask": "Where do you do it?",
+      "statements": [
+        {
+          "id": "markets",
+          "record": "product",
+          "attribute": "market.geography"
+        },
+        {
+          "id": "channels",
+          "record": "validation-go-to-market",
+          "attribute": "channels"
+        }
+      ]
+    },
+    {
+      "id": "whether",
+      "ask": "Whether to do it, given what is true now?",
+      "statements": [
+        {
+          "id": "alignment",
+          "record": "alignment",
+          "attribute": "principles",
+          "note": "Replaces must-not (Torian, 2026-10-28): must-not described how the framework and platform behave, which is alignment, and alignment is longer than one line (EE-053). venture core.must_not stays as a one-line summary"
+        },
+        {
+          "id": "whether-review",
+          "record": null,
+          "attribute": null,
+          "note": "Not settled (Torian, 2026-10-28): go/kill is too narrow. Persevere, pivot, pause and stop stay draft frameworks, not the default. No design is agreed"
+        }
+      ]
+    },
+    {
+      "id": "brand",
+      "ask": "How are you known?",
+      "statements": [
+        {
+          "id": "tagline",
+          "record": "venture",
+          "attribute": "brand.tagline"
+        }
+      ]
+    }
+  ]
+}

package/purpose/templates/telos-based-smart.md

@@ -0,0 +1,39 @@
+---
+type: template
+tags: [everything-ecosystem, purpose, telos, template, based, smart]
+ai-model: claude-opus-5.5
+created: 2026-10-27T20:47:00Z
+source: hybrid
+---
+
+# Template: telos, BASED then SMART
+
+Fills `<venture>/purpose/telos.json` (EE-023), the default telos template. It writes in two passes. **BASED** states the ambition without hedging: the end as the owner truly means it. **SMART** then scopes it: measures and exit criteria that are specific, measurable, achievable, relevant and time-bound. BASED is the owner's ambition practice from earlier venture work; its letters are still to be written down here.
+
+## Pass 1: BASED (the ambition, uncensored)
+
+Write it the way you would say it if no one could object.
+
+- **Statement:** what the venture is for when it has done its job, in one sentence.
+- **End state:** what is true in the world then. Concrete enough that two people would agree whether it is true.
+- **Owner outcome:** what the owners intend then: hold, acquisition, IPO, secondary sale, merger, management buyout or wind-down, and why.
+
+## Pass 2: SMART (the scope)
+
+Turn the ambition into numbers the framework can check.
+
+| Measure id | Kind | Statement | Target (number and date) | Primary? |
+| --- | --- | --- | --- | --- |
+| | revenue, usage_or_adoption, cost_or_time_saved, compliance_met, learning, flow_and_lead_time, impact | | | exactly one |
+
+Then, for the current phase and the next, the exit criteria, each serving one or more measures:
+
+| Phase | Criterion id | What must be true | Serves |
+| --- | --- | --- | --- |
+| | | | |
+
+## Check
+
+- `node schema/check-telos.mjs <venture dir>`: every exit criterion traces to a measure, and `governance/exit.json` follows the owner outcome.
+- The primary measure is what a build method such as MAD reads as the success measure.
+- Other templates can replace this one. The skill offers BASED + SMART first.

package/purpose/tooling/integrations.json

@@ -0,0 +1,48 @@
+[
+  {
+    "id": "obsidian",
+    "name": "Obsidian",
+    "layer": "purpose",
+    "role": "vision, philosophy and BASED goals as notes",
+    "interfaces": [
+      "files",
+      "app"
+    ],
+    "status": "in-use",
+    "reason": "The vault is an Obsidian vault"
+  },
+  {
+    "id": "claude-docs",
+    "name": "Claude Docs",
+    "layer": "purpose",
+    "role": "shared drafts of vision and strategy",
+    "interfaces": [
+      "mcp"
+    ],
+    "status": "in-use",
+    "reason": "Used for the Polity vision draft on 2026-10-26"
+  },
+  {
+    "id": "notion",
+    "name": "Notion",
+    "layer": "purpose",
+    "role": "goals and vision pages",
+    "interfaces": [
+      "mcp",
+      "api"
+    ],
+    "status": "candidate",
+    "reason": "Connector exists; not yet chosen for this layer"
+  },
+  {
+    "id": "framer",
+    "name": "Framer",
+    "layer": "purpose",
+    "role": "public site design for the brand pillar",
+    "interfaces": [
+      "mcp"
+    ],
+    "status": "candidate",
+    "reason": "Connector exists"
+  }
+]

package/schema/README.md

@@ -0,0 +1,61 @@
+---
+type: index
+source: hybrid
+created: 2026-10-27T01:15:00Z
+ai-model: claude-opus-5.5
+tags: [everything-ecosystem, schema, index]
+description: "Index of the Everything Ecosystem schema: every record type an instance uses, where it is defined, and what is still missing. Independent of any one builder's workspace."
+---
+
+# Schema index
+
+The Everything Ecosystem is a schema, version in `VERSION`. An instance is a builder's workspace: a set of ventures, each with its product cards and, where it keeps them, account records (EE-011, EE-021). Personal life is out of scope (EE-009). This index lists every record type, so anyone can build an instance from this repo alone. Its machine form is `schema/data-model.json` (EE-018): every record type, its owning layer, schema, paths and references, checked by `schema/check-data-model.mjs`. There is no single master schema; the data model is the map of all of them. Nouns follow `docs/ontology.md` (EE-014).
+
+Status:
+- **defined**: a JSON Schema exists.
+- **prose**: the shape is described only in Markdown.
+- **missing**: the record type has no definition yet.
+
+## Instance level
+
+| Record | Where | Status | Notes |
+|---|---|---|---|
+| Workspace | `schema/workspace.schema.json`, `schema/VERSION` | defined | Grouping folders carry no meaning. Always a vault; a code folder of repositories once a venture builds software (EE-020) |
+| Venture | `schema/venture.schema.json`, `schema/check-ventures.mjs` | defined | Phase, ambition, form, industry, core product, parent, owner, layers, venture profile, one-way links |
+| Product (card) | `schema/product.schema.json` | defined | `products/<id>.json`: market, job, technology, offering, business model, flows |
+| Account | `schema/account.schema.json` | defined | Optional. `accounts/<id>/account.json` inside the venture that serves it; relationship client, customer, user, member, partner or other (EE-021) |
+| Venture folder layout | `schema/scaffold/defaults.json`, `schema/init-venture.mjs` | defined | Starting layers by phase; pillars and venture profile in every venture |
+| Nouns | `docs/ontology.json`, `schema/check-nouns.mjs` | defined | Standards first; retired nouns fail the check |
+| References | `schema/reference.schema.json`, `<layer>/references/references.json` | defined | Purpose has one so far; filled by `knowledge/skills/find-reference/` |
+| Data model | `schema/data-model.json`, `schema/data-model.schema.json`, `schema/check-data-model.mjs` | defined | Every record type, its owning layer and references; no JSON file may sit outside it |
+| Layer manifests | `schema/layer.schema.json`, `<layer>/layer.json`, system layer `schema/layer.json` | defined | Each layer's skills, record types it still owns, reads and writes; layer relationships are derived from them (EE-071). Venture packages are `packages/<name>/package.json` |
+
+## Inside a venture, by layer
+
+| Layer | Record | Where | Status |
+|---|---|---|---|
+| Purpose | Core product | `core` in `venture.json` | defined |
+| Purpose | Telos (start with the end) | `schema/telos.schema.json` at `<venture>/purpose/telos.json`; `check-telos.mjs` (EE-023) | defined |
+| Governance | Publication policy (the publication gate) | `schema/publication-policy.schema.json` at `<venture>/governance/publication-policy.json`; `check-publication.mjs` (EE-025) | defined |
+| Purpose | Validation package: problem record, shared evidence item, GRADE-adapted grading | `schema/validation-problem.schema.json` and `schema/validation-evidence.schema.json` at `<venture>/purpose/validation/`; `check-validation.mjs`; package at `packages/validation/` (templates and skills still under `purpose/kits/validation/`, EE-026, EE-071) | problem built; six sub-scores to build |
+| Purpose | Goals and vision | `purpose/frameworks/business-discovery-framework.md` | prose |
+| Purpose | Product Anatomy and Succession Matrix | `purpose/frameworks/product-anatomy/` (phases, gates, questions as JSON) | defined, draft |
+| Knowledge | Venture profile | the file `venture.json` names in `profile` | prose |
+| Knowledge | Decision log | `schema/decision.schema.json`; the schema's own log is `docs/decisions/decisions.json` (EE-NNN) | defined |
+| Operations | Handoff | `schema/handoff.schema.json` at `<venture>/operations/handoffs/<id>.json`, brief beside it; contract prose in `operations/handoff-v2.md` (execution folded into operations, EE-038); `check-ready.mjs` (definition of ready, EE-019), `run-handoff.mjs`, `check-execution.mjs` | defined |
+| Evidence | Evals and results | `schema/eval-suite.schema.json` for `evidence/evals/*.json`; `schema/evidence.schema.json` at `<venture>/evidence/results/<id>.json` | defined |
+| Evidence | Design-documents registry | `evidence/design-documents.registry.json` | self-describing, no schema |
+| Governance | Decision rights | `schema/decision-rights.schema.json`; template `governance/venture-template/decision-rights.json`, a venture's own at `<venture>/governance/decision-rights.json` (tightens only); switches on when a venture is formalized | defined |
+| Governance | Pillars (product, brand, business) | `governance/venture-template/pillars/`, stubs in each venture's `pillars/` | prose |
+| Governance | Ownership and control: cap table, boards, founder agreement, exit | `schema/ownership.schema.json`, `board.schema.json`, `founder-agreement.schema.json`, `exit.schema.json` at `<venture>/governance/`; `check-governance.mjs`, `payouts.mjs` (EE-022) | defined |
+| Governance | Roles | `governance/venture-template/roles/agent-roles.json` | shape used, no schema |
+| Product | Business models | `schema/vocab/business-models.json` (St. Gallen 55 plus named extras) | defined |
+| Every layer | Tool integrations | `schema/integration.schema.json`, `<layer>/tooling/integrations.json`, `check-integrations.mjs` (interfaces reach at least four layers) | defined |
+
+## Open reconciliations
+
+1. **Venture profile guidance.** The profile has no guidance of its own since the SAD documents were removed (EE-036); write a short template when a venture first needs one.
+2. **MAD's tiers.** EE-013 renames MAD's four layers to tiers; the MAD repo and older method documents still say layers.
+3. **Decisions.** The schema keeps its own log (EE-001 to EE-017). Older documents under `operations/` still cite workspace ids.
+4. **Personal references.** About twelve files still name one person or their paths. They need to be made generic or moved out.
+5. **Personal system.** Out of scope (EE-009). Built separately and joined later through links.

package/schema/VERSION

@@ -0,0 +1 @@
+0.5.0

package/schema/account.schema.json

@@ -0,0 +1,79 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "account.schema.json",
+  "title": "Account",
+  "description": "One named party the venture keeps a record for, at accounts/<id>/account.json inside the venture that serves it (EE-011, EE-021). Optional: only ventures that work per party need accounts; who a product serves in general is its market. Account follows CRM usage (an organization or person you have a relationship with). Not a venture: it has no phase or core.",
+  "type": "object",
+  "required": [
+    "id",
+    "name",
+    "relationship",
+    "status"
+  ],
+  "properties": {
+    "id": {
+      "type": "string",
+      "pattern": "^[a-z0-9-]+$"
+    },
+    "name": {
+      "type": "string"
+    },
+    "relationship": {
+      "enum": [
+        "client",
+        "customer",
+        "user",
+        "member",
+        "partner",
+        "other"
+      ],
+      "description": "How the venture stands to this party (EE-021). client: served under a professional relationship; customer: buys; user: uses, may not pay; member: belongs (a club, community or cooperative); partner: works with the venture; other: say which in the note"
+    },
+    "status": {
+      "enum": [
+        "prospect",
+        "active",
+        "paused",
+        "closed"
+      ]
+    },
+    "opened": {
+      "type": "string",
+      "format": "date"
+    },
+    "closed": {
+      "type": "string",
+      "format": "date"
+    },
+    "products": {
+      "type": "array",
+      "items": {
+        "type": "string"
+      },
+      "description": "Ids of the venture's products this account buys or uses"
+    },
+    "profile": {
+      "type": "string"
+    },
+    "layers": {
+      "type": "object",
+      "description": "Optional: where this account's knowledge and operations records live",
+      "properties": {
+        "knowledge": {
+          "$ref": "venture.schema.json#/$defs/layer"
+        },
+        "operations": {
+          "$ref": "venture.schema.json#/$defs/layer"
+        },
+        "evidence": {
+          "$ref": "venture.schema.json#/$defs/layer"
+        }
+      },
+      "additionalProperties": false
+    },
+    "note": {
+      "type": "string"
+    }
+  },
+  "additionalProperties": false
+}

package/schema/add-department.mjs

@@ -0,0 +1,41 @@
+// Imports one department into a venture (EE-047, EE-048): lists it in venture.json `departments`
+// and creates its folders, the operations side always and the governance side when the venture's
+// governance layer is on. Nothing else is created, so a venture holds only what it uses.
+//
+//   node schema/add-department.mjs <venture dir> <department id> [--group]
+//
+// --group puts the folders under primary/ or support/, by the department's place in the value
+// chain. The grouping is for looking at only: the department.json tag says what the folder is.
+// Writes nothing over an existing folder.
+
+import { existsSync, mkdirSync, readFileSync, writeFileSync } from "node:fs";
+import { join } from "node:path";
+import { catalog, foldersOf } from "./departments.mjs";
+
+const args = process.argv.slice(2);
+const group = args.includes("--group");
+const [dir, id] = args.filter((a) => !a.startsWith("--"));
+if (!dir || !id) { console.error("usage: node schema/add-department.mjs <venture dir> <department id> [--group]"); process.exit(2); }
+if (!existsSync(join(dir, "venture.json"))) { console.error(`${dir} has no venture.json`); process.exit(2); }
+const all = catalog();
+const d = all.find((x) => x.id === id);
+if (!d) { console.error(`unknown department ${id}: one of ${all.map((x) => x.id).join(", ")}`); process.exit(2); }
+
+const venture = JSON.parse(readFileSync(join(dir, "venture.json"), "utf8"));
+const layersOn = ["operations", ...(venture.layers?.governance ? ["governance"] : [])];
+const held = foldersOf(dir).filter((f) => f.tag?.department === id).map((f) => f.layer);
+const tag = { department: d.id, value_chain: d.value_chain, apqc: d.apqc.id };
+const made = [];
+for (const layer of layersOn.filter((l) => !held.includes(l))) {
+  const rel = join(layer, "departments", ...(group ? [d.value_chain] : []), d.id);
+  if (existsSync(join(dir, rel))) { console.error(`${rel} exists without a department.json; add the tag by hand`); process.exit(1); }
+  mkdirSync(join(dir, rel), { recursive: true });
+  writeFileSync(join(dir, rel, "department.json"), JSON.stringify(tag, null, 2) + "\n");
+  const [file, title, what] = layer === "governance"
+    ? ["charter.md", "charter", d.governance] : ["README.md", "operations", d.operations];
+  writeFileSync(join(dir, rel, file), `# ${d.label}: ${title}\n\nHolds: ${what}.\n\nAPQC ${d.apqc.id} ${d.apqc.name}; value chain: ${d.value_chain} (${d.porter}).\n`);
+  made.push(rel);
+}
+venture.departments = [...new Set([...(venture.departments ?? []), d.id])];
+writeFileSync(join(dir, "venture.json"), JSON.stringify(venture, null, 2) + "\n");
+console.log(made.length ? `added ${d.label}: ${made.join(", ")}` : `${d.label} is already in ${dir}`);