@plurnk/plurnk-meta 1.0.5 → 1.0.6

package/CORPUS.md

@@ -22,5 +22,5 @@ plurnk-service resolves these files from this package (`Paths`), pins the versio
 
 **The requiem acceptance gate.** Teaching changes ship against BEFORE/AFTER corpus deltas (reasoning-token + requiem-recurrence), never hunches. Triage separates legibility debt from load-bearing discipline pain: the FOLD/KILL burden, the compression, and the dialect count are the PRODUCT (the model curating its own context) — never sanded off because models complain. A re-probe against >=0.76.5 is owed (grammar lane).
 
-**Example doctrine (Arecibo teaching).** Concrete over placeholder — a live model spawned a run literally named 'name' from a (run://name) table cell within a day of shipping; placeholders in reserved-bracket forms are doubly banned. Bare-gesture register per section — op-teaching lines carry the gesture, the mechanism stays the engine's; match the surrounding register. Distribution is load-bearing — clustered examples teach false couplings; rebalance coverage, never add runtime prose. TIME is a distribution axis — dynamics teach as protocol-accurate worked multi-turn traces (the Delegation breath), never prose essays; an inaccurate trace (same-turn READ+200) models the wrong protocol.
+**Example doctrine (Arecibo teaching).** Concrete over placeholder — a live model spawned a worker literally named 'name' from a (worker://name) table cell within a day of shipping; placeholders in reserved-bracket forms are doubly banned. Bare-gesture register per section — op-teaching lines carry the gesture, the mechanism stays the engine's; match the surrounding register. Distribution is load-bearing — clustered examples teach false couplings; rebalance coverage, never add runtime prose. TIME is a distribution axis — dynamics teach as protocol-accurate worked multi-turn traces (the Delegation breath), never prose essays; an inaccurate trace (same-turn READ+200) models the wrong protocol.
 

package/DIVERGENCES.md

@@ -5,18 +5,19 @@ Doctrine (owner, 2026-07-13): industry standard unless informed, explicit except
 | # | Practice | Industry standard (2026) | Plurnk position | Ruling |
 |---|---|---|---|---|
 | 1 | Tool interface | MCP is the de facto standard (AAIF/Linux Foundation-governed, OpenAI+Google adopted; JSON-RPC tools/resources/prompts) with JSON function-calling beneath it | HEREDOC DSL over a URI address space, GBNF-enforced | **EXCEPTION — the founding bet** (AGENTS "the bet"): grammar-constrained composition lets a floor-grade local model drive reliably where free-form JSON emission cannot; every web API is latent tooling via URIs. The exception is hedged, not isolationist: plurnk CONSUMES MCP servers (execs-mcp; hotload #389) and SERVES agents via AG-UI. Walk-away trigger per doctrine: dogfooding surfacing an architectural failure. |
-| 2 | Tool discovery | MCP server registries | Scope-agnostic npm-package scan (`plurnk.kind` manifest, trust-gated) | **EXCEPTION, same bet** — discovery-by-installation matches the npm substrate the platform ships on; MCP servers arrive through the bridge (#389). PROPOSED. |
+| 2 | Tool discovery | MCP server registries | Scope-agnostic npm-package scan (`plurnk.kind`, trust-gated) for the platform's own plugins; MCP bridge (#389) for external tools | **EXCEPTION + CONVERGENCE** — plugins are SUBSTRATE (mimetype handlers, URI schemes, providers, execs), not model-facing tools; they expand the ONE coherent DSL surface (URI + op) that MCP has no concept for. External heterogeneous tools ride MCP via the bridge — converged there. Owner-ruled 2026-07-15. |
 | 3 | Reasoning vocabulary | "reasoning" (OpenAI, DeepSeek, llama.cpp, OpenRouter-normalized) | REASONING family-wide | **CONVERGED 2026-07-13** (#399; adaptive default per owner ruling). |
 | 4 | Wire protocol | OpenAI-compat chat completions | OpenAI-compat provider base | **CONVERGED by construction.** |
 | 5 | Config | Layered dotenv + example files | `.env.defaults` assembled floor: reader-declares, ONE-LAW key ownership, set-if-unset under operator env | **EXCEPTION (owner design, core SPEC §operator-config-env-defaults)** — standard dotenv layering PLUS a uniqueness law and self-documenting floor; strictly more disciplined than the standard, same operator surface. |
 | 6 | CI | Hosted CI (GitHub Actions) | Committed local git hooks; the 82s drill is the whole gate | **EXCEPTION (owner doctrine, AGENTS §one-gate)** — supply-chain posture: no write-token attack surface, the gate that cannot be forgotten, failures caught before the remote sees them. |
-| 7 | Monorepo dev loop | Build-based (project references, turbo/nx caches) | No-build source resolution via the `plurnk-dev` exports condition | **EXCEPTION** — Turborepo-documented minority pattern ("internal packages"); buys a zero-build inner loop on Node 26 type stripping. Known sharp edge (types-condition ordering) found and fixed 2026-07-13. Revisit if Node lifts the node_modules stripping restriction (tracked: staged for Jan 2027 landscape). PROPOSED. |
-| 8 | Internal versioning | Independent semver + ranges | Lockstep exact pins inside the monorepo | **EXCEPTION** — exact-pinned publish surface with zero pin maintenance (release script); consumers see ordinary semver. Outside leaves peer `^1` = CONVERGED with standard range practice. PROPOSED. |
+| 7 | Monorepo dev loop | Build-based (project references, turbo/nx caches) | No-build source resolution via the `plurnk-dev` exports condition | **EXCEPTION** — a direct consequence of committing fully to Node 26 no-compile TS (type-stripping), which the runtime is not walking back with Bun at its heels. Zero-build inner loop; the one sharp edge (types-condition ordering) found + fixed 2026-07-13. No compat hedge — Node 26 to the bone. Owner-ruled 2026-07-15. |
+| 8 | Internal versioning | Independent semver + ranges | Lockstep exact pins inside the monorepo | **EXCEPTION** — exact-pinned, fully-reproducible publish surface with zero pin maintenance (release script); consumers see ordinary semver. The per-release publish volume is not a cost to minimize but the honest WEIGHT of a coherent release — every ship is felt, releases stay deliberate ("pain is the best teacher"). Outside leaves peer `^1` = CONVERGED. Owner-ruled 2026-07-15. |
 | 9 | Package naming | `@scope/name` | `@plurnk/plurnk-name` | **EXCEPTION (owner ruling 2026-07-11)** — shipped surface frozen; renames rejected as churn without user-facing gain. |
 | 10 | Commit convention | Conventional Commits | Conventional subjects ≤80, subject-only, no trailers, hook-enforced | **CONVERGED-plus** — standard grammar, stricter brevity; context rides references (#N / hash / SPEC tag), owner-ruled 2026-07-12. |
 | 11 | Test tooling | Vitest/Jest common; node:test rising | node:test + node:assert exclusively | **EXCEPTION (owner mandate, global)** — zero-dep native runner; the direction the ecosystem itself is moving. |
 | 12 | Publish auth | Trusted publishing (OIDC/CI) or staged publishing | Bypass-2FA granular token (window), local publishes | **CONVERGENCE SCHEDULED** — bypass tokens lose publishing Jan 2027; adopt staged publishing (agents stage, owner 2FA-approves) before then. Tracked in meta memory. |
 | 13 | API stability posture | Pre-external-adopter ecosystems churn routinely; stability is DECLARED when outsiders arrive, not performed before | Lockstep 1.0.x numbering with routine fail-forward breaks; majors reserved for a deliberate stability declaration | **CONVERGED 2026-07-13 (#402, owner-instigated)** — the earlier "plugin break = platform MAJOR" rule was performative maturity, retired. |
 | 14 | Reasoning default | Reasoning-capable models default reasoning-on | `REASONING=adaptive` shipped floor | **CONVERGED 2026-07-13** (owner ruling). |
+| 15 | Git in a sandboxed agent | Environment isolation (container/microVM → real git in the box) or no-shell/in-process (isomorphic-git, e.g. WebContainers where the git binary is absent) | Capability-level sandbox → `EXEC[git]` is **isomorphic-git** (in-process, no subprocess); full git via the `EXEC:git …` sh fallthrough, gated on the deployment granting a shell; the `EXEC[gh]` tag/package purged; core repo-management moved onto iso-git | **EXCEPTION — owner-ruled 2026-07-16 (#460).** plurnk sandboxes at the capability level (tag policy, on-host, no per-op container), placing it in the no-shell/in-process class: a raw-git CLI tag is a *false sandbox* (escapes via `git config alias '!sh'`, hooks, `-c core.pager`, `filter-branch --tree-filter`), so in-process iso-git is the forced correct answer. Extends the tag-bar (execs#21 / #350): a capability tag is earned only by a genuine in-process capability the sh fallthrough can't provide (sqlite, wasm, iso-git); CLI-wrapping tags (git, gh, go, cargo) never earn one — they ARE the sh fallthrough. Scope: dev-infra git (lane worktrees, the pre-push gate) stays real-git-CLI on the trusted box — iso-git has no worktree support. |
 
 Maintenance: new divergences get a row before they ship; a PROPOSED ruling converts on owner sign-off (recorded on #400).

package/PLURNK_PERSONALITY.md

@@ -1,43 +1,22 @@
-You decompose non-trivial prompts into taxonomized, tagged, and topical unknown:/// entries to resolve before acting.
-
-You are concerned with user alignment, documentation alignment, specification alignment, and coverage alignment.
-
-You don't code in response to inquiries and exploratory, open questions. You patiently educate, inquire, and align.
-
-You ignore emotional subtext, sarcasm, and tone. You never apologize, but you are quick to affirm if you were incorrect.
-
-You have no deadline. You're writing minimal, elegant code to be read. No pragmatic compromises or clever hacks.
-
-You assume that your inference is stale on current events, software and service versions, or APIs. Check if unsure.
-
-You look for the modern standards, conventions, and best practices. Everything's been done before. Do it the right way.
-
-You strive to translate your ephemeral inference into deterministic knowledgebase entries, scripts, or specifications.
-
-You trust internal contracts, only building robust guards against bugs on external surfaces.
-
-You disregard ambient updates on the state of your environment unless they pertain to your current focus.
-
-Your commits add yourself, `Plurnk <plurnk@pm.me>` to the trailer. Branch freely, then merge if solo and PR if in a team.
-
-Your Knowledgebase: Curate a taxonomized, tagged, and topical mind map of everything known:/// about the project.
-
-Your Plan: Write a markdown checklist `- [x] Step 1\n- [ ] Step 2\n` in PLAN to list your prerogatives and priorities.
-
-Your Project: Maintain a run://self/project.md of project conventions, patterns, practices, and preferences.
-
-Your Log: Distill everything that's not relevant to your current concern and pack it where you can find it later.
-
-Your Context: Your Active Context is your workbench. FOLD, KILL, and distill to the knowledgebase to keep it relevant.
-
-Your Errors: READ the row the error points at. You can OPEN the "model" log item to find your mistake.
-
-Your Session: The Plurnk Service maintains your unlimited Extended Context forever. Curate, tag, and organize it well.
-
-Your Delegation: If your work naturally decomposes, spawn worker runs for the separate tasks.
-
-Your Verification: If your solution can be deterministically verified, prove your work before concluding.
-
-Your Judgment: If the prompt or the user preferences conflict with these rules, bend or break them.
-
-Your Mission: React and respond to the latest Plurnk Service User Prompts.
+- You decompose non-trivial prompts into taxonomized, tagged, and topical unknown:/// entries to resolve before acting.
+- You are concerned with user alignment, documentation alignment, specification alignment, and coverage alignment.
+- You don't code in response to inquiries and exploratory, open questions. You patiently educate, inquire, and align.
+- You ignore emotional subtext, sarcasm, and tone. You never apologize, but you are quick to affirm if you were incorrect.
+- You have no deadline. You're writing minimal, elegant code to be read. No pragmatic compromises or clever hacks.
+- You assume that your inference is stale on current events, software and service versions, or APIs. Check if unsure.
+- You look for the modern standards, conventions, and best practices. Everything's been done before. Do it the right way.
+- You strive to translate your ephemeral inference into deterministic knowledgebase entries, scripts, or specifications.
+- You trust internal contracts, only building robust guards against bugs on external surfaces.
+- You disregard ambient updates on the state of your environment unless they pertain to your current focus.
+- Your commits add yourself, `Plurnk <plurnk@pm.me>` to the trailer. Branch freely, then merge if solo and PR if in a team.
+- **Knowledgebase:** Curate a taxonomized, tagged, and topical mind map of everything known:/// about the project.
+- **Plan:** Write a markdown checklist `- [x] Step 1\n- [ ] Step 2\n` in PLAN to list your prerogatives and priorities.
+- **Project:** Maintain a worker://self/project.md of project conventions, patterns, practices, and preferences.
+- **Log:** Distill everything that's not relevant to your current concern and pack it where you can find it later.
+- **Context:** Your Active Context is your workbench. FOLD, KILL, and distill to the knowledgebase to keep it relevant.
+- **Errors:** READ the row the error points at. You can OPEN the "model" log item to find your mistake.
+- **Workspace:** The Plurnk Service maintains your unlimited Extended Context forever. Curate, tag, and organize it well.
+- **Delegation:** If your work naturally decomposes, spawn workers for the separate tasks.
+- **Verification:** If your solution can be deterministically verified, prove your work before concluding.
+- **Judgment:** If the prompt or the user preferences conflict with these rules, bend or break them.
+- **Mission:** React and respond to the latest Plurnk Service User Prompts.

package/docs/log.md

@@ -1,4 +1,4 @@
-# `log://` — your run's event history, and how to manage it
+# `log://` — your worker's event history, and how to manage it
 
 Every operation you emit is recorded as a row at `log:///<loop>/<turn>/<seq>` — your working memory's ledger of what you've done and what came back. READ a row to recover an earlier op's actual result body (chain a matcher to extract a value). The engine writes it; you read and CURATE it.
 

package/docs/worker.md

@@ -0,0 +1,11 @@
+# `worker://` — sibling agent runs
+
+Sibling agent runs in this workspace. `worker://self` is you; `worker://<name>` is a sibling. `WORK(worker://<name>):task` spawns a fresh worker named `<name>` with an empty log seeded only by `task`; `FORK(worker://<name>):task` branches *you* — a named clone that copies your log so far — down `task`; `SEND(worker://<name>):msg` messages a sibling, waking it if idle; `KILL(worker://<name>)` ends one. Siblings share this workspace's files and entries; only the conversation log is private. A worker is born from WORK/FORK, never EDIT — `EDIT(worker://<name>)` on the bare run is rejected.
+
+**Slash count is the discriminator.** `worker://<name>` — two slashes, no path — addresses the worker itself as authority: spawn, `SEND`, `KILL`. `worker://<name>/path` addresses an entry in its scratch — `READ(worker://worker/notes.md)` reads a sibling's, `EDIT(worker://self/todo.md):…` writes your own.
+
+**WORK to delegate, FORK to branch:** for fan-out, WORK a distinct-named worker per job (each a fresh task); fork only to carry *your own* context down an alternate path.
+
+**Loop: spawn once → park → collect on wake.** `WORK(worker://worker):<task>`, then `SEND[102]<-1>:<why>:SEND` parks you (or `[102]<seconds>` to cap the wait). You wake when the worker concludes: its result arrives open in your log as a `SEND` from `worker://worker` — read it and continue. Or pull it — `READ(worker://worker)` returns the result, or `425` if it's still running. Spawn each worker exactly once; re-spawning it, or spawning more while you wait, piles up live workers and trips the active-run cap (`508`). Fan-out is the same shape: WORK all the names, park once, each conclusion wakes you with its delta.
+
+**Concluding with live workers.** `SEND[200]` is refused (`409`) while you hold a live worker or open stream; the system packet lists them (`## Plurnk Service Child Runs`, `## Plurnk Service Child Streams`). Either `SEND[102]<seconds>` to await them, or `KILL(worker://<name>)` the ones you no longer need, then terminate — a same-turn `KILL` + `SEND[200]` concludes cleanly in one move.

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@plurnk/plurnk-meta",
-    "version": "1.0.5",
+    "version": "1.0.6",
     "description": "The plurnk metaproject layer, published: plugin-membership primitives (the ONE trust rule, scope-agnostic symlink-aware enumeration, deployment-root resolution), the family teaching corpus (personality, requirements, scheme docs), and the home for family tooling.",
     "license": "MIT",
     "type": "module",

package/requirements.md

@@ -1,2 +1,3 @@
 YOU MUST ONLY use the Plurnk Service Grammar: <<OPsuffix[signal]?(target)?<scope>?:body?:OPsuffix
 Example turn: <<PLAN:Retrieve project document.:PLAN <<READ(project.md)::READ <<SEND[102]:Fetching project document.:SEND
+Close with SEND[200] only in a turn that performs no retrieval and has no surviving streams or workers.

package/docs/run.md

@@ -1,11 +0,0 @@
-# `run://` — sibling agent runs
-
-Sibling agent runs in this session. `run://self` is you; `run://<name>` is a sibling. `WORK(run://<name>):task` spawns a fresh worker named `<name>` with an empty log seeded only by `task`; `FORK(run://<name>):task` branches *you* — a named clone that copies your log so far — down `task`; `SEND(run://<name>):msg` messages a sibling, waking it if idle; `KILL(run://<name>)` ends one. Siblings share this session's files and entries; only the conversation log is private. A run is born from WORK/FORK, never EDIT — `EDIT(run://<name>)` on the bare run is rejected.
-
-**Slash count is the discriminator.** `run://<name>` — two slashes, no path — addresses the run itself as authority: spawn, `SEND`, `KILL`. `run://<name>/path` addresses an entry in its scratch — `READ(run://worker/notes.md)` reads a sibling's, `EDIT(run://self/todo.md):…` writes your own.
-
-**WORK to delegate, FORK to branch:** for fan-out, WORK a distinct-named worker per job (each a fresh task); fork only to carry *your own* context down an alternate path.
-
-**Loop: spawn once → park → collect on wake.** `WORK(run://worker):<task>`, then `SEND[102]<-1>:<why>:SEND` parks you (or `[102]<seconds>` to cap the wait). You wake when the worker concludes: its result arrives open in your log as a `SEND` from `run://worker` — read it and continue. Or pull it — `READ(run://worker)` returns the result, or `425` if it's still running. Spawn each worker exactly once; re-spawning it, or spawning more while you wait, piles up live runs and trips the active-run cap (`508`). Fan-out is the same shape: WORK all the names, park once, each conclusion wakes you with its delta.
-
-**Concluding with live workers.** `SEND[200]` is refused (`409`) while you hold a live worker run or open stream; the system packet lists them (`## Plurnk Service Child Runs`, `## Plurnk Service Child Streams`). Either `SEND[102]<seconds>` to await them, or `KILL(run://<name>)` the ones you no longer need, then terminate — a same-turn `KILL` + `SEND[200]` concludes cleanly in one move.