naive-framework 0.1.0 → 0.3.0

package/AGENTS.md

@@ -33,9 +33,10 @@ The Everything Ecosystem methodology, packaged as one private repo (EE-001). Pro
 - `node schema/check-publication.mjs <dir>` checks each venture's publication policy and every handoff that publishes: a named channel and content rule, and a person approving (EE-025).
 - `node schema/check-validation.mjs <dir> [--json]` grades each venture's validation records from their cited evidence (high to very low, adapted from GRADE). The validation package is `packages/validation/` (EE-071). A kit, Mentura's enhanced package, will live under `platform/kits/` and is not built yet.
 - `node schema/check-execution.mjs <venture dir>` checks handoffs, evidence and decision rights; `node schema/run-handoff.mjs <venture dir> <handoff id>` runs a handoff's done-criteria and writes evidence (EE-017).
-- `node interface/cli/naive.mjs typegen` writes `.naive/types/` from the route table and the MCP tools. `mentura typegen` is the same command. `naive upgrade <venture dir>` (was `mentura migrate`) moves a venture onto the next Naive layout. `naive port --from <project> --venture <dir>` plans bringing a project in with its files as they are, and `--apply --confirm port` carries the plan out, read-only on the project (EE-076, `node schema/port-test.mjs`). `naive migrate --from <project> --venture <dir>` has an agent rewrite the project as records, settled by `migrate-<function>` decisions and written through the router with `--apply` (`node schema/migrate-test.mjs`, with a stand-in agent). Neither opens a file that looks like a secret. `schema/init-venture.mjs` creates new ventures only. `node schema/check-private.mjs <dir>` fails when a private record or field could reach a model. `node schema/gate.mjs` is not a CLI: the gate reads `naive.config.json` and package gates and never calls a model.
+- `node interface/cli/naive.mjs typegen` writes `.naive/types/` from the route table and the MCP tools. `mentura typegen` is the same command. `naive upgrade <venture dir>` (was `mentura migrate`) runs the migrations in `schema/upgrades.json` up to the installed Naive and pins versions in `naive.config.json`; `--check`, `--guide`, `--adopt <package>`, `--canary`, `--agent` (a staged copy accepted with `--accept --confirm upgrade`) and `--framework` are in `schema/upgrade-venture.mjs` (`node schema/upgrades-test.mjs`). `mentura triggers` (`schema/triggers.mjs`) shows the triggers that run after each write and raises a failed run as a decision; `mentura notify` and `mentura stale` (`schema/stale.mjs`) mark summaries stale when a source changes; `mentura adapt` and `mentura adapters verify` (`interface/adapters.mjs`) write and test harness adapters. `naive port <folder> --venture <dir>` plans moving a folder into the venture whole and unchanged (to `repo/<name>` unless `--to` says where), naming what the move would break (worktrees, links into it, processes inside it); `--apply --confirm port` moves it with a rename, names it in `sources.json` as a read-only source of truth and logs the move in provenance (EE-076, a move since 2026-10-29; `node schema/port-test.mjs`). Each run writes `.release/port-trace.json` for `platform/integrations/langsmith.mjs`. `naive migrate --from <project> --venture <dir>` has an agent rewrite the project as records, settled by `migrate-<function>` decisions and written through the router with `--apply` (`node schema/migrate-test.mjs`, with a stand-in agent). Neither opens a file that looks like a secret. `schema/init-venture.mjs` creates new ventures only. `node schema/check-private.mjs <dir>` fails when a private record or field could reach a model. `node schema/gate.mjs` is not a CLI: the gate reads `naive.config.json` and package `gate_rules`, matches the router's path patterns and never calls a model. `node schema/check-config.mjs <venture dir>` checks `naive.config.json` (`--explain <route>`, `--rules`, `--resolved`, `--pin`); `node schema/gate-drafts.mjs <venture dir> [--owner <role>]` lists held drafts; `node schema/gate-test.mjs` tests the gate, the config, who is acting (`interface/acting.mjs`) and access at the record.
 - `node interface/cli/mentura.mjs <route> <action> --venture <id>` reads, writes, checks or runs one route; `node interface/mcp/server.mjs` is the MCP server and `node interface/api/server.mjs` the local API, all over `interface/router.mjs` (EE-030). Routes follow the Next.js App Router (EE-032): `[id]` collection items, nested ventures by path, layout, view, not-found, loading and error, route groups by phase, the `system/overview` slots and team-plan robots; see `docs/reference/ROUTES.md`. `node interface/test.mjs` tests them. Records are read and written through connectors for the venture's sources (`knowledge/connectors/`, EE-037); `node knowledge/connectors/eval.mjs` runs the framework's (filesystem) and `node platform/connectors/eval.mjs` the platform's (GitHub), both against `knowledge/connectors/suite.mjs`. The source map's `rules` are the source-of-truth matrix (EE-042, `knowledge/connectors/resolve.mjs`): a system of record and owner per record type, attribute and context; `node schema/check-sources.mjs <dir>` refuses ties, and `node schema/check-where-used.mjs <dir>` reports where-used children that drifted from their parent. Every write through them appends to the venture's provenance log, `provenance.jsonl` (EE-031); `node schema/check-provenance.mjs <dir>` checks its hash chain, and `mentura baseline --venture <id>` adopts records written before the log. `node schema/need-now.mjs <venture dir>` says what a venture needs now (EE-028); `node schema/time-to-ready.mjs <venture dir>` measures time to running and ready; `node schema/check-team.mjs <dir>` checks team plans against the agent capability register (EE-029).
 - `node schema/assess-problem.mjs <venture dir> [--as-is]` (route `purpose/validation/assess`) says what the problem's evidence is strong enough for: four assumptions labelled demonstrated to contradicted, the commitment they support (explore, prototype, charge, raise) and the next test, with no single score; it asks first when the record is incomplete (EE-050). `node schema/foundation.mjs <dir>` (route `purpose/foundation`) reports the strategic foundation by the Five Ws and How plus whether, and whose each is; `mentura confirm <statement>` and `mentura accept` of a foundation record need the name typed (EE-051).
+- `node schema/freshness.mjs <venture dir>` (route `system/freshness`, `mentura freshness`) says which records are fresh, stale, expired or live holes: by time from freshness profiles (`knowledge/freshness.json`, overridden under `freshness` in `naive.config.json`, with per-phase profiles) and on demand when a dependency changed or a tag, path or package was revalidated (`mentura revalidate`, `verify`, `phase`; route `system/revalidate`). A stale record is still read, with a `freshness` flag; `--freeze <dir>` writes a shell that leaves live records as holes (Revalidating, V-1 to V-8; `node schema/freshness-test.mjs`).
 - `node schema/bdd.mjs <file.feature>` runs Gherkin behaviors as tests, with step definitions in `<file>.steps.mjs`; behaviors are written first (EE-050).
 - `node purpose/frameworks/product-anatomy/test.mjs` tests the Product Anatomy runner's role rules.
 - `node schema/test.mjs` tests the checkers on broken copies; `python3 schema/validate.py` validates every record against its schema.

package/docs/decisions/decisions.json

@@ -856,6 +856,48 @@
         "EE-034",
         "EE-044"
       ]
+    },
+    {
+      "id": "EE-082",
+      "date": "2026-10-29",
+      "status": "in-force",
+      "related": [
+        "EE-047",
+        "EE-048",
+        "EE-060",
+        "EE-070",
+        "EE-076"
+      ],
+      "decision": "A venture has a type (venture.json `type`, from schema/venture-types.json), and create-venture scaffolds nothing until the type and the founder's role are set. The founder describes the venture in a few words and Jev classifies it (one Noul per type, uncertain below 0.5), or picks from the list; without TYPESAFE_API_KEY the list is the only way. The type decides the starting packages, the first decisions, the layers it needs and the functions it imports (as departments, with folders). Roles a person can hold are in governance/venture-template/roles/venture-roles.json; investors are roles too (general partner, limited partner), so an investor creates a venture of type vc-fund, which starts with a thesis, terms, deals and a portfolio of nested ventures instead of product questions. people/ holds the venture's human capital: people/people.json (who is in it, in which role, and the functions, or hats, each owns; a solo founder owns every function) and one file per founder in people/founders/, linked to the founder agreement. schema/check-people.mjs checks that roles, hats and founder files agree.",
+      "why": "Torian, 2026-10-29: the app should not be scaffolded until a role is chosen and the type of venture is selected; an investor can be a role, and a VC fund needs a thesis and other templates than a software startup; a solo founder owns every function by default; people needs a top-level folder that is to human capital what venture.json is to the venture, with one file per founder linked to founding agreements. Defaults (one file per founder, the type list, investor split into general and limited partner, the folder name people/, the model only with a key) were chosen by the coordinator on Torian's go-ahead and stay open to change."
+    },
+    {
+      "id": "EE-083",
+      "date": "2026-10-29",
+      "status": "in-force",
+      "related": [
+        "EE-037",
+        "EE-042",
+        "EE-070",
+        "EE-082"
+      ],
+      "decision": "Setup asks where each of the venture's functions keeps its truth, and records the answers as pointers in knowledge/sources.json under `functions` (the source-of-truth matrix, EE-042, not a second file), with `truth` naming where the venture's source of truth as a whole lives (local by default). schema/systems-catalog.json lists the systems offered per function (a local repo, GitHub, Vercel, Cloudflare, Stripe, Square, Shopify, Rho, Google Drive, DocuSign, a local folder). A system Naive reads through code is connected (Rho, through its MCP API: sandbox, live with RHO_API_TOKEN, or a saved fixture marked as one); the rest are pointed until a connector exists. A function with no system keeps the founder's words. naive dev serves a setup page at /setup (interface/dev/setup.mjs) that walks through people and hats, sources of truth, the strategic foundation and first decisions (each answer an approved decision; a foundation statement as a decision with `statement`), and a goal for discovery, and says when the structure is established and what comes next. A new venture's .gitignore keeps sensitive stream activity out of git.",
+      "why": "Torian, 2026-10-29: when scaffolding, ask the user to point Naive to the source of truth for each function (the repo, GitHub and Vercel for a software product; analytics from the host; Stripe, Square or Shopify for sales; Rho for financials in the demo; legal documents, with the connections to set them up if missing), let a function default or be answered in prose, and ship a local setup experience like the one Next.js gives, essentially the strategic foundation and a version of the decision docket, ending by setting a goal for the discovery phase. After setup a founder has the structure of the venture and a way of routing decisions; operating it is Mentura's, as deploying is Vercel's after Next.js."
+    },
+    {
+      "id": "EE-086",
+      "date": "2026-10-29",
+      "status": "in-force",
+      "related": [
+        "EE-047",
+        "EE-070",
+        "EE-071",
+        "EE-082",
+        "EE-083",
+        "EE-085"
+      ],
+      "decision": "The venture project structure (docs/design/VENTURE_STRUCTURE_2026-10-29.md). At the top: venture.json, README.md (was profile.md), AGENTS.md, knowledge/ (the knowledge base), meta/ (sources.json, naive.config.json, provenance.jsonl, releases) and an optional repo/ for code. Packages sit flat in knowledge/. venture.json declares the business functions once (the org chart, flat by default with one function per package owned by the founder); packages and records inherit their function from it, a founder composes functions over several packages, (group)/ folders are an optional view, and hats derive from function ownership. A record's route is its path inside knowledge/, with groups and the extension dropped: no name table, no reserved route names. Skills teach where files go; code guarantees schema, the person-only gate, private data, provenance and outside systems. A function's publishable items are in public.json where it has any.",
+      "why": "Torian, 2026-10-29: the folder structure is a visual aid and an educational device for how a founder should think about the business; put the knowledge base in a knowledge folder, code in an optional repo folder like src, and add a meta folder; let people group and merge functions their own way, starting from a flat org chart declared in the venture file that everything inherits from; routes were overcomplicated, and agents can handle file conventions with skills. Answers marked default in the design note are Claude's recommendations until Torian changes them."
     }
   ]
 }

package/docs/reference/ROUTES.md

@@ -1,35 +1,3 @@
----
-type: reference
-source: generated
-created: 2026-10-27T20:52:31Z
-ai-model: claude-opus-5.5
-tags: [everything-ecosystem, mentura, routing, interfaces, reference]
-description: "Every route a venture has: the records and commands the CLI, the MCP server and the HTTP API reach, with their actions and gates (EE-030). The table below is generated from the data model and kits; test.mjs fails when it is stale."
----
-
-# Routes
-
-One route table serves three interfaces: the CLI (`interface/cli/mentura.mjs`), the MCP server (`interface/mcp/server.mjs`) and the HTTP API (`interface/api/server.mjs`). All three call `interface/router.mjs`, so they cannot disagree. Install them into an agent harness with `interface/skills/install-mentura/SKILL.md`.
-
-Routes follow the Next.js App Router (EE-032). The path is the route: a record in a layer's own kit is `<layer>/<record>`, and a record in a nested kit is `<layer>/<kit>/<record>`, so a route is its record's folder path. The venture comes first: an id, or a nested venture's folder path (`studio/print`), given as `--venture`, a tool argument, or `/ventures/<venture>/` in the API.
-
-| Next.js | Here |
-| --- | --- |
-| `route` (API endpoint) | record actions read, write, check and template; command routes run |
-| `page` | the view action: a Markdown page for a person |
-| `layout` | the layout action: system, layer and kit context, skills, references, gate and need-now status |
-| `not-found`, `loading`, `error` | a missing record answers with its template and need-now status; a waiting draft is reported on read; a failed check or write answers with the kit's skills and template |
-| `[id]` | collection items: `purpose/product/[id]` beside the list route `purpose/product` |
-| `[...slug]` | the venture: `studio/print` |
-| `(group)` | route groups by phase, below |
-| `@slot` | `system/overview`: slots that render side by side, one failing without stopping the rest |
-| `_private` | `_drafts/`, never routed |
-| `proxy` | gates before every write: schema, decision class (from the data model, applied from the venture's decision rights), the role's routes |
-| `robots` | team-plan roles may list the routes they read and write; `system/robots` shows them |
-| redirects | `interface/route-aliases.json`: a renamed route keeps its old one as an alias |
-
-Nothing here is written by hand: add a record type to `schema/data-model.json` and a kit, and its route appears. Regenerate the table with `node interface/router.mjs --md`.
-
 ## Routes (generated by `node interface/router.mjs --md`)
 
 Every route works on one venture, named in front of it: its id, or its folder path for a nested venture (`studio/print`). Record routes read, write, check, view, lay out or show the template of one record type; a collection has a list route and an `[id]` item route; command routes run a venture-wide tool and can be viewed. A write is checked against the record's schema first; a record whose decision class escalates is written as a draft when an agent writes it, for a person to accept.
@@ -39,6 +7,8 @@ Every route works on one venture, named in front of it: its id, or its folder pa
 | `.release/venture-package` | record | read, view, layout | `.release/venture-package.json`, `.release/layout.json`, `package/venture-package.json` |  | (discovery) (validation) (beachhead) (scale) (platform) | The venture package view (EE-067, EE-069): the open core packages and handoffs, each record confirmed, to review or to write, what moves now and what waits, with its versions; the records themselves stay in place |
 | `customers` | record (list) | read, view, layout | `customers/*.json` |  |  | A customer master record. Activity is an append-only stream. The package is never complete (EE-070). |
 | `customers/[id]` | record (item) | read, view, layout, write | `customers/*.json` |  |  | A customer master record. Activity is an append-only stream. The package is never complete (EE-070). |
+| `deals` | record (list) | read, view, layout | `deals/*.json` |  |  | A company in a fund's pipeline (EE-082) |
+| `deals/[id]` | record (item) | read, view, layout, write | `deals/*.json` |  |  | A company in a fund's pipeline (EE-082) |
 | `decisions` | record (list) | read, view, layout | `decisions/*.decision.json` |  | (discovery) (validation) (beachhead) (scale) (platform) | One live decision, in a decisions/ folder beside the record it decides, with its parent, boundary (fail closed or open) and the phase it is needed in (EE-054, EE-057); node schema/decisions.mjs renders the matrix. The decision log keeps the history |
 | `decisions/[id]` | record (item) | read, view, layout, write | `decisions/*.decision.json` |  | (discovery) (validation) (beachhead) (scale) (platform) | One live decision, in a decisions/ folder beside the record it decides, with its parent, boundary (fail closed or open) and the phase it is needed in (EE-054, EE-057); node schema/decisions.mjs renders the matrix. The decision log keeps the history |
 | `evidence` | record (list) | read, view, layout, check | `evidence/results/*.json` |  | (validation) (beachhead) (scale) (platform) | Append-only results of running checks |
@@ -47,6 +17,11 @@ Every route works on one venture, named in front of it: its id, or its folder pa
 | `foundation/icp` | record | read, view, layout, write | `foundation/icp.json`, `purpose/icp.json` | strategy-or-constitution | (discovery) (validation) (beachhead) (scale) (platform) | Who the venture serves: ideal customer profiles, one primary (EE-051); a foundation statement, gated |
 | `foundation/problem` | record | read, view, layout, write, check, template | `foundation/problem.json`, `purpose/validation/problem.json` | strategy-or-constitution | (discovery) (validation) (beachhead) | The problem sub-score of validation: the claim and its cited evidence, each item graded (EE-026). Shares schema/validation-evidence.schema.json with every sub-score Gated like the telos (EE-050): the problem statement is a founder-critical record, so an agent's write is a draft the founder accepts. |
 | `foundation/telos` | record | read, view, layout, write, check, template | `foundation/telos.json`, `purpose/telos.json` | strategy-or-constitution | (validation) (beachhead) (scale) (platform) | The end the venture exists to reach: statement, end state, measures, owner outcome, exit criteria per phase (EE-023) |
+| `fund/terms` | record | read, view, layout, write | `fund/terms.json` |  |  | A fund's terms and closes (EE-082) |
+| `fund/thesis` | record | read, view, layout, write | `fund/thesis.json` |  |  | A fund's thesis (EE-082) |
+| `glossary` | record (list) | read, view, layout, check, template | `glossary/*.json` |  | (beachhead) (scale) (platform) | A package's own terms, at glossary/<package>.json (Y-2): local to the package unless exported, so an agent in another package sees only exported terms; glossary/terms shows what one package sees |
+| `glossary/[id]` | record (item) | read, view, layout, write, check, template | `glossary/*.json` |  | (beachhead) (scale) (platform) | A package's own terms, at glossary/<package>.json (Y-2): local to the package unless exported, so an agent in another package sees only exported terms; glossary/terms shows what one package sees |
+| `glossary/terms` | command | run, view, layout | `schema/brand.mjs` |  |  | The terms one package sees (Y-2): its own glossary and the terms other packages export; their local terms stay with them. Input value is the package |
 | `governance/analytics` | command | run, layout | `schema/decision-analytics.mjs` |  |  | Decision analytics (EE-072): how many decisions of each type each function has made, open against decided, in whose words, in which phase, and their outcomes. Data only; a view is the platform's, or a visualization skill's |
 | `governance/board` | record | read, view, layout, write, check | `governance/board.json` | ownership-or-control | (platform) | Formal and advisory boards, their seats and reserved matters |
 | `governance/decision-rights` | record | read, view, layout, write, check | `governance/decision-rights.json` | strategy-or-constitution | (validation) (beachhead) (scale) (platform) |  |
@@ -63,12 +38,20 @@ Every route works on one venture, named in front of it: its id, or its folder pa
 | `investors` | record (list) | read, view, layout | `investors/*.json` |  |  | An investor master record. Activity is an append-only stream. The package is never complete (EE-070). |
 | `investors/[id]` | record (item) | read, view, layout, write | `investors/*.json` |  |  | An investor master record. Activity is an append-only stream. The package is never complete (EE-070). |
 | `knowledge/catalog` | command | run, view, layout | `knowledge/connectors/catalog.mjs` |  |  | Build or refresh the catalog: every item in every source the venture keeps records in, with its address and version, no content (EE-037) |
+| `knowledge/freshness-log` | record | read, view, layout | `knowledge/freshness.jsonl` |  | (beachhead) (scale) (platform) | On-demand revalidations (a tag, a path or a package marked stale), checks that a record is still right, and phase changes: one append-only line each (Revalidating V-1, V-5, V-7) |
+| `knowledge/judgment` | record (list) | read, view, layout | `knowledge/judgments/*.json` |  |  | The typed output of one model step (use model, EE-073): what it read, its answer and confidence, and whether code accepted, overruled or routed it to a person as uncertain. The agent's until a person confirms it (schema/model-steps.mjs) |
+| `knowledge/judgment/[id]` | record (item) | read, view, layout, write | `knowledge/judgments/*.json` |  |  | The typed output of one model step (use model, EE-073): what it read, its answer and confidence, and whether code accepted, overruled or routed it to a person as uncertain. The agent's until a person confirms it (schema/model-steps.mjs) |
 | `knowledge/knowledge-sources` | record | read, view, layout, write, check | `knowledge/sources.json` |  | (scale) (platform) | Which source each record type lives in: the venture's own folder by default, or a connected source such as a GitHub repository (EE-037); its rules are the source-of-truth matrix: a system of record and owner per record type, attribute and context (EE-042) |
 | `knowledge/search` | command | run, view, layout | `knowledge/connectors/catalog.mjs` |  |  | Find items across every source through the catalog; input value is the query (EE-037) |
 | `knowledge/venture-profile` | record | read, view, layout | `profile.md` |  | (discovery) (validation) (beachhead) (scale) (platform) | The venture's story and thesis in prose, beside venture.json |
 | `knowledge/where-used` | record | read, view, layout, write, check | `knowledge/where-used.json` |  | (scale) (platform) | For each fact kept once in its system of record, every place that repeats it; live children must show the parent's value (EE-042) |
+| `marketing/brand` | record | read, view, layout, write, check, template | `marketing/brand.json` | experience-design | (beachhead) (scale) (platform) | Brand tokens in the marketing package (Y-3): colors, licensed self-hosted typefaces (T-1), the font each role uses with scopes where nearer context wins (Y-5, T-2), voice rules (the global stylesheet for words), the logo and marks (P-24) and outside design systems by reference (Y-4). Read by every agent's layout; marketing/brand/tokens renders it for interfaces |
+| `marketing/brand/resolve` | command | run, view, layout | `schema/brand.mjs` |  |  | The brand at one route (Y-5, T-2): the venture brand with every scope that covers the route applied, nearer last, and which scope set each value; input value is the route |
+| `marketing/brand/tokens` | command | run, view, layout | `schema/brand.mjs` |  |  | The venture's brand tokens (Y-3): colors and typefaces as W3C design tokens, the CSS custom properties and @font-face rules an interface loads, each scope as its own selector, and the head links for the venture's marks (P-24) |
 | `marketing/content` | record | read, view, layout | `marketing/content/**/*.mdx`, `operations/marketing/content/**/*.mdx` |  | (beachhead) (scale) (platform) | Public variants of internal records, written by marketing agents as their own MDX: each names the record it is a variant of, its audience, whether it is published and who approved it; checked by the public gate (EE-064) |
 | `marketing/sitemap` | record | read, view, layout, write | `marketing/sitemap.json`, `operations/marketing/sitemap.json` |  | (validation) (beachhead) (scale) (platform) | The planned public site: each page's sections in order, with the MDX component, the need, the audience and why, when it shows, the internal record it draws on and the public variant to write; part of the marketing package handed to engineering (EE-064, EE-065) |
+| `marketing/sitemap/xml` | command | run, view, layout | `schema/brand.mjs` |  |  | sitemap.xml rendered from the marketing sitemap record (P-26), for a release; input value is the site's base URL |
+| `marketing/voice` | command | run, view, layout | `schema/brand.mjs` |  |  | Marketing content held to the voice rules, the global stylesheet for words (Y-3): each phrase to avoid, where it is and what to use instead; and terms another package keeps local (Y-2) |
 | `money` | record (list) | read, view, layout | `money/*.json` |  |  | A money master record. Activity is an append-only stream. The package is never complete (EE-070). |
 | `money/[id]` | record (item) | read, view, layout, write | `money/*.json` |  |  | A money master record. Activity is an append-only stream. The package is never complete (EE-070). |
 | `operations/department` | record | read, view, layout, check | `departments/*/department.json`, `departments/*/*/department.json` |  | (validation) (beachhead) (scale) (platform) | The tag in each department folder, in the governance or operations layer; an optional primary/ or support/ grouping folder is for looking at only (EE-047) |
@@ -78,6 +61,9 @@ Every route works on one venture, named in front of it: its id, or its folder pa
 | `operations/marketing/site` | command | run, view, layout | `operations/marketing/site/presence.mjs` |  |  | How present the venture's public records are on its marketing site: a score weighed by who the site must speak to now (raising, hiring, contributors, ICPs), and each item missing, not prominent enough or present, with where it belongs (EE-062). Read the site first with interface/harness/site.mjs |
 | `operations/marketing/sitemap` | command | run, view, layout | `operations/marketing/site/plan.mjs` |  |  | Plan the public site from the venture's records: the product decides whom it is offered to, that decides the audiences, and each page gets its sections in order with the MDX component, need, audience, reason, condition, source record and the public variant to write (EE-064) |
 | `operations/site-presence` | record | read, view, layout, write | `operations/marketing/site-presence.json` |  | (validation) (beachhead) (scale) (platform) | How present the venture's public records are on its marketing site, item by item, with a score weighed by who the site must speak to now (EE-062) |
+| `people` | record | read, view, layout, write | `people/people.json` |  | (discovery) (validation) (beachhead) (scale) (platform) | The venture's people: role and hats per person; venture.json for human capital (EE-082) |
+| `people/founders` | record (list) | read, view, layout | `people/founders/*.json` |  | (discovery) (validation) (beachhead) (scale) (platform) | One file per founder, linked to the founder agreement (EE-082) |
+| `people/founders/[id]` | record (item) | read, view, layout, write | `people/founders/*.json` |  | (discovery) (validation) (beachhead) (scale) (platform) | One file per founder, linked to the founder agreement (EE-082) |
 | `people/team` | record | read, view, layout, write, check, template | `people/team.json`, `purpose/validation/team.json` |  | (validation) (beachhead) (scale) | Validation sub-score: skills needed, held and the gaps; cofounder sought (EE-026) |
 | `people/team-plan` | record | read, view, layout, write, check | `people/team-plan.json`, `operations/team-plan.json` |  | (validation) (beachhead) (scale) (platform) | Who the venture needs, agent or person, when, with what authority, and where a human stays in the loop; recruiting briefs for open person roles (EE-029) |
 | `product` | record (list) | read, view, layout, check | `product/*.json`, `products/*.json` |  | (discovery) (validation) (beachhead) (scale) (platform) |  |
@@ -85,6 +71,8 @@ Every route works on one venture, named in front of it: its id, or its folder pa
 | `product/anatomy` | record (list) | read, view, layout | `product/anatomy/*.json`, `purpose/anatomy/*.json` |  | (beachhead) (scale) (platform) | Product Anatomy input for one product with parts (venture, core, products, flows), such as Naive or Mentura; read by purpose/frameworks/product-anatomy/anatomy.mjs |
 | `product/anatomy-answers` | record | read, view, layout | `product/anatomy/answers*.json`, `product/anatomy.answers*.json`, `purpose/anatomy.answers*.json` |  | (beachhead) (scale) (platform) | Scores per product per question; the matrix is rendered from them |
 | `product/anatomy/[id]` | record (item) | read, view, layout | `product/anatomy/*.json`, `purpose/anatomy/*.json` |  | (beachhead) (scale) (platform) | Product Anatomy input for one product with parts (venture, core, products, flows), such as Naive or Mentura; read by purpose/frameworks/product-anatomy/anatomy.mjs |
+| `public/assets` | record | read, view, layout, write, check, template | `public/assets.json` |  | (beachhead) (scale) (platform) | The register of what the venture ships as it is, in public/ (I-23, J-2, J-3, J-4): each file's source, license and credit, facts code reads from its bytes, alt text and who wrote it; remote images as links with a note in raw/; the hosts an agent may fetch from |
+| `public/assets/facts` | command | run, view, layout | `schema/assets.mjs` |  |  | What code reads from each file in public/ (J-4): type from the bytes, width and height, icon sizes, bytes and sha256. Agents copy these, never guess them |
 | `purpose/account` | record (list) | read, view, layout, check | `accounts/*/account.json` |  | (beachhead) (scale) (platform) | A named party the venture keeps a record for: client, customer, user, member or partner (EE-021). Optional |
 | `purpose/account/[id]` | record (item) | read, view, layout, write, check | `accounts/*/account.json` |  | (beachhead) (scale) (platform) | A named party the venture keeps a record for: client, customer, user, member or partner (EE-021). Optional |
 | `purpose/data-stream` | record (list) | read, view, layout | `customers/_streams/*/stream.json`, `investors/_streams/*/stream.json`, `money/_streams/*/stream.json` |  |  | Declares one append-only stream and whether it is sensitive (EE-070). |
@@ -93,6 +81,7 @@ Every route works on one venture, named in front of it: its id, or its folder pa
 | `purpose/ideas` | command | run, view, layout | `purpose/frameworks/idea-map/ideamap.mjs` |  |  | The founder's idea dump mapped onto Naive's conventions: each idea verbatim with its departments, records and whether it exists, where the ideas cluster, what the dump never mentions, and what it says about whether a product exists (EE-059) |
 | `purpose/ideas/graph` | command | run, view, layout | `purpose/frameworks/idea-map/graph.mjs` |  |  | The idea graph: which ideas build on which, each idea's signal, the lanes that move in order and the ones that can move on their own, and the ideas to develop next (EE-060) |
 | `purpose/ideas/routes` | command | run, view, layout | `purpose/frameworks/idea-map/route.mjs` |  |  | Where each idea goes in the framework: the records it feeds, each destination's stage (routed, drafted, your decision, waiting, done), whether it moves in order or on its own, and the one step that moves it; plus the decision docket traced to the ideas (EE-061) |
+| `purpose/money/summary` | record | read, view, layout, write | `money/_summary.json` |  | (beachhead) (scale) (platform) | Cash, monthly flows and runway from the money source's last sync; versioned, and the only money record a model sees (EE-070) |
 | `purpose/raw/text` | record (list) | read, view, layout | `raw/sources/*/text.md` |  |  | The text of a raw source. original.* stays out of git (EE-070). |
 | `purpose/raw/text/[id]` | record (item) | read, view, layout | `raw/sources/*/text.md` |  |  | The text of a raw source. original.* stays out of git (EE-070). |
 | `purpose/validation/assess` | command | run, view, layout | `schema/assess-problem.mjs` |  |  | What the problem's evidence is strong enough for: each assumption labelled demonstrated, inferred, assumed, unknown or contradicted, the commitment it supports and the next test (EE-050). Asks first when the record is incomplete; input as_is runs it anyway |
@@ -100,12 +89,22 @@ Every route works on one venture, named in front of it: its id, or its folder pa
 | `raw/dump` | record | read, view, layout | `raw/dump.md`, `purpose/ideas/dump.md` |  | (discovery) (validation) | The founder's raw idea dump: every idea about the venture, verbatim and unprompted. Never rewritten by an agent (EE-059) |
 | `raw/sources` | record (list) | read, view, layout | `raw/sources/*/source.json` |  |  | Where a founder-supplied source came from. Raw is immutable (EE-070). |
 | `raw/sources/[id]` | record (item) | read, view, layout, write | `raw/sources/*/source.json` |  |  | Where a founder-supplied source came from. Raw is immutable (EE-070). |
+| `system/answer` | command | run, view, layout | router |  |  | One answer from several routes (C-8): each part says whether it is a confirmed record, an agent's record, a draft, a cached result or judgment, or fresh computation; input routes (a list, or value a,b) and judge (a request) |
+| `system/cache` | command | run, view, layout | router |  |  | The venture's cache (C-1, C-17): entries by level, what is private to you, what has expired, and which routes are cached for how long; input value list, prune or clear |
+| `system/context` | command | run, view, layout | `interface/context.mjs` |  |  | The context budget (N-13): what every route sends an agent, in tokens, against its budget, with the largest part and where to move it (S-14, F-6) |
+| `system/freshness` | command | run, view, layout | `schema/freshness.mjs` |  |  | What is fresh, stale or expired, and which records are live holes: by time (freshness profiles, per phase too) and on demand (a dependency changed, a where-used parent drifted, a tag, path or package was revalidated) |
+| `system/judge` | command | run, view, layout | router |  |  | Ask System 1 a typed request ({ state, model, questions }) through the judgment cache (S-8, C-5): reused answers are not asked again; the rest go to NAIVE_JUDGE_CMD in one request |
+| `system/naive-config` | record | read, view, layout, write, check | `naive.config.json` | security-loosening |  | The venture's overrides to Naive's defaults (P-2, like next.config.js): the gate's static rules, function owners, check settings, thresholds, which System 1 questions run, pinned package versions and how strictly the acting role is checked. An agent's write of it is a draft, since it can loosen the gate |
 | `system/need-now` | command | run, view, layout | `schema/need-now.mjs` |  |  | What the venture needs now, soon, or should hold back (EE-028) |
 | `system/overview` | command | run, view, layout | router |  |  | The venture at a glance: telos, validation, need-now, time to ready, team and recent provenance, rendered as parallel slots |
 | `system/package` | command | run, view, layout | `schema/packages.mjs` |  |  | The venture package (EE-067, EE-069): the core packages open now and the handoffs, each record confirmed, to review or to write, what moves on its own and what waits, and what completion unlocks; --write renders the view and records a version. Assumes a solo founder or small founding team in Discovery and Validation; agents are a package enhancement |
 | `system/provenance` | record | read, view, layout, check | `provenance.jsonl` |  | (discovery) (validation) (beachhead) (scale) (platform) | Who or what wrote each record, how, from what and under which decision: one append-only line per write, hash-chained, after W3C PROV (EE-031) |
+| `system/release` | record | read, view, layout | `.release/release.json`, `.release/card.json` |  | (beachhead) (scale) (platform) | A release (C-11, I-17): the venture's static shell, written by node schema/build-release.mjs. release.json is the manifest (confirmed records frozen in with their sha256, date and who confirmed them; named live holes; the route table as the release holds it; frozen command answers); card.json is the release card's data (P-25, O-7). The frozen copies under .release/records/ keep their own record types. Read without the router by node schema/start-release.mjs |
+| `system/revalidate` | command | run, view, layout | `schema/freshness.mjs` |  |  | Mark records stale on demand: input value tag:<route> (the record and what depends on it), path:<folder>, package:<name>, or pivot (the validation package); a plain folder is refused in favour of exact tags |
 | `system/robots` | command | run, view, layout | router |  |  | Which roles may read and write which routes, from the team plan |
+| `system/steps` | command | run, view, layout | `schema/model-steps.mjs` |  |  | The model steps' payload (use model, EE-073): what code computed, a placeholder for each judgment a model has yet to give, and the only fields each one receives; asks no model. mentura steps run asks one |
 | `system/time-to-ready` | command | run, view, layout | `schema/time-to-ready.mjs` |  |  | Time to running, and to ready per layer and MAD tier |
+| `system/vitals` | command | run, view, layout | `interface/vitals.mjs` |  |  | Agent vitals (N-6): calls per task, tokens of context per call, time to a useful answer and time from a decision opening to a person deciding it, at the 75th percentile, each checked against its threshold (C-15). Reads the events log that instrumentation writes |
 | `validation/go-to-market` | record | read, view, layout, write, check, template | `validation/go-to-market.json`, `purpose/validation/go-to-market.json` |  | (validation) (beachhead) (scale) | Validation sub-score: path, motion, channels and evidence a channel works; the path sets the weights (EE-026) |
 | `validation/operations-readiness` | record | read, view, layout, write, check, template | `validation/operations-readiness.json`, `purpose/validation/operations-readiness.json` |  | (beachhead) (scale) (platform) | Validation sub-score: per MAD tier evidence; grades as the weakest tier (EE-026) |
 | `validation/pricing` | record | read, view, layout, write, check, template | `validation/pricing.json`, `purpose/validation/pricing.json` |  | (validation) (beachhead) (scale) | Validation sub-score: price model, points, buyer and evidence they pay (EE-026) |
@@ -118,8 +117,8 @@ A group gathers the routes need-now suggests in a phase. It changes the layout a
 
 | Group | The phase asks | Routes |
 | --- | --- | --- |
-| `(discovery)` | Does a real problem exist, and who has it? | `.release/venture-package`, `decisions`, `decisions/[id]`, `foundation/alignment`, `foundation/icp`, `foundation/problem`, `ideas/graph`, `ideas/map`, `knowledge/venture-profile`, `product`, `product/[id]`, `raw/dump`, `system/provenance` |
-| `(validation)` | Will people adopt this solution and keep using it? | `.release/venture-package`, `decisions`, `decisions/[id]`, `evidence`, `evidence/[id]`, `foundation/alignment`, `foundation/icp`, `foundation/problem`, `foundation/telos`, `governance/decision-rights`, `governance/publication-policy`, `ideas/graph`, `ideas/map`, `knowledge/venture-profile`, `marketing/sitemap`, `operations/department`, `operations/handoff`, `operations/handoff/[id]`, `operations/site-presence`, `people/team`, `people/team-plan`, `product`, `product/[id]`, `raw/dump`, `system/provenance`, `validation/go-to-market`, `validation/pricing`, `validation/product-market-fit`, `validation/solution` |
-| `(beachhead)` | Can we win one segment repeatably, at a profitable cost? | `.release/venture-package`, `decisions`, `decisions/[id]`, `evidence`, `evidence/[id]`, `foundation/alignment`, `foundation/icp`, `foundation/problem`, `foundation/telos`, `governance/decision-rights`, `governance/pillar`, `governance/pillar/[id]`, `governance/publication-policy`, `knowledge/venture-profile`, `marketing/content`, `marketing/sitemap`, `operations/department`, `operations/handoff`, `operations/handoff/[id]`, `operations/site-presence`, `people/team`, `people/team-plan`, `product`, `product/[id]`, `product/anatomy`, `product/anatomy-answers`, `product/anatomy/[id]`, `purpose/account`, `purpose/account/[id]`, `system/provenance`, `validation/go-to-market`, `validation/operations-readiness`, `validation/pricing`, `validation/product-market-fit`, `validation/solution` |
-| `(scale)` | How fast can we take the mass market? | `.release/venture-package`, `decisions`, `decisions/[id]`, `evidence`, `evidence/[id]`, `foundation/alignment`, `foundation/icp`, `foundation/telos`, `governance/decision-rights`, `governance/exit`, `governance/ownership`, `governance/pillar`, `governance/pillar/[id]`, `governance/publication-policy`, `knowledge/knowledge-sources`, `knowledge/venture-profile`, `knowledge/where-used`, `marketing/content`, `marketing/sitemap`, `operations/department`, `operations/handoff`, `operations/handoff/[id]`, `operations/site-presence`, `people/team`, `people/team-plan`, `product`, `product/[id]`, `product/anatomy`, `product/anatomy-answers`, `product/anatomy/[id]`, `purpose/account`, `purpose/account/[id]`, `system/provenance`, `validation/go-to-market`, `validation/operations-readiness`, `validation/pricing` |
-| `(platform)` | What will others build on, so the venture can't be displaced? | `.release/venture-package`, `decisions`, `decisions/[id]`, `evidence`, `evidence/[id]`, `foundation/alignment`, `foundation/icp`, `foundation/telos`, `governance/board`, `governance/decision-rights`, `governance/exit`, `governance/ownership`, `governance/pillar`, `governance/pillar/[id]`, `governance/publication-policy`, `knowledge/knowledge-sources`, `knowledge/venture-profile`, `knowledge/where-used`, `marketing/content`, `marketing/sitemap`, `operations/department`, `operations/handoff`, `operations/handoff/[id]`, `operations/site-presence`, `people/team-plan`, `product`, `product/[id]`, `product/anatomy`, `product/anatomy-answers`, `product/anatomy/[id]`, `purpose/account`, `purpose/account/[id]`, `system/provenance`, `validation/operations-readiness` |
+| `(discovery)` | Does a real problem exist, and who has it? | `.release/venture-package`, `decisions`, `decisions/[id]`, `foundation/alignment`, `foundation/icp`, `foundation/problem`, `ideas/graph`, `ideas/map`, `knowledge/venture-profile`, `people`, `people/founders`, `people/founders/[id]`, `product`, `product/[id]`, `raw/dump`, `system/provenance` |
+| `(validation)` | Will people adopt this solution and keep using it? | `.release/venture-package`, `decisions`, `decisions/[id]`, `evidence`, `evidence/[id]`, `foundation/alignment`, `foundation/icp`, `foundation/problem`, `foundation/telos`, `governance/decision-rights`, `governance/publication-policy`, `ideas/graph`, `ideas/map`, `knowledge/venture-profile`, `marketing/sitemap`, `operations/department`, `operations/handoff`, `operations/handoff/[id]`, `operations/site-presence`, `people`, `people/founders`, `people/founders/[id]`, `people/team`, `people/team-plan`, `product`, `product/[id]`, `raw/dump`, `system/provenance`, `validation/go-to-market`, `validation/pricing`, `validation/product-market-fit`, `validation/solution` |
+| `(beachhead)` | Can we win one segment repeatably, at a profitable cost? | `.release/venture-package`, `decisions`, `decisions/[id]`, `evidence`, `evidence/[id]`, `foundation/alignment`, `foundation/icp`, `foundation/problem`, `foundation/telos`, `glossary`, `glossary/[id]`, `governance/decision-rights`, `governance/pillar`, `governance/pillar/[id]`, `governance/publication-policy`, `knowledge/freshness-log`, `knowledge/venture-profile`, `marketing/brand`, `marketing/content`, `marketing/sitemap`, `operations/department`, `operations/handoff`, `operations/handoff/[id]`, `operations/site-presence`, `people`, `people/founders`, `people/founders/[id]`, `people/team`, `people/team-plan`, `product`, `product/[id]`, `product/anatomy`, `product/anatomy-answers`, `product/anatomy/[id]`, `public/assets`, `purpose/account`, `purpose/account/[id]`, `purpose/money/summary`, `system/provenance`, `system/release`, `validation/go-to-market`, `validation/operations-readiness`, `validation/pricing`, `validation/product-market-fit`, `validation/solution` |
+| `(scale)` | How fast can we take the mass market? | `.release/venture-package`, `decisions`, `decisions/[id]`, `evidence`, `evidence/[id]`, `foundation/alignment`, `foundation/icp`, `foundation/telos`, `glossary`, `glossary/[id]`, `governance/decision-rights`, `governance/exit`, `governance/ownership`, `governance/pillar`, `governance/pillar/[id]`, `governance/publication-policy`, `knowledge/freshness-log`, `knowledge/knowledge-sources`, `knowledge/venture-profile`, `knowledge/where-used`, `marketing/brand`, `marketing/content`, `marketing/sitemap`, `operations/department`, `operations/handoff`, `operations/handoff/[id]`, `operations/site-presence`, `people`, `people/founders`, `people/founders/[id]`, `people/team`, `people/team-plan`, `product`, `product/[id]`, `product/anatomy`, `product/anatomy-answers`, `product/anatomy/[id]`, `public/assets`, `purpose/account`, `purpose/account/[id]`, `purpose/money/summary`, `system/provenance`, `system/release`, `validation/go-to-market`, `validation/operations-readiness`, `validation/pricing` |
+| `(platform)` | What will others build on, so the venture can't be displaced? | `.release/venture-package`, `decisions`, `decisions/[id]`, `evidence`, `evidence/[id]`, `foundation/alignment`, `foundation/icp`, `foundation/telos`, `glossary`, `glossary/[id]`, `governance/board`, `governance/decision-rights`, `governance/exit`, `governance/ownership`, `governance/pillar`, `governance/pillar/[id]`, `governance/publication-policy`, `knowledge/freshness-log`, `knowledge/knowledge-sources`, `knowledge/venture-profile`, `knowledge/where-used`, `marketing/brand`, `marketing/content`, `marketing/sitemap`, `operations/department`, `operations/handoff`, `operations/handoff/[id]`, `operations/site-presence`, `people`, `people/founders`, `people/founders/[id]`, `people/team-plan`, `product`, `product/[id]`, `product/anatomy`, `product/anatomy-answers`, `product/anatomy/[id]`, `public/assets`, `purpose/account`, `purpose/account/[id]`, `purpose/money/summary`, `system/provenance`, `system/release`, `validation/operations-readiness` |

package/evidence/skills/fidelity-ladder-audit/ladder-census.mjs

@@ -15,6 +15,7 @@
 
 import { readdirSync, readFileSync, statSync, writeFileSync } from "node:fs";
 import { join, extname, basename } from "node:path";
+import { ventureFile } from "../../../schema/venture-paths.mjs";
 
 // ---------------------------------------------------------------- lexicons
 
@@ -59,7 +60,7 @@ const jsonOut = flag("json");
 function walk(dir, acc = []) {
   for (const entry of readdirSync(dir)) {
     if (entry === "node_modules" || entry.startsWith(".")) continue;
-    const full = join(dir, entry);
+    const full = ventureFile(dir, entry);
     const st = statSync(full);
     if (st.isDirectory()) walk(full, acc);
     else if (extname(entry) === ".tsx" && !/\.(test|spec|stories)\.tsx$/.test(entry)) acc.push(full);

package/governance/layer.json

@@ -72,7 +72,8 @@
     "founder-agreement",
     "exit",
     "publication-policy",
-    "decision-record"
+    "decision-record",
+    "venture-role"
   ],
   "reads": [
     "handoff",

package/governance/venture-template/roles/venture-roles.json

@@ -0,0 +1,62 @@
+{
+  "version": "0.1.0",
+  "note": "Roles a person can hold in a venture (EE-082). Agent roles are in agent-roles.json.",
+  "roles": [
+    {
+      "id": "founder",
+      "name": "Founder",
+      "kind": "builder",
+      "description": "Started the venture and owns it; alone, owns every function",
+      "founder": true,
+      "owns_when_solo": true
+    },
+    {
+      "id": "co-founder",
+      "name": "Co-founder",
+      "kind": "builder",
+      "description": "One of two or more founders; owns the functions the team assigns",
+      "founder": true,
+      "owns_when_solo": true
+    },
+    {
+      "id": "general-partner",
+      "name": "General partner",
+      "kind": "investor",
+      "description": "Runs a fund or firm: sets the thesis, raises from limited partners, makes and manages investments",
+      "founder": true,
+      "owns_when_solo": true
+    },
+    {
+      "id": "limited-partner",
+      "name": "Limited partner",
+      "kind": "investor",
+      "description": "Commits capital to a fund and receives reports; does not run it",
+      "founder": false,
+      "owns_when_solo": false
+    },
+    {
+      "id": "operator",
+      "name": "Operator",
+      "kind": "operator",
+      "description": "Runs one or more functions without founding the venture: an early employee or executive",
+      "founder": false,
+      "owns_when_solo": false
+    },
+    {
+      "id": "advisor",
+      "name": "Advisor",
+      "kind": "advisor",
+      "description": "Advises the founders; owns no function",
+      "founder": false,
+      "owns_when_solo": false
+    },
+    {
+      "id": "board-member",
+      "name": "Board member",
+      "kind": "governor",
+      "description": "Sits on the board and governs; owns no function",
+      "founder": false,
+      "owns_when_solo": false
+    }
+  ]
+}

package/interface/acting.mjs

@@ -0,0 +1,83 @@
+// Who is acting (M-18, like cookies in a Server Action) and access on every read (F-5). Every action
+// through the router carries who is acting, a person or an agent, and in which team-plan role. The
+// router checks it before anything else, on every call: the actor is a person or an agent, an agent
+// never acts in a role a person holds, and a venture can refuse role ids its team plan does not list
+// (naive.config.json acting.unknown_roles). Each answer carries `acting` back. When who is acting
+// changes between two calls on one interface, or the role's entry in the team plan changes, the next
+// answer carries `acting_changed` with the routes the new identity may reach: the re-render.
+//
+// Access (P-27) is checked again at the record: a list read returns only the items the role may read,
+// so a role allowed one product never sees the others. Credentials never enter here; connectors keep
+// them, and the platform's stay in platform/ (EE-041).
+
+import { AsyncLocalStorage } from "node:async_hooks";
+import { createHash } from "node:crypto";
+import { globsOf, mayReadItem, mayReadSome, roleOf, teamPlan } from "../schema/access.mjs";
+import { configFor } from "../schema/naive-config.mjs";
+
+export { mayReadItem, mayReadSome };
+
+/** Checks who is acting on a venture. Returns { ok, who: { kind, role, known, occupant } } or { ok: false, error }. */
+export function actingOf(dir, kind, roleId) {
+  const who = { kind, role: roleId ?? null };
+  if (kind !== "agent" && kind !== "person") return { ok: false, error: `the actor is a person or an agent, not ${kind}`, who };
+  if (!dir || !roleId) return { ok: true, who };
+  const plan = teamPlan(dir);
+  if (!plan) return { ok: true, who };
+  const role = (plan.roles ?? []).find((r) => r.id === roleId);
+  if (!role) {
+    let mode = "allow";
+    try { mode = configFor(dir).acting?.unknown_roles ?? "allow"; } catch {}
+    if (mode === "refuse") return { ok: false, error: `${roleId} is not a role in the team plan, and naive.config.json refuses unknown roles (acting.unknown_roles)`, who };
+    return { ok: true, who: { ...who, known: false } };
+  }
+  if (kind === "agent" && role.occupant === "person") return { ok: false, error: `${roleId} is a person's role in the team plan: an agent may not act in it`, who };
+  return { ok: true, who: { ...who, known: true, occupant: role.occupant } };
+}
+
+/** A fingerprint of who is acting: kind, role and the role's team-plan entry, so a changed entry counts as a change. */
+export function fingerprint(dir, who) {
+  return createHash("sha256").update(JSON.stringify({ kind: who.kind, role: who.role, entry: dir && who.role ? roleOf(dir, who.role) : null })).digest("hex");
+}
+
+/** The routes an identity may reach: globs to read and write. */
+export function reach(dir, roleId) {
+  const g = dir && roleId ? globsOf(dir, roleId) : null;
+  return g ?? { read: ["**"], write: ["**"] };
+}
+
+/** The id of a collection item from its file, given the collection's file patterns (products/*.json). */
+export function itemId(patterns, path) {
+  for (const g of patterns) {
+    if (!g.includes("*")) continue;
+    const m = path.match(new RegExp("^" + g.split("*").map((s) => s.replace(/[.+^${}()|[\]\\]/g, "\\$&")).join("([^/]*)") + "$"));
+    if (m) return m[1];
+  }
+  return path;
+}
+
+const nested = new AsyncLocalStorage();
+const last = new Map();
+
+/**
+ * Runs one router action with who is acting checked first and carried on the answer. inner is the
+ * router's own call; findDir finds a venture folder. Calls the router makes inside another call
+ * (a view's read, the overview's slots) are checked too, but only the outer call tracks changes.
+ */
+export async function actingCall(a, inner, findDir) {
+  const kind = a.actor ?? "agent", role = a.actor_id ?? process.env.MENTURA_ACTOR_ID;
+  let dir = null;
+  try { dir = a.venture ? findDir(a.venture, a.workspace) : null; } catch {}
+  const check = actingOf(dir, kind, role);
+  const acting = { kind, role: role ?? null };
+  if (!check.ok) return { ok: false, error: check.error, acting };
+  if (nested.getStore()) return { ...(await inner(a)), acting };
+  let changed = null;
+  if (dir) {
+    const key = `${dir}\0${a.via ?? "router"}`, fp = fingerprint(dir, check.who), prev = last.get(key);
+    if (prev && prev.fp !== fp) changed = { from: prev.acting, to: acting, may: reach(dir, role) };
+    last.set(key, { fp, acting });
+  }
+  const r = await nested.run(true, () => inner(a));
+  return { ...r, acting, ...(changed ? { acting_changed: changed } : {}) };
+}

package/interface/adapters/claude-code.json

@@ -0,0 +1,16 @@
+{
+  "name": "claude-code",
+  "title": "Claude Code",
+  "kind": "harness",
+  "integration": "claude-code",
+  "reads": ["CLAUDE.md", ".claude/skills/*/SKILL.md"],
+  "files": [
+    { "path": "CLAUDE.md", "text": "@AGENTS.md\n" }
+  ],
+  "skills": ".claude/skills",
+  "sources": [
+    "https://docs.claude.com/en/docs/claude-code/memory",
+    "https://docs.claude.com/en/docs/claude-code/skills"
+  ],
+  "note": "Claude Code reads CLAUDE.md, which imports the venture's AGENTS.md with @AGENTS.md, and loads project skills from .claude/skills/<name>/SKILL.md. The adapter copies the skill of each package open now, so the agent has the installed version's skill."
+}

package/interface/adapters/codex.json

@@ -0,0 +1,14 @@
+{
+  "name": "codex",
+  "title": "Codex",
+  "kind": "harness",
+  "integration": "codex",
+  "reads": ["AGENTS.md"],
+  "files": [],
+  "skills": null,
+  "sources": [
+    "https://agents.md/",
+    "https://github.com/openai/codex"
+  ],
+  "note": "Codex reads AGENTS.md natively, from the venture root down to the folder it works in, which is the layout chain Naive already writes. Nothing else is needed."
+}

package/interface/adapters/cursor.json

@@ -0,0 +1,16 @@
+{
+  "name": "cursor",
+  "title": "Cursor",
+  "kind": "harness",
+  "integration": "cursor",
+  "reads": ["AGENTS.md", ".cursor/rules/*.mdc"],
+  "files": [
+    { "path": ".cursor/rules/naive.mdc", "text": "---\ndescription: How to work in this Naive venture\nalwaysApply: true\n---\n\nRead AGENTS.md at the venture root, and the AGENTS.md of each folder down to the one you work in, before writing anything. Write records through the router (node interface/cli/mentura.mjs), never by editing files, and never read _private/.\n" }
+  ],
+  "skills": null,
+  "sources": [
+    "https://docs.cursor.com/context/rules",
+    "https://agents.md/"
+  ],
+  "note": "Cursor reads AGENTS.md and project rules in .cursor/rules/. The adapter adds one rule that always applies and points at the AGENTS.md chain."
+}