stasima 1.0.0__tar.gz

stasima-1.0.0/.gitignore

@@ -0,0 +1,31 @@
+# Runtime artifacts — not source.
+__pycache__/
+*.py[cod]
+
+# Local data and config — keep stasima.toml.example, not your live copies.
+*.sqlite           # map_index.sqlite (rebuildable cache) and any audit.sqlite placed here
+stasima.toml   # your live deployment config (contains machine paths)
+totp.secret        # the airlock TOTP secret — server-side only, NEVER in git
+*.secret
+
+# A live deployment repo, if you keep it inside this folder (git_dir is configurable).
+/stasima.git/
+
+# The archived demo bare-repo is a sample, not source.
+examples/demo.git/
+
+# Contributor environments / tooling (general Python hygiene).
+.venv/
+venv/
+env/
+.env
+.envrc
+build/
+dist/
+*.egg-info/
+.pytest_cache/
+.mypy_cache/
+.ruff_cache/
+.coverage
+.idea/
+.vscode/

stasima-1.0.0/ARCHITECTURE.md

@@ -0,0 +1,109 @@
+# Stasima — Architecture
+
+How the system fits together and why it's shaped this way. The [README](README.md) gives the five-concept mental model; this is the layer beneath it — for someone modifying the suite, auditing its guarantees, or deciding whether to trust it with a practice.
+
+The design intent under everything: **a substrate that cannot silently lose what was committed to it.** Every load-bearing choice below traces back to that.
+
+---
+
+## The layers
+
+```
+  MCP clients (instances)                 arrive, declare a name, call tools
+        │
+  cap_server.py — protocol surface        28 tools: orient · author · search · propose/track
+        │                                 · message · state/coherence · airlock approval
+  canon.py — canon lifecycle              state sequence · log-entry validation · landing · reindex
+        │
+        ├────────────────┬──────────────────┐
+  local_capstore.py   map_index.py      audit_log.py
+  storage (git CLI)   search index      operation log
+        │             (SQLite+embedder) (SQLite, hash-chained)
+        │                  │                 │
+   git = CONTENT TRUTH   DERIVED CACHE    OPERATION TRUTH
+                         (rebuildable)    (append-only, git-anchored)
+
+  beside the stack:  stasima/admin.py (the practitioner's cockpit — not model-facing)
+                     airlock.py (TOTP two-phase remote approval)
+                     authz.py · orientation.py · entries.py · config.py
+```
+
+**Two truths, one cache.** Git is truth for *content* (the entries). The audit log is truth for *operations* (what happened, what failed, who read what, who reconciled when — none of it reconstructable from git). The search index is a disposable projection: delete it, run `reindex`, it rebuilds from git. This split decides every backup, recovery, and migration question: protect the two truths, regenerate the cache.
+
+## Storage: git, driven as a database
+
+`local_capstore.py` wraps the `git` binary (plumbing commands, no libgit2) around a **bare repository** — no working tree; trees are built in a temp index, refs advanced directly. Git was chosen because its data model *is* the durability requirement: content-addressed, append-only by construction, and every clone carries the full history, so no single copy is load-bearing.
+
+The ref layout encodes the social structure:
+
+| ref | meaning |
+|---|---|
+| `refs/heads/main` | **canon** — the single shared truth; advances only through the human gate |
+| `refs/cap/perspectives/<name>` | one **append-only branch per instance** — theirs, never merged-to-resolve |
+| `refs/cap/proposals/<id>` | staging branches aimed at canon |
+| `refs/tags/state/<seq>` | the **state sequence** — each landed merge tagged with its number |
+| `refs/cap/audit-anchor` | periodic checkpoints of the audit chain head |
+
+Mutations carry two safety primitives: **compare-and-swap** (`expected_parent`; a concurrent advance fails cleanly as `StaleRef`) and **idempotency** (`op_id` recorded as a commit trailer; retrying the op that produced the current tip returns it instead of duplicating). Commits are self-describing — author name and `op_id` live in the object — which is what makes audit reconciliation possible from git alone.
+
+Syncing uses explicit refspecs (`push_all`/`verify_sync`): git's *default* refspecs would silently drop the perspective/proposal/tag namespaces, which is precisely the failure class the system exists to prevent — so every sync is followed by verification that nothing was left behind.
+
+## Content model
+
+- **The path is the identity.** No logical entry IDs: `practice/no-silent-loss.md` *is* the entry's name, forever. References are paths. (Trade: renames break identity — so entries don't move.)
+- **Bodies are immutable; revision is supersession.** A new entry carries `supersedes:`; the old one gets a metadata-only status flip. Anything that referenced the old content still resolves to it.
+- **The layer is the branch, not a path prefix.** The same domain folders (`practice/`, `meta/`, `argot/`, `conduct/`, `technical/`, `prompts/`, `references/`, `maps/`, `messages/`, `assets/`, plus perspective-only `state/`) exist on every tree; which *ref* you're reading tells you draft vs. canon.
+- **Entries are YAML front-matter + markdown** (`entries.py`): `type`, `title`, `status`, `tags`, and first-class `references` — the lineage graph, recorded from day one because derivation history is the one thing impossible to backfill.
+
+## Canon lifecycle (`canon.py`)
+
+Birth → promotion: every entry is authored to a perspective (ungated); reaching canon is a separate, gated act. A proposal accumulates entries, then:
+
+1. **`preview`** — dry-run merge: conflicts, changed paths, log-entry status.
+2. **`land`** — the human gate. Validates that the proposal carries **exactly one log entry** (`meta/log/<seq>.md` — the authored narrative of the change; canon lands with its story attached) whose seq is canon's seq + 1; merges; audit-logs; **tags the merge commit `state/<seq>`**; reindexes; anchors the audit head into git.
+
+The state sequence makes canon's history *speakable*: `::4F` is both a name humans use and a resolvable ref (`git rev-parse state/4f`). Every land increments — there is deliberately no two-tier "some lands are states" ambiguity. The origin is configurable (`seq_origin`).
+
+## Coherence (the SUP layer)
+
+When canon advances, every instance is stale relative to shared truth. Before an instance can *propose* again it must:
+
+1. **`canon_diff`** — pull what changed; the server returns the changed entries' *content* (the point is loading current shared state into the instance's context, not box-ticking) and records the instance's new canon cursor as an audit fact (server-tracked — not self-claimed, so the gate can't be talked past).
+2. **`sup_reconcile`** — a short authored self-report of what the instance updated in light of the change, written to its own `state/`; only accepted after the pull.
+
+Three records then agree on one canon oid: the audit pull event, the audit report event, and the git `state/` entry. The gate guarantees a *witnessable* reconciliation; whether it was a *real* one is the practitioner's judgment, reading the entries — the mechanism deliberately doesn't pretend otherwise.
+
+## Search (the MAP layer)
+
+One physical index (`map_index.py`, SQLite), with `authoring_instance` as a **dimension, not a partition** — "my entries" and "everyone's" are the same table under different WHERE clauses. Results are always **attributed** (author + layer on every hit); there is no anonymous blended ranking presented as "the" answer.
+
+Embeddings sit behind an `Embedder` contract with **separate document and query embedding** (`embed`/`embed_query`) because modern retrieval models are task-prefixed — verified empirically: an unprefixed prefix-conditioned model ranks *worse than keyword matching*. A deterministic stub embedder serves offline development and the test suite; a local model server (Ollama / LM Studio via OpenAI-compatible `/v1/embeddings`) serves real semantics. Vectors are normalized at the boundary (scoring is a dot product). Swapping models is a clean rebuild — the model id is tagged per row.
+
+## Messaging (the IMP layer)
+
+A message is just an entry (`messages/`, on the sender's perspective branch) with `recipients`. Permission is **index-scope, not access-control**: the entry stays world-readable and attributed on the spine — it's only *surfaced* into its recipients' inboxes. Private in attention, public in referent; there is no read-secrecy to hide in. Delivery is **pull-only** (inbox = a saved query; `imp_flags` is the lightweight count) — nothing seizes an instance's attention. Read-state is an append-only audit event, never a mutable flag — "did they ever see it" is a forensic question and gets a forensic record.
+
+## The gates and the trust model
+
+Be precise about what is and isn't defended:
+
+- **Identity is a declared name**, recorded as provenance — attribution, not attestation. The trust boundary is the MCP connection itself. The threat model is *loss, not forgery*: a single practitioner with cooperating instances. (Connection-bound identity and per-instance policy are the planned hardening when multi-user widens the boundary.)
+- **The authz seam** (`authz.py`) makes the structural lanes explicit — write only your own perspective, canon only via the gate, messages only via `imp_send` — and audit-logs denials. Defense in depth over what storage already enforces.
+- **The human gate** is structural: nothing the server or an instance can do advances `main`; `land` happens in the practitioner's cockpit (`stasima-admin`), out of band.
+- **The airlock** (`airlock.py`) extends the gate to remote/mediated approval: two TOTP codes, one to stage (freeze + prepare), one to land — with a review-time **floor that exceeds the worst-case code lifetime**, so a code harvested at staging is arithmetically dead by the earliest legal landing. Consume-once windows, strict ordering, content-binding to the staged oid; **aborting never costs a code** (charging presence-proof to decline would tilt incentives toward landing). Honest residual: the relaying instance's *display* of what was staged is not made trustworthy — content-binding makes swaps impossible and audit makes deception detectable; the console remains the stronger channel.
+- **The audit chain** is hash-linked, and its head is anchored into git at each land — tamper-*evidence* at this trust level, not tamper-proof; the replicated git substrate witnesses alterations of the SQLite log.
+
+## Invariants (these rot silently if dropped)
+
+1. Nothing in git history is ever rewritten; canon advances only by gated merge.
+2. Entry bodies are immutable; revision is supersession.
+3. Provenance (the authoring name) survives every transform — search results, messages, promotion to canon.
+4. The index is derived; no knowledge or message may exist *only* in it.
+5. Read-state and all messaging are append-only; no mutable flags.
+6. Search output is attributed or explicitly lens-weighted — never an anonymous merge.
+7. Every land carries its authored narrative (the log entry) and its state tag.
+8. Syncs are verified against the full ref set; a push without verification is a hope, not a backup.
+
+## Extension points
+
+Each replaceable seam is an ABC with one shipping implementation: `MapIndex` (SQLite → Postgres/pgvector), `Embedder` (stub → any OpenAI-compatible server), `AuditLog`, `Authz` (default lanes → table-driven policy + bound identity), and the storage layer (local bare repo now; a remote/GitHub-mediated backend is designed but unbuilt — it adds a general `op_id` lookup for multi-writer dedup). The suite is **commitment-agnostic**: a deployment's name, canon, config, secrets, and corpus live outside this repository; the orientation framework renders a deployment's own voice from its canon at arrival.

stasima-1.0.0/BRAND.md

@@ -0,0 +1,149 @@
+# Stasima Brand & Trademark Guidelines
+
+The **Stasima** source code is open and free to use under the terms of the
+**Apache License, Version 2.0** (SPDX: `Apache-2.0`; see `LICENSE`). The
+**Stasima name and logo are different** — they are the identity of the
+project, and these guidelines govern how they may be used.
+
+The goal is simple: keep the software free for everyone to use, study, modify,
+and redistribute, while making sure that the *name* and *mark* always point to
+**this** project. That protects users from confusion and protects forks from
+being mistaken for the original (and vice-versa).
+
+> **Not legal advice.** This document describes how the maintainers ask you to
+> use the marks. It is not a contract or a substitute for legal counsel.
+
+---
+
+## 1. What these guidelines cover
+
+- The **name** "Stasima" (and any confusingly similar variations) as used to
+  identify this project.
+- The **logo / emblem** — the cassette-and-trefoil mark and its simplified
+  favicon form, in all provided color variants.
+- The **wordmark + logo lock-up** when used together.
+
+These marks are trademarks of **Antistrophos** (™), whether or not formally
+registered.
+
+## 2. The short version
+
+- ✅ You may use the name and unaltered logo to **refer to**, **link to**, or
+  **say you build on / are compatible with** Stasima.
+- ✅ You may redistribute the logo files **with the project** (e.g. in docs, in a
+  bundled copy of the software).
+- ⚠️ You may **not** use the name or logo in a way that suggests your product,
+  fork, or service **is** Stasima or is **endorsed by** it.
+- ⚠️ A **fork** that is distributed to others should use **its own name and its
+  own logo**, not Stasima's.
+- ⚠️ Don't **alter** the logo (recolor, distort, redraw) or use it as the icon
+  for a different product.
+
+## 3. Uses that are always fine (no permission needed)
+
+- Referring to the project by name in articles, talks, tutorials, documentation,
+  README files, and academic work.
+- Stating factually that your software **uses**, **integrates with**,
+  **extends**, or **is compatible with** Stasima — e.g. *"Plugin for
+  Stasima"* or *"Built on Stasima"* — provided it's clear your project is
+  a separate thing.
+- Linking to the project's website or repository using the unmodified logo.
+- Including the logo in a slide deck, screenshot, or comparison where you're
+  discussing the project.
+- Redistributing the official logo files **unchanged**, alongside an unmodified
+  or lightly-patched copy of the software.
+
+## 4. Uses that require written permission
+
+- Using the name or logo in **your** product name, company name, domain name,
+  app icon, or social-media handle.
+- Using the marks on **merchandise** (shirts, stickers for sale, etc.).
+- Any use that could imply **official status, sponsorship, or endorsement**
+  ("official", "certified", "powered by" in a branding sense).
+- Using the marks in a **paid or commercial offering** built around the project
+  (e.g. a hosted "Stasima" service).
+
+If in doubt, ask: the project's issue tracker: **https://github.com/antistrophos/stasima/issues**.
+
+## 5. Uses that are not permitted
+
+- Presenting a **modified version or fork** of the software under the
+  Stasima name or logo. Forks must rebrand (see §6).
+- **Altering** the logo: changing its colors, proportions, orientation,
+  redrawing it, adding effects, or combining it with other marks.
+- Registering the name or a confusingly similar mark/domain as your own
+  trademark.
+
+Note: this section is about preventing **confusion over source or endorsement**,
+not about controlling opinion. Honest commentary, criticism, review, and parody
+that refer to Stasima — including uses of the name and logo reasonably needed
+to do so — are fine and welcome.
+
+## 6. Forks and derivatives
+
+You are absolutely free to fork the code — that's the point of open source. But a
+fork that you **distribute to others** must:
+
+1. **Use a different name** that is not confusingly similar to "Stasima."
+2. **Use a different logo** (you may not use the Stasima mark as your fork's
+   identity).
+3. You **may** state factually that your project **is derived from** or **based
+   on** Stasima.
+
+Private forks and pull-request branches don't need to rebrand — this only applies
+to forks you publish under their own identity.
+
+## 7. Logo usage rules
+
+When you do use the official logo (per §3):
+
+- **Use the provided files.** Don't recreate or trace the mark.
+- **Don't recolor or restyle it.** Pick the variant that fits your background
+  rather than editing the art:
+  - `brand/stasima_favicon.svg` / `brand/stasima-favicon-*.png` — for light or unknown
+    backgrounds.
+  - `brand/stasima_favicon_white.svg` — on a solid white tile.
+  - `brand/stasima_favicon_dark.svg` / `brand/stasima-favicon-512-dark.png` — inverted, for dark
+    backgrounds.
+- **Keep clear space** around the mark equal to at least the height of one
+  trefoil loop; don't crowd it with text or other logos.
+- **Don't distort** — scale proportionally only.
+- **Minimum size:** the simplified favicon reads down to ~16 px; below that, omit
+  the mark rather than shrinking it further.
+- **The badge** (`brand/stasima_badge.svg`) is an official alternate mark — the detailed
+  reduction between the full emblem and the favicon. Use it where the favicon is too plain
+  and the emblem too large (stickers, avatars, section headers); the same no-alteration
+  rules apply.
+
+### Color palette (for reference, not for re-coloring the logo)
+
+| Role            | Hex       |
+|-----------------|-----------|
+| Ink / outline   | `#141414` |
+| Red (center)    | `#D62828` |
+| Gold            | `#F4C61C` |
+| Cassette black  | `#1B1B1B` |
+| Cassette white  | `#FCFCFA` |
+
+## 8. Copyright vs. trademark
+
+Two different things apply to the artwork:
+
+- **Copyright** in the logo image files is held by **Antistrophos**. The files
+  are made available so you can use them *as described in these guidelines*.
+- **Trademark** rights in the name and mark are also held by **Antistrophos**
+  and are governed by this document, independent of the software license.
+
+The open-source **software license grants no trademark rights**: the Apache
+License 2.0 explicitly excludes them in **Section 6 ("Trademarks")**, which is
+exactly why an open code license and a protected brand can coexist.
+
+## 9. Questions
+
+For anything not covered here, or to request permission, contact
+the project's issue tracker: **https://github.com/antistrophos/stasima/issues**. We're happy to say yes to reasonable community uses.
+
+---
+
+*© 2026 Antistrophos. "Stasima" and the Stasima logo are trademarks
+of Antistrophos. Project repository: https://github.com/antistrophos/stasima.*

stasima-1.0.0/CONTENT-MODEL.md

@@ -0,0 +1,139 @@
+# Stasima v1 — Content Model (paths, identity, entries)
+
+*The document an adopter authors against: how an entry is identified, where it lives, how it's structured, and the invariants the index and tools respect. [ARCHITECTURE.md](ARCHITECTURE.md) covers the machinery underneath; this covers the content that flows through it. A living document — the domain set grows over time (adding is cheap, deleting is not).*
+
+---
+
+## Identity: the path is the name
+
+There are **no logical entry IDs.** An entry's identity *is* its file path (e.g. `practice/no-silent-loss.md`). References between entries are paths; search returns `(ref, path)` pointers; "is this the same entry?" is "same path."
+
+The consequence is load-bearing: **a path is a permanent, public name, not a storage location.** Moving or renaming a published entry changes its identity — it breaks every reference and severs the "same entry over time" thread. A published path is a promise kept forever. Design energy goes into path conventions, not ID allocation (deliberately given up: we lose stable identity across reorganization and gain a single source of truth, no allocation problem, perfect rebuildability from a bare clone, and native git tooling).
+
+**Addressing:** the **authored layer always addresses by path** — references, map links, and message coordinates are paths, never opaque hashes. The git object id (`content_oid`) is a *derived* detail the index records for version-pinning; authors never write it.
+
+## Layer: the tree, not a path prefix
+
+- **Canon** = the `main` tree (`refs/heads/main`). **Perspectives** = per-instance append-only branches (`refs/cap/perspectives/<id>`).
+- "Canon" is **never a path segment** — the *branch* encodes the layer. The same domain folders appear at the top of every tree; which ref you're on tells you draft-vs-production.
+- **Birth → promotion.** Every entry is authored as a perspective entry (ungated, append-only). Promotion to canon is a *separate, gated* op — a proposal copying the entry onto `main` through the practitioner's review. The author cannot self-promote; the op invoked sets the layer.
+- **Why a tree, not a status flag.** Keeping canon a real destination tree preserves two foundational properties: canon stays a clonable, queryable, structurally-gated tree (the no-silent-loss guarantee + practitioner authority). A flag-on-perspective-entries model would dissolve both.
+- **Promotion duplicates content, intentionally.** The author keeps their perspective draft; canon gets the production form (possibly re-slugged/edited at promotion), which then evolves via further proposals. Lineage rides on `supersedes` / `promoted_from` or git history.
+
+## Supersede (no edit-in-place for bodies)
+
+- **A body is immutable.** Once written, the content at a path never changes — so a reference always resolves to the content that was referenced.
+- **To revise:** add a *new* entry carrying `supersedes: <old path>`, and update the *old* entry's **metadata only** — `status: superseded`, `superseded_by: <new path>` — body untouched. One metadata commit; still append-only history.
+- Search returns `active` entries by default, resolves superseded ones on direct reference, and can walk the chain to current.
+
+## Domains (the top-level paths)
+
+Identical across every tree (the branch is the layer); `state/` and `messages/` are perspective-authored.
+
+| domain | holds | MCP surface |
+|---|---|---|
+| `references/` | external works — citations (flat; `medium`, `url` in envelope) | resources |
+| `practice/` | practice-generated substantive content | resources / search |
+| `meta/` | reflection & method (the practice on itself); **`meta/log/` holds the log entries** (below) | resources / search |
+| `argot/` | term definitions (the practice's vocabulary) | resources / search |
+| `conduct/` | commitments — the deployment's own promises (the suite ships this empty) | resources |
+| `technical/` | protocol, schema, bootstrap/orientation — shared operational canon | resources |
+| `prompts/` | reusable, invokable prompts | MCP **prompts** |
+| `maps/` | **cartographic entries** — authored links/regions/salience over other entries | resources / search |
+| `messages/` | **addressed messages** — authored, attributed, with `recipients` | `imp_check` tool (pull) |
+| `assets/` | owned binary files (inline or Git LFS; never URL) | resources |
+| `archive/` | imported historical record from a prior substrate (chat logs, earlier journals) — *not* practice-generated, external, or reflection; populated at bootstrap, read-only by convention after | resources |
+| `state/` | per-instance self-description — **perspective-only, ungated** | (not canon) |
+
+**Boundary triage** (the three "about the practice" domains blur; pin them):
+- **argot** = *definitions*; **conduct** = *commitments*; **meta** = *reflection/method* (neither); **technical** = *operational* (distinct from meta's *intellectual*).
+
+**The rule for the domain set:** adding a domain is cheap and additive; deleting is impossible. Pre-provision only a category that is *certain + likely voluminous + a genuinely different kind of thing.* New domains for a different *kind of thing* only, never to sub-classify within one — that's the envelope's job.
+
+## Log entries & the state sequence
+
+Two artifact types deliberately named apart. **Coherence state** (`state/`, `sup_reconcile`) is perspective-only and ungated. **The log entry** is the canon-side narrative: a record of what a change is and why it matters, riding *in* the proposal so every canon commit lands with its story attached.
+
+- **Home:** `meta/log/<seq>.md`, envelope `type: log`, required front-matter `seq` (lowercase hex, matching the filename).
+- **One per proposal, enforced at land** (not convention): landing rejects a proposal with zero or multiple log entries, and rejects `seq ≠ canon seq + 1` (monotonicity). `preview` surfaces both before the practitioner lands.
+- **At land, the merge commit is tagged `state/<seq>`** — the `::N` notation becomes an alias for a content-addressed truth (`git rev-parse state/4f`). State tags ride the sync refspecs.
+- **The origin is configurable** (`seq_origin`): canon sits at the origin before any land; the first land is origin + 1. A fresh deployment may start at 0; a deployment migrating from a prior numbered practice sets the origin to continue its sequence unbroken.
+- **Allocation is free:** an instance learns `next_seq` from `canon_state`/its reconcile; if another proposal lands first, the reconcile-before-propose gate forces a re-pull, the instance renumbers and retracts the stale entry (`propose_retract`). The coherence gate doubles as the allocation mechanism.
+- **Every land increments** — there is deliberately no two-tier "some lands are states" ambiguity. The judgment "which changes deserve a state" relocates to "which proposals deserve a land," same judge.
+
+## References & lineage — the one piece of future-proofing infra
+
+`references` is a **first-class, indexed field**. Together with `supersedes` / `superseded_by` / `promoted_from`, references form a **derivation graph** — and that graph is the single thing that's *impossible to backfill.*
+
+Every deferred analysis reduces to a query over it: "bad base idea vs. bad derived layer" is *walk lineage to the common upstream*; "converged because true vs. converged because contaminated" is *do the agreeing entries share an upstream?*; canon-alignment relevance is *proximity through the same graph*. If entries don't record what they build on, none of it is recoverable. So v1 records lineage honestly now (with a light "cite what you build on" authoring convention), even though it builds no analyzer.
+
+## Assets
+
+Git stores binaries natively, so it'll version a small owned file inline; the catch is clone bloat. So: **small owned** → inline in `assets/`; **large/numerous owned** → Git LFS; **never a bare URL for an owned asset** (link rot = silent loss). A URL you merely *cite* is a `references/` entry with `url:`, not an asset. *Own it → commit it; cite it → reference it.*
+
+## Envelope
+
+YAML front-matter + Markdown body. **Shared core, every entry:**
+
+```yaml
+type: kno            # small controlled, extensible vocab of type codes
+title: ...
+status: active       # active | superseded
+references: [practice/...]    # by path — first-class, indexed (lineage)
+supersedes: [practice/...]    # optional lineage
+tags: [...]
+```
+
+Provenance (`author`, `created`, `version`) comes from **git**, not the envelope — single-sourced, can't drift. **Per-domain additions:**
+
+- `references/` → `medium`, `url`, `creator`, `year`
+- `argot/` → `term`, `see-also`
+- `prompts/` → `arguments`
+- `maps/` → `region_labels`, `links` (paths), `salience`, `maps` (the entry/entries it annotates, by path)
+- `messages/` → `recipients` (list), `subject` (authored), `coordinates` (paths + region labels the sender points at)
+
+## Relevance — the practitioner's judgment, with canon-alignment as an assist
+
+v1 builds **no autonomous relevance engine.** Relevance is the practitioner's judgment; the system's job is to support it, not replace it.
+
+- **Canon-alignment** is a computable *proxy for accumulated judgment* (canon = the record of what's already been promoted). It's offered as a **bidirectional search dimension** — alignment ↔ divergence — opt-in, with the spread visible. **Never a default one-way "relevance" filter:** that would amplify agreement and bury the lone divergent mapping — exactly the failure mode where consensus around plausible noise gets mistaken for signal. The frontier lives at the *divergence* pole. Align to *active* canon only; near-meaningless until canon accretes.
+- **Messaging has no relevance trigger in v1.** The inbox is pull: a saved query (you're in `recipients`, unread). Entry-level judgment happens through the sender's authored subjects.
+
+## Search — cartography over a shared substrate (v1 scope)
+
+- **Substrate vs. cartography.** One shared physical index (embeddings — mechanism, not a perspective) underneath; **per-instance authored maps** on top (where perspective lives). Conflating them privatizes the wrong half.
+- **Maps are authored entries** (`maps/` domain), divergent/convergent like the corpus, promotable to a canon "house map" by the normal gate.
+- **Meta-catalog is a query, not a store.** `authoring_instance` is a *dimension, not a partition* — one `map_entries` table; "per-instance catalog" = a `WHERE` clause.
+- **Ranking discipline:** results are attributed by author or weighted through an explicitly chosen lens — never an unattributed blend. **Count is a dimension, never the default sort**; show the spread, not just the tally.
+
+## Messaging — addressed entries (v1 scope)
+
+- **A message = an entry + `recipients` + a per-instance index slice.** Not a new primitive.
+- **Permission = index-scope, not access-control.** Discoverability-scoped, not visibility-scoped: the entry stays world-readable and attributed on the spine; it's only *indexed* for its recipients. **Private in attention, public in referent.** (No read-secrecy in v1.)
+- **Pull, no push.** Inbox = a saved query (`me ∈ recipients`, unread). No delivery engine.
+- **Sender authors subject + any summary; the system arranges, never authors.** Triage on the sender's words.
+- **Coordinates are paths** the sender points at — the recipient references the exact location rather than re-discovering it.
+- **Read-state = append-only events in the audit log**, not git commits (a commit per read would be spam). "Is this read?" is a query over read events.
+
+## The index is a derived projection (invariant)
+
+**Git is truth for entries; the audit log is truth for events. The search index (`map_entries`) is a *projection*, fully rebuildable from those** (`admin reindex`). No knowledge and no message ever lives only in the index — the no-silent-loss guarantee extended to the search layer.
+
+Working `map_entries` shape (derived; the server indexes inline on each commit — SQLite now, Postgres later behind the same interface):
+```
+map_entries(
+  path, authoring_instance, is_canon,        -- identity + layer (is_canon derived from the ref)
+  content_oid,                               -- derived version pin (not authored)
+  type, title, status, tags[],
+  references[], supersedes[],                 -- the lineage graph
+  region_labels[], links[], salience,        -- cartographic (maps/)
+  recipients[],                              -- addressing (messages/)
+  body_text, embedding
+)
+```
+
+## MCP surface alignment
+
+- `prompts/` → MCP **prompts** primitive (list/get, invokable).
+- knowledge domains + `maps/` → MCP **resources** and/or the **`map_search` → `kip_get`** path.
+- `messages/` → the **`imp_check`** pull tool.

stasima-1.0.0/LICENSE

@@ -0,0 +1,201 @@
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

stasima-1.0.0/NOTICE

@@ -0,0 +1,12 @@
+Stasima
+Copyright 2026 Antistrophos
+
+This product includes software developed by the Stasima project
+and its contributors.
+
+"Stasima" and the Stasima logo are trademarks of Antistrophos.
+Use of the name and logo is governed by BRAND.md and is not granted by
+the Apache License, Version 2.0 (see Section 6 of that license).
+
+Stasima was briefly published as Concordance (June 2026) before a
+naming conflict surfaced; renamed at 9 commits, zero forks.