owfadev 0.0.1 → 0.3.1

package/.meta/docs/research-landscape.md

@@ -0,0 +1,132 @@
+# Comparable Products and Paradigms Survey: Getting Information In and Out
+
+> Development-side research archive (2026-09-16, distilled from four parallel web-research tracks: official docs / papers / HN·Reddit communities): the market benchmarking basis for vault-wiki (inspired by llm-wiki). Not a runtime artifact of any instance. Unified four-question frame: **how information composition (ingestion) works, how information retrieval (output) works, success points and attractions, problems and flaws**.
+
+## 1. Lineage origins: llm-wiki and OKF
+
+### 1.1 Karpathy's "LLM Wiki" gist (2026-04-04)
+
+- **What it is**: a GitHub Gist published by Karpathy (a pure idea file, no code, designed to be pasted directly to any agent). Core claim: RAG (including NotebookLM, ChatGPT file uploads) "rediscovers knowledge from scratch" on every question, with no compounding; the alternative is letting an LLM incrementally build and maintain a persistent markdown wiki—"knowledge is compiled once and then kept current, not re-derived on every query", i.e. the opposition of **distill-at-write vs. retrieve-at-query**. Humans abandon wiki maintenance because the burden grows faster than the value, while an LLM does not tire and never forgets to update cross-references. Intellectually traceable to Bush's 1945 Memex.
+- **Structure**: three layers—raw sources (human-curated, immutable, LLM read-only) → the wiki (LLM full-authority generation and maintenance) → the schema (CLAUDE.md/AGENTS.md conventions); three operations Ingest/Query/Lint; two special files index.md and log.md. (The gist is deliberately abstract; the folk "raw/wiki/output three-folder" account is second-hand embellishment.)
+- **Success points**: measured token gains are dramatic (an r/ClaudeAI case of 47,450 → 360 tokens, plus a 71.5× case); pure files, zero dependencies, Obsidian-compatible; knowledge compounding.
+- **Flaws**: initial compilation and ongoing maintenance are themselves token-hungry (2000 md files will blow the rate limit, per a skeptical r/ObsidianMD thread); errors and hallucinations from the distillation stage solidify into the wiki; the barrier is high for ordinary users.
+- **Derivative implementations**: nvk/llm-wiki (1.3k★, command set + AGENTS.md, self-described as inspired by Karpathy), nashsu/llm_wiki (19.6k★, Tauri desktop app + knowledge graph), the awesome-llm-wiki list, etc. autoresearch (karpathy's official repo, ~96k★) is ML-training automation, unrelated to wikis, but the community often conflates the derived "loop research-archive" pattern with it in circulation.
+
+### 1.2 Google OKF—Open Knowledge Format (2026-06-13)
+
+- **What it is (verified)**: the Google Cloud official blog post "How the Open Knowledge Format can improve data sharing" + the spec repository (GoogleCloudPlatform/knowledge-catalog/okf/SPEC.md, started at v0.1, now v0.2). Self-positioned: **formalizing the llm-wiki pattern into a portable, interoperable open format**; the blog text cites Karpathy, acknowledging the intellectual origin.
+- **Contract**: "Just markdown + Just files + Just YAML frontmatter"; one file per concept, **the file path is the identity**; the only required field is `type`, with title/description/resource/tags/timestamp conventional; reserved file names index.md and log.md; markdown links woven into a relationship graph. Three principles: minimally opinionated / producer-consumer independence / **format, not platform** (no binding to cloud, database, model, or agent framework).
+- **Ingestion**: the reference implementation's enrichment agent walks BigQuery datasets drafting a concept doc per table, with a second LLM pass adding citations/schema/join paths. **Retrieval**: static single-file HTML graph visualization (no backend).
+- **Reception**: positive but exploratory—vs-RAG/GraphRAG comparisons, enterprise agent-knowledge-layer discussions, developers building their own supersets, r/LLMDevs debates over applicability boundaries. Note the acronym collision with the Open Knowledge **Foundation** (CKAN, government open-data portals; a very distant lineage).
+- **Convergence with this project's `01-okf.md`** (independent distillation on both sides, same Karpathy lineage):
+
+| Contract point | Google OKF | This project's 01-okf.md v0.2 |
+|---|---|---|
+| `type` required, value set decided instance-side | ✓ | ✓ (closed via registry) |
+| Reserved names index.md / log.md | ✓ | ✓ (+ exemption duties) |
+| One concept one file, path as identity | ✓ | ✓ (wikilink full name = path) |
+| Minimal YAML, complex structures not accepted | ✓ | ✓ (top-level scalars / block lists / one-level block mappings) |
+| Producer-consumer decoupling | producer-consumer independence | SASU-L zero priors |
+| Trust and provenance | **none** | **trust four fields + unified actor format + trust-level derivation** (a differentiated strength) |
+
+### 1.3 kepano/obsidian-skills (2026-01)
+
+The official agent skills repository from Obsidian CEO kepano, following the Agent Skills open specification (agentskills.io), now about 48.4k★. Six skills today: obsidian-markdown / obsidian-bases / json-canvas / obsidian-cli / defuddle / knap (the last added later; the five skills recorded in internal archives lack it). Pure-files philosophy: agents read and write Markdown/Bases/JSON Canvas directly. Flaw: community testing of obsidian-cli 1.12 found 13 silent failures (22.8% of 57 scenarios exiting 0 yet returning empty/wrong data), spawning third-party remediation skills.
+
+### 1.4 Nearby references
+
+- **DeepWiki** (Cognition): freely AI-generates conversable documentation for any public GitHub repository; controversies: generating without maintainer consent + questioned accuracy.
+- **OKFN/CKAN**: a dataset publication and discovery system aimed at government/institutional open data; distant lineage from agent personal knowledge bases.
+
+## 2. AI-native knowledge-base products (consumer PKM)
+
+| Product | Ingestion (composition) | Retrieval (search) |
+|---|---|---|
+| NotebookLM | sources uploaded per notebook (PDF/Docs/URL/audio-video), near-zero processing at write | source-grounded RAG with inline citation markers; Audio Overview podcast-style summaries |
+| Notion AI | the workspace is the corpus + connectors syncing Slack/Jira/Drive | cross-page + connector-data Q&A with source links |
+| Mem | quick capture, AI auto-tagging and association, zero manual organization | Smart Search semantic retrieval + Related Notes auto-surfacing |
+| Reflect | daily notes + web clipping + voice transcription; AI auto-adds entity backlinks | backlink-network browsing + full-text search + built-in AI chat |
+| Tana | meeting transcription / AI capture; supertags give nodes a schema, processing fields at write | live searches as dynamic aggregate views + Ask AI |
+| Reor | points at an md directory, local chunking + embeddings stored in LanceDB at write | local semantic search + related notes + local-LLM RAG, fully offline |
+| Khoj | syncs markdown/PDF into an index (embedded at write), open-source self-hosted | natural-language search + sourced Q&A, backend can plug into Ollama |
+| Obsidian plugins | Smart Connections embeds everything locally with continuous increments | sidebar live related notes + semantic search; Copilot Vault QA with citations |
+| MyMind | one-click save, AI auto-tagging + summarization, zero organization | smart search (keyword + semantic) |
+
+**Success points**: NotebookLM's grounding + traceable citations are seen as the anti-hallucination benchmark, and Audio Overview was the breakout catalyst (third-party aggregate tallies claim over 30 million users; second-hand figures, for reference only); Notion leans on existing users with zero migration cost; Mem's search reputation and $23.5M funding; Reor's Show HN 411 points plus kepano's public endorsement that "plain markdown files beat databases"; Khoj/Obsidian plugins feed on the "data never leaves the machine + reuse your existing vault" selling points.
+
+**Flaws** (documented per product): NotebookLM still has fake citations / mismatched quotes, poor PDF table recognition, serious inaccuracy past roughly 500k characters, and a long-lamented source-count cap; Notion's results depend heavily on workspace organization quality, questions against databases often fail retrieval, and paywall changes sparked discontent; Mem bled users to long-standing bugs before 2.0, and the cost of automatic organization is that the classification logic is not your own; Tana has a steep learning curve; Reor's author concedes "RAG is fairly naive" and the local 7B model is a hard ceiling; Khoj has a high deployment barrier, and its "self-hosted" marketing clashes with its OpenAI dependency; Obsidian plugins' Vault QA requires full embedding first, and semantic association is poor in multilingual vaults; MyMind's inaccurate auto-tags make things harder to find again.
+
+**Spectrum summary**: on one end, **heavy processing at write** (Mem/Reflect/MyMind auto-tagging; Reor/Smart Connections embedding at write); on the other, **near-zero processing, computed at query** (NotebookLM/Notion/Tana live search). Processing at write buys retrieval speed but solidifies errors—inaccurate auto-tags are the common failure point; processing at query keeps the original text pure but is costly and slow. "RAG Q&A with clickable citations" has become a standard selling point, while "fake citations" remain every vendor's shared crack in trust.
+
+## 3. Agent memory systems
+
+### 3.1 Product level
+
+- **ChatGPT Memory**: saved memories (entries written by the bio tool and injected into the system prompt) + reference chat history (per Embrace The Red's hands-on analysis: it does not retrieve historical conversations but is a continuously aggregated longitudinal profile—preference inferences, topic summaries, the raw text of roughly the last 40 user messages, device/intent metadata—injected wholesale, pure write-time processing). Successes: zero-config on by default, deletable item by item; flaws: the profile area is unauditable and uneditable by the user, capacity is small (Plus fills up quickly), the profile can be contaminated by conversation injection, and it is unavailable in Europe over GDPR concerns.
+- **Claude (Projects / memory tool / the 2026-08 unified memory)**: on the product side, chat and Cowork share memory, partitioned per Project, on by default. On the API side, the memory tool is **client-side file-based memory**: six commands operate on a `/memories` directory, Claude autonomously decides what to record, the system prompt enforces "look at the memory directory before doing anything", and it persists to disk continuously under the assumption that "the context may be reset at any moment". Files are memory—a minimal mental model; flaws: the application side must implement its own handler and guardrails, with no built-in deduplication/conflict resolution.
+
+### 3.2 Framework level (star counts as of 2026-09)
+
+- **Mem0 (65.4k★)**: two-stage extract-consolidate—on `add()` an LLM extracts fact-level memories, and a decision engine issues ADD/UPDATE/DELETE/NOOP against old memories (OSS v3 has simplified to ADD-only; corrections require explicit update/delete). Retrieval fuses four signals (vector + keyword + entity boost + temporal intent). Official numbers: LoCoMo 92.5, tokens about 1/3–1/4 of full context. Flaws: extraction is lossy and non-deterministic, details are lost at "factualization"; HN critics say it "only stores and retrieves, learns no patterns".
+- **Zep / Graphiti (30.9k★)**: incrementally builds a **temporal knowledge graph**, bitemporal—facts carry valid/invalid time windows, outdated facts are "invalidated rather than deleted", episodes retained permanently for provenance. Retrieval is hybrid (embeddings + BM25 + graph traversal) with graph-distance reranking, supporting "current truth / any historical point-in-time" queries. Flaw: multiple LLM calls per episode make ingestion latency and cost high.
+- **Letta (formerly MemGPT, 24.8k★)**: OS-style layering—context as RAM, external storage as disk; memories are named blocks that the agent self-edits via tool calls; sleep-time compute reflects in the background during idle periods and rewrites shared memory blocks. Key experiment: **Letta Filesystem merely stores conversation history in files and scored 74.0% on LoCoMo, beating most dedicated memory stores**. Flaws: many abstraction layers, a steep learning curve, and self-editing can corrupt memory.
+- **MemOS (11.4k★)**: the paper unifies three memory states via MemCube (plaintext / activated KV-cache / parameterized LoRA) + a Memory Scheduler for dispatching; the open-source landing is a multi-Cube knowledge base with traces/policies/world-models layering, while the three-state transitions mostly remain on paper. The greatest academic ambition, concept-heavy, lacking third-party validation.
+- **Cognee (30.7k★)**: an ECL pipeline (Extract-Cognify-Load) into knowledge graph + embeddings, including session distillation and ontology-constrained deduplication; `recall` auto-routes hybrid graph/vector retrieval. The code knowledge graph is the differentiator; LLM graph extraction is the cost bottleneck—an independent evaluation rated extraction quality 2.97/5.
+- **LangMem / LangGraph memory**: splits memory psychologically into semantic/episodic/procedural; the distinctive part is the procedural channel hot-updating the system prompt. Clear concepts and the broadest tutorial ecosystem; but it is more of an SDK—no graph, no temporality, schemas entirely user-designed.
+
+### 3.3 Academic side
+
+MemGPT (arXiv:2310.08560, the paradigm's origin); A-MEM (arXiv:2502.12110, Zettelkasten-style atomic cards with LLM-generated links/tags, where adding new memories triggers dynamic reorganization of the old memory network); HippoRAG 2 (ICML 2025, modeled on hippocampal indexing theory, builds a KG offline + completes multi-hop association with a single graph traversal at query time).
+
+### 3.4 The LoCoMo benchmark dispute (a trust-crisis specimen)
+
+The Mem0 paper reported Zep at 65.99% → Zep published "Lies, Damn Lies, & Statistics" alleging misconfiguration, self-reporting 84% → Mem0's CTO counter-sued (denominator-exclusion manipulation, secretly altered prompts; across 10 reruns Zep got only 58.44%±0.20). **Third-party meta-analysis**: about 6.4% of LoCoMo questions have corrupted ground truth; the GPT-4o-mini judge pass rate is 62.81%; **the full-context baseline of about 73% overtakes most dedicated memory stores**; the same system scores anywhere from 38%–92% depending on who does the evaluating. Net conclusion: static memory leaderboards are basically untrustworthy; evaluation must be self-built and carry full-context/grep baselines—external corroboration of this project's ruling to "validate by use, no matrix testing".
+
+## 4. Multi-agent collaboration paradigms
+
+**A four-way split of shared substrates**: message streams (AutoGen, OpenAI Agents SDK's items) · state/checkpoints (LangGraph, ADK) · vector memory stores (CrewAI) · **files and documents** (Anthropic appendix recommendation, Manus, Claude Code, MetaGPT). vault-wiki belongs to the files school.
+
+**Four highlights**:
+
+1. **Anthropic's multi-agent research system** (2025-06 blog): orchestrator-worker, with embedded scaling rules (1 subagent for simple facts / 10+ for complex research); context isolation—each subagent carries a clean context, and the lead receives only compressed results. **The official appendix explicitly recommends: subagent outputs are written to the filesystem, with only lightweight references passed back**—avoiding large outputs being copied layer upon layer through conversation history. Opus 4 lead + Sonnet 4 workers beat a single agent by 90.2%, with token usage explaining 80% of performance variance; costs: multi-agent runs about 15× tokens, vague instructions cause subagent collisions and duplicated work, non-determinism is hard to debug, and the company states outright that it does not fit tightly coupled tasks that need shared context.
+2. **Claude Code**: memory fully file-based—layered CLAUDE.md (enterprise/project/user levels), skills as SKILL.md folders with on-demand progressive disclosure, subagents themselves being md definitions. A subagent's isolated context sees only task + constitution + git snapshot, with only the final summary flowing back. Official warning: a bloated constitution gets ignored (every line must pass the "would removing it break something?" test).
+3. **Manus context engineering**: **the filesystem as the ultimate context**—unbounded, naturally persistent, directly operable by the agent; todo.md plans externalized and rewritten repeatedly, fighting lost-in-the-middle; append-only context with a stable prefix preserves KV-cache ($0.30 cached vs $3.00 uncached/MTok, 10×). Admitted flaws: long-context performance decay, and repeated traces leading the model to imitate old patterns.
+4. **OpenAI Agents SDK**: a session is an items list; Session prepends before the run / appends after, and multiple agents can share a session and see each other; handoff by default **broadcasts the full history** (trimmable with a filter), and input_type passes only small metadata. Flaws: misplaced guardrail responsibilities, and token bloat over long chains requires building your own filters.
+
+**Quick sketches**: AutoGen's group chat is shared memory—every message visible to all—with the official advice "single agent first, a team only when collaboration is truly needed"; CrewAI has the most explicit consolidation strategy (similarity >0.85 triggers LLM arbitration of keep/update/delete, ≥0.98 dedup, composite scoring semantic 0.5 / recency 0.3 / importance 0.2); LangGraph runs dual-track checkpointer (session snapshots) + Store (cross-thread shared KV), with accumulating checkpoints pushing latency up; MetaGPT (70.4k★) encodes SOPs, its shared memory being structured document artifacts flowing through (user stories → PRD → design → code), at the cost of process rigidity; MCP handles tool externalization (donated to the Linux Foundation, a de facto standard), complementary to the wiki's handling of shared memory between agents; Google A2A takes the **no shared memory** route (Agent Card discovery + task/artifact passing, protecting IP), while the same company's ADK keeps session state as a KV dictionary with long-term memory in a Memory Bank—default InMemory vanishes on restart, and storing the raw full history "may drown the model".
+
+## 5. Side-by-side comparison
+
+| Representative | Memory substrate | Ingestion (composition) | Retrieval (search) | Trust/provenance |
+|---|---|---|---|---|
+| llm-wiki (Karpathy) | md files | LLM distills at write, raw read-only | index + browsing | none (log.md records operations) |
+| Google OKF | md + YAML | enrichment agent drafts + second pass | static graph visualization | timestamp by convention, no trust model |
+| **vault-wiki** | **md + YAML** | **explicit command-discipline composition (map/save), raw=vault append-only** | **hot cache → index → grep → body, progressive disclosure** | **trust four fields + trust-level derivation** |
+| NotebookLM | source files + chunks | near-zero processing at write | query-time RAG + citation markers | inline citations (occasionally fake) |
+| Mem0 | SQL + vector + entities | LLM extraction + decision-engine consolidation | four-signal fusion | no temporal semantics |
+| Zep/Graphiti | temporal knowledge graph | incremental entity-edge extraction + bitemporal | hybrid retrieval + graph reranking | bitemporal (strongest temporal provenance) |
+| Letta | memory blocks + files | agent self-editing + idle-time reflection | core blocks resident + archival vectors | none |
+| ChatGPT Memory | proprietary profile | aggregated and injected at write | no standalone retrieval layer | unauditable (weakest) |
+| Anthropic multi-agent | message streams + files | orchestrator consolidates; writing to files and returning references recommended | context isolation + summary backflow | a dedicated citation-backfill agent |
+| Manus | filesystem | append-only + externalized todo.md | full retention + KV-cache | reconstructable (URL/path pointers) |
+
+## 6. Shared successes and shared flaws
+
+**Successes**: ① compounding—"compile once, keep fresh" replacing "re-derive every time" (llm-wiki, Mem0's selective updates, Zep's invalidate-not-delete); ② verifiable citations as a trust selling point (NotebookLM's markers, Notion's links); ③ pure files + path as identity (OKF's format-not-platform, kepano's argument, the Letta Filesystem experiment, Claude's memory tool in the same direction); ④ progressive disclosure controlling tokens (index → body, skills, Audio Overview); ⑤ zero-config on-by-default lowering the mass-market barrier (ChatGPT Memory).
+
+**Flaws**: ① extraction is lossy and non-deterministic (the common ailment of Mem0/Zep/Cognee, not reproducible); ② distilled errors solidify—hallucinations in a wiki have no natural correction loop (llm-wiki's biggest soft spot; check/lint is the lifeline); ③ fake citations and audit gaps (NotebookLM's mismatched quotes, ChatGPT's uneditable profile); ④ token costs (multi-agent 15×, wiki maintenance fees, full-embedding fees); ⑤ benchmark arms races detached from real use (the LoCoMo dispute, full-context baselines overtaking); ⑥ the loss of control from automatic organization and the philosophical critique that it "makes thinking passive" (Mem/MyMind).
+
+## 7. Implications for vault-wiki
+
+**Choices already externally validated**: the md pure-files foundation (OKF's three principles, kepano's argument, Letta Filesystem's 74.0%, Claude memory tool's file memory—four independent corroborations); path as identity ↔ the wikilink full-name convention; index.md/log.md reserved names already a lineage convention; the hot cache ≈ Manus's todo.md anti-drift + progressive disclosure; the trust four fields exactly fill the trust layer that both Google OKF and NotebookLM lack; the "validate by use" ruling and the LoCoMo trust crisis corroborate each other.
+
+**Worth borrowing**: Anthropic's "outputs to the filesystem, lightweight references back" can be written explicitly into save/map usage; Zep's "invalidate rather than delete" is isomorphic to trust's stale_after/verified event lists and can strengthen the semantics of "mark stale knowledge, never delete"; Letta's sleep-time compute corresponds to this project's "idle-time log consolidation" (the existing requires-user-consent boundary unchanged); CrewAI's consolidation thresholds prove that save deduplication can be quantified, but mechanizing the numbers risks overfitting.
+
+**Risk warnings**: distilled errors solidifying—check must keep its hard-constraint status; the token cost of wiki maintenance swelling with page count—hot ≤25 entries and index aggregation are the existing gates and need continued watching; **the OKF name collision** (Google Open Knowledge Format / Open Knowledge Foundation)—the full name of `01-okf.md` is undetermined, pending the owner's note; whether to align with Google OKF or explicitly differentiate is a decision point.
+
+## 8. Sources (selected, grouped)
+
+- **Lineage**: Karpathy LLM Wiki gist (gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) · Google OKF blog (cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing) · OKF spec (github.com/GoogleCloudPlatform/knowledge-catalog, okf/SPEC.md) · kepano/obsidian-skills (github.com/kepano/obsidian-skills) · nvk/llm-wiki (github.com/nvk/llm-wiki) · nashsu/llm_wiki (github.com/nashsu/llm_wiki) · token case (r/ClaudeAI 1sfdztg) · hype skepticism (r/ObsidianMD 1sx040s) · CLI silent failures (forum.obsidian.md/t/111169)
+- **Knowledge-base products**: NotebookLM (blog.google Audio Overviews; r/notebooklm 1l2aosy) · Notion AI (workflowautomation.net review; r/Notion 1g7gx3h) · Mem (techcrunch 2022-11-10 funding) · Reflect (reflect.app/blog) · Tana (producthunt.com/products/tana) · Reor (news.ycombinator.com/item?id=39372159) · Khoj (github.com/khoj-ai/khoj) · Smart Connections (community.obsidian.md)
+- **Agent memory**: Mem0 (docs.mem0.ai/core-concepts/how-it-works; arxiv 2504.19413) · Zep/Graphiti (github.com/getzep/graphiti) · Letta (letta.com/blog/sleep-time-compute; letta.com/research) · MemOS (arxiv 2505.22101; github.com/MemTensor/MemOS) · Cognee (github.com/topoteretes/cognee) · LangMem (langchain-ai.github.io/langmem) · ChatGPT Memory teardown (embracethered.com 2025 chatgpt-how-does-chat-history-memory-preferences-work) · Claude memory tool (platform.claude.com/docs) · the dispute (blog.getzep.com/lies-damn-lies-statistics; github.com/getzep/zep-papers/issues/5; essays.bloo-mind.ai/posts/2026-05-20-mem-eval)
+- **Multi-agent**: Anthropic multi-agent system (anthropic.com/engineering/built-multi-agent-research-system) · Claude Code (code.claude.com/docs/en/best-practices; /sub-agents) · Manus (manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus) · Agents SDK (openai.github.io/openai-agents-python) · AutoGen (microsoft.github.io/autogen) · CrewAI (docs.crewai.com/concepts/memory) · LangGraph (docs.langchain.com langgraph/persistence) · MetaGPT (github.com/FoundationAgents/MetaGPT; arxiv 2308.00352) · MCP (modelcontextprotocol.io) · A2A (a2a-protocol.org) · ADK (cloud.google.com/blog remember-this-agent-state-and-memory-with-adk)

package/.meta/docs/research-user-profile.md

@@ -0,0 +1,27 @@
+# User Profile Research Distillation (design basis for user-profile)
+
+> Development-side design archive (2026-09-13, distilled from four rounds of web research): the selection basis for the user-profile plugin. Not a runtime artifact of any instance; framework behavior is sourced from `.meta/plugins/user-profile/`.
+
+"User profiling" has two practice lines with different semantics: the product-design line draws **representative fictional target users** (personas), serving design decisions; the agent-memory line maintains **a continuous cognition profile of the real user** (user profile), serving personalization. vault-wiki's profile plugin belongs to the latter—borrowing the dimension framework from the former and the update mechanism from the latter.
+
+## The dimension framework from product methodology
+
+Mainstream persona template fields converge on: basic attributes, role/background, goals, pain points, behavioral habits, motivations. Chinese-language material commonly distinguishes **static dimensions** (demographic attributes, low-frequency change) from **dynamic dimensions** (behavioral preferences, continuously evolving). The construction process is a three-step frame: acquire and research user information → segment user groups → build and enrich profiles.
+
+Two practical disciplines:
+
+- **Details that serve no decision should be discarded**—a profile is not better for being more complete; details you cannot act on are unwanted
+- **Profiles have a durability requirement**—they go stale and must be maintained continuously; the static/dynamic layering maps neatly onto different update frequencies and expiry policies
+
+## The update mechanism from agent memory
+
+The core patterns of the agent memory field: a profile consists of two layers, **static identity facts + real-time behavioral signals**; user-scoped persistent memory underpins cross-session continuity; profiles update incrementally with user feedback. Behavioral signals and self-reported signals complement each other—what the user did (which assets were placed in) is often harder evidence than what the user said.
+
+## vault-wiki's selection
+
+The profile page is a convergent cognition profile: a static identity layer + a dynamic preference layer, with open-ended sections and unenumerated dimensions. Assertions must carry evidence wikilinks (guarding against hallucination pile-up), and the preference layer carries stale_after (knowledge that can go stale explicitly declares its expiry moment). Signals have two channels: conversation saves (self-reported signals) and asset mapping (behavioral signals). Zero proprietary fields; trust provenance fully reuses trust semantics.
+
+## Sources
+
+- Zhihu column 「数据分析之用户画像方法与实践」 (user-profiling methods and practice in data analysis), 人人都是产品经理 「构建用户画像的流程与方法」 (the process and methods of building user profiles), boardmix 「persona 的 8 个内容维度」 (8 content dimensions of a persona)—the dimensions-and-process line
+- Supermemory "How AI User Profiles Drive Personalization", Mem0 "Build an AI Agent That Actually Remembers Your Users", Microsoft Foundry user-scoped persistent memory—the agent-memory line

package/.meta/docs/sandbox.md

@@ -0,0 +1,40 @@
+# Using the sandbox
+
+> Reader: team members who need to run experiments against real data. The authoritative source for sandbox governance red lines is the "User requirements" section of AGENTS.md; this document covers operations. Written 2026-10-04; updated 2026-10-13 — the in-repo sandbox left git tracking (owner re-ruling) and is local-only now.
+
+## What it is
+
+test-repo is a scratch deployment instance living inside the development repository — **local-only and untracked since 2026-10-13**: a fresh clone of the framework carries none of it, and nothing inside (mirrors included) can enter history. Its `.meta/` and `.agents/` trees are a mirror of the framework, re-copied wholesale from the root side when a batch closes; everything else is the sandbox's own data zone. The inside of the sandbox is unaware of this project: a session opened at the sandbox root reads the sandbox's own AGENTS.md and skills.
+
+## Enabling it
+
+The sandbox is not initialized in a fresh clone. To set one up (or redo it from scratch), four steps:
+
+1. `mkdir test-repo` at the framework root
+2. Copy the framework trees in: `.meta/` and `.agents/` from the root side
+3. Create the `AGENTS.md` shell inside: one identity paragraph plus a layout description, and insert the injection region marker block — from `<!-- wiki-inject:start -->` to `<!-- wiki-inject:end -->`, keeping the region header and the explanatory lines (see [agents-example.md](agents-example.md))
+4. Create four empty directories (`vault/`, `wiki/notes/`, `wiki/sessions/`, `wiki/vault/`) and run `python .meta/scripts/wiki_plugin_kernel.py all` at the sandbox root — the injection region fills, all-green validate makes it a usable instance
+
+## Running experiments
+
+Open an agent session at the sandbox root and use commands normally: map, save, query, check, and the course family all work. The data zone grows naturally — wiki derived pages are built on first run, course data lands on the bb side. Artifacts and derivatives are all to be treated as local temporary material.
+
+## Red lines
+
+Three summarized here; the authoritative source is AGENTS.md:
+
+- Nothing inside `test-repo/` is ever committed — the whole tree is gitignored; mirrors, data, derived pages, all of it
+- Mirror updates go only through root-side re-copy. The sandbox side may modify mirror files for framework experiments, but the next re-copy overwrites them; framework-level changes should be made on a root-side branch and go through review-and-merge
+- Conclusions travel via conversation reports or docs, never via sandbox archives
+
+## Wrap-up and reset
+
+Whether experiment data stays or goes is up to you; resetting means deleting everything outside the mirror trees — `bb/`, `wiki/`, and `__pycache__` inside the mirror — then walking "Enabling it" once more yields a clean sandbox.
+
+## Mirror sync
+
+Re-copy happens when a root-side batch closes. To trigger it yourself: delete the sandbox's two mirror trees, copy the whole trees in from the root side, then run kernel convergence once more. The sandbox carries no `connectors/` sources, so kernel deploy will report connector skill copies as orphans — the warning is expected; keep the copies, they remain usable.
+
+## Sandbox vs. local
+
+The constitution and the usage guide both say "experiments land in the sandbox or locally". The two are the same thing at two scales: test-repo is the shared-in-place sandbox inside your template checkout; opening your own local sandbox elsewhere is just a manual deployment (see [deployment.md](deployment.md)) — clone (or copy two trees), write the shell, create the directories, run convergence — and the target vault is your choice. One selection criterion: use test-repo when you need to stay in sync with the template mirror at hand; deploy elsewhere for long-term private use or for something close to your real vault.

package/.meta/docs/usage.md

@@ -0,0 +1,45 @@
+# Usage Guide
+
+> Audience: the vault owner after deployment completes — the next step after deployment — plus members who want to understand the collaboration shape. Command details are authoritatively disclosed in each SKILL.md under `.agents/skills/`. This document is about chaining workflows: how single commands connect into loops. Written 2026-10-04.
+
+## Loop One: Vault Stewardship
+
+The general loop; a few minutes a day.
+
+**Input**: drop files into `vault/` and tell the agent "map" — you get `wiki/vault/` proxy pages carrying SHA-256 and metadata; index, tags, and hot cache update automatically. When a conversation yields an insight worth keeping, say "save" and it settles into `wiki/notes/` as a native page — type for classification, tags for grouping. Promote precious drafts out of `wiki/tmp/` promptly; promotion deletes the draft.
+
+**Retrieval**: say "query". The agent reads the hot cache and the index first, then answers synthetically; answers carry wikilink citations you can follow all the way down. Drilling down through index levels is itself a pointer structure.
+
+**Delegation and reminders**: tasks delegated to the agent land in `wiki/todo.md`; one entry = a trigger condition plus one sentence. At the start of a new session the agent reads this page first; due items are proactively raised; completion closes the entry — history goes to log.
+
+**Health**: periodically say "check" for a full audit of mechanical and semantic items. Say "profile" anytime to converge new knowledge about you into `wiki/profile.md`: assertions carry evidence, preferences expire. Before personalization decisions — forms of address, style — the agent reads it first.
+
+The discipline in one sentence: the wiki takes distillates, not process. Process products belong to vault, tmp, and the domain workspaces; only settled conclusions enter notes.
+
+## Loop Two: Course Study
+
+The bb domain loop; one semester's rhythm.
+
+**Onboarding a course**, once at term start: bb-cli pulls, with credentials stored only on the local machine; the `bb/<term>/<course>/` workspace materializes — document-type content in full, media as pointers; bb-map projects the wiki-side territory into four buckets: info for course information, courseware for knowledge points, assessments for assignment dossiers, attachments for attachments; the domain-root inbox.md digest page — announcement distillation plus approaching deadlines plus unsubmitted reminders, synthesized from both sources.
+
+**Daily**, weekly:
+
+1. Read inbox for a near-window view of announcements and deadlines
+2. "Explain and answer" bb-teach: ask about whatever is unclear. The agent reads the cognition profile first; the unknown is explained thoroughly, the known skimmed — or met with a question back at you. Significant explanations settle as ai notes into notes/
+3. "Quiz me" bb-quiz: give a scope, optionally samples. English questions with Chinese annotations land in notes/testing/; after you answer, grading flows back into the cognition profile with your confirmation
+4. "Cognition profile" bb-track: reading the profile and gap analysis. The knowledge-point universe minus the anchored set is the gap; wrong answers trace back to the assessments review
+
+**Closed loop**: teach explains, with ai notes as weak evidence; track converges; quiz generates questions by the profile; grading flows back as machine evidence; the next round of teach flexes against the new profile. Material lives on the bb side — notes, exam papers, the grading process; conclusions live on the wiki side — cognition readings. When the semester ends, everything freezes with term_status.
+
+## Loop Three: Collaborative Development
+
+The standard flow for changing the framework — see AGENTS "commit flow" for details: branch off the latest master; before touching manifests or commands, read `log.md` to align with current state and next steps; `kernel all` green; small commits in the `module: summary` format; push and open a PR; the manager reviews and merges.
+
+**Installing a new domain**, bringing an external source in: `kernel list-remote` shows the catalog; `kernel install <pkg> --yes` lands the package — plugins, commands, and in-repo connectors arrive in one step (the bb course domain brings bb-cli with it; lark declares the external lark-cli; email mail-cli). Credentials stay on the local machine; on first use read the connector skill disclosure, e.g. bb-cli's credentials and usage. The domain growth path and its decision criteria are in the mechanics doc, "How Domains Grow" section.
+
+**Experiments** always land in the test-repo sandbox or locally. Sandbox usage is in `.meta/docs/sandbox.md`; sandbox experiment content never enters history — conclusions travel via conversation reports or docs.
+
+## Rhythm
+
+- calendar sources refresh daily via deployment-side cron unattended sessions — built into lark-calendar's design; bb data TTL defaults to 1 day, the agent is the synchronizer — stale means pull now
+- Onboard courses at term start, freeze at term end; a weekly check plus gap analysis; everything else triggers on use. Commands are natural-language triggered — no ceremony

package/.meta/plugins/core/calendar/PLUGIN.md

@@ -0,0 +1,35 @@
+# calendar: time territory
+
+## Design Overview
+
+- **Why it exists**: the wiki's time dimension — what happens when. The source model is open: manual notes plus each adapter's projections converge on the same page, lark-calendar being the first adapter. Time is a single cross-tenant dimension; multi-source convergence is precisely this territory's reason for being
+- **Key rulings**:
+  - Events are lines, not pages: the calendar registers only the timeline; weighty events are distilled via save into a note or session, then wikilinked from the calendar line — consistent with 'the wiki receives distillates'
+  - Boundary with todo: the calendar stores 'what happens when', todo stores 'what is pending'; events may derive todo entries, never merged the other way
+  - Month pages two-section scheme: `## Schedule` is the source projection, refreshed wholesale by section; `## Manual Notes` is append-only — the mechanical-zone/distillation-zone boundary sits at section level
+  - Future rolling, past frozen: a month may not be rewritten once over; rewrite traces = error, git audit; missed changes are recorded in the new month's page — history stays truthful
+  - The month page is the only mixed-provenance page in the whole library: territory ownership and section-content provenance are separated. Named, not mechanized; a single instance raises no architectural concept
+
+## Structure
+
+- `wiki/calendar.md` — declaration page, type: calendar. Frontmatter `calendar` block mapping = source key to source declaration; value syntax belongs to the adapter, e.g. `lark/<profile> <calendar_id>`. The body holds usage notes; may be absent when manual-only
+- `wiki/calendar/<YYYY-MM>.md` — month page, one page per month, ASCII file name. **Two-section scheme**: `## Schedule` is the source-projection zone, regenerable and refreshed wholesale by section; `## Manual Notes` is for human and agent writing, append-only
+- Event line: `- MM-DD HH:MM~HH:MM Title (source key)`, may carry a wikilink — people, group archives, notes; all-day events written `MM-DD all-day`
+
+## Invariants
+
+- Future rolling, past frozen: a month freezes once over, its page never rewritten; rewrite traces → error, git audit; missed changes are recorded in the new month's page, history staying truthful
+- A refresh only wholesale-replaces the `## Schedule` section; the manual-notes section is never touched by source sync
+- Month pages carry trust: stale_after short TTL, default 2 days, leaving headroom for the daily-refresh cadence
+- Events get no pages; meeting conclusions go to group-archive topic records or notes, the calendar line keeping only the link
+- The declaration page's source list is instance configuration; no declaration page = manual-only, a legal norm
+- The month page is the only mixed-provenance page in the whole library: the `## Schedule` section is a true projection, reconcilable with an external source, lodging in a native territory — territory ownership and section-content provenance separated; named, not mechanized; a single instance raises no architectural concept
+
+## Bridge: on-demand
+
+A derivation-destination bridge governing schedules: domain plugins one-way derive source-keyed schedule lines into the current month's `## Schedule`, out-only; never touching manual notes, never touching frozen month pages. Constitutional principle 11. Attachment cardinality **on-demand**. Format authority is in this plugin's usage, projected to the point of consumption — division-of-labor ruling. This section elaborates: event lines carry the source key; the source key is defined by the deriving domain itself and registered on the declaration page.
+
+## Changelog
+
+- 0.4 (2026-10-06) inject line: sections lost to the kernel comment-strip clip restored (quoted values are now protected), tightened for budget headroom — issue #12 post-migration nit- 0.3 (2026-10-06) inject line compressed to pointer density (issue #12 layer discipline) — procedural detail lives in usage / PLUGIN.md / skills- 0.2 2026-10-02: global-domain batch two — established the on-demand bridge as the derivation destination; domain-plugin self-descriptions retained with a pointer
+- 0.1 2026-09-19: established — month-page two-section scheme, the open source model, the freezing regime; lark-calendar as the first source adapter

package/.meta/plugins/core/calendar/PLUGIN.yaml

@@ -0,0 +1,21 @@
+id: calendar
+schema_version: 1
+version: 0.4
+bridge: 按需
+depends:
+  - wiki
+  - trust
+updated: 2026-10-06
+attachment:
+  - "wiki/calendar.md — declaration page (`calendar` block mapping = source key → source declaration; self-created when the first source attaches, manual-only may be absent)"
+  - "wiki/calendar/ — month pages YYYY-MM.md (one page per month, two-section scheme)"
+fields:
+  calendar: "block mapping (declaration page) — source key → source declaration (value syntax belongs to the adapter: lark-calendar uses `lark/<profile> <calendar_id|primary>`); the source key is the end-of-line tag on schedule lines"
+inject: "Time territory: declaration page wiki/calendar.md (calendar block mapping = source key → declaration; absent = manual-only) + month pages wiki/calendar/YYYY-MM.md — ## Schedule source projection refreshed wholesale + ## Manual Notes append-only; event lines may wikilink, events get no pages; future rolling, past frozen; month stale_after default 2 days; boundary — calendar stores what happens when, todo what is pending; on-demand bridge (domains derive source-keyed lines into the current month)"
+usage:
+  - Sync (mechanical): read the declaration page's source list → each source pulled for the current and next month by its adapter → wholesale section refresh of each month page's `## Schedule` (lines tagged with the source key) → `pipeline.py verify` + log line + commit (`映射: calendar`)
+  - Daily refresh (unattended session): deployment-side cron triggers the sync session on schedule, fully mechanical, no confirmation needed; failed sources are reported via log and do not block other sources; semantic enhancements (event notes, link completion) are left to interactive sessions
+  - Manual notes: append one line to the current month's `## Manual Notes` (date + one sentence), append-only, never modified
+  - Freezing: month pages are never rewritten once the month is over; changes such as rescheduling are recorded in the new month's page
+checks:
+  - Semantic (v0.1 manual, attached audit deferred): month page file name not YYYY-MM or landing outside wiki/calendar/ → error; traces of rewriting a past month's page → error (git audit); declaration page missing the `calendar` block → info (the manual-only norm)

package/.meta/plugins/core/cron/PLUGIN.md

@@ -0,0 +1,38 @@
+# cron: deferred-trigger territory
+
+## Design Overview
+
+- **Why it exists**: the 'cadence' of scheduled tasks was once scattered across three places (lark-calendar's session-edition daily refresh, email's optional daily refresh, bili digest reserved), while the executors (harness scheduler / system task scheduler) are per-workspace, machine-bound, and lost on machine change or reinstall — the intent of 'what should be automated when' had no home: the execution side had tasks but no archive, the wiki side had disclosures but no registry. This plugin gives the intent an md home. v0.4 widens the same motive to the condition dimension: cron governs **deferred-trigger unattended intent** — time was merely the first trigger vocabulary; when conditional executors arrived instance-side, the original verbatim repeated (the executor side had watches, the wiki side had no registry — the first real watch carried a self-continuing "re-register me" note that existed only because conditions had no declaration layer)
+- **Key rulings**:
+  - **Declaration-as-source, executor-as-projection**: an extension of three-projections-one-source into the execution dimension, dissolving the constitutional-principle-4 tension (harness replaceable) — the trigger vocabulary (time = crontab 5-field, condition = the open kind set) is the cross-executor lingua franca, the translation rules belonging to the replay recipes; changing harness / machine / conditional engine = read the declaration pages and replay
+  - **Executor-agnostic positioning** (owner ruling 2026-10-08, issue #29): "the plugin must not be limited by any harness; it exists to provide systematic recording and archiving for all deferred-trigger tasks" — every executor (harness scheduler / system task scheduler / conditional executor) is a peer projection: executor names appear only in the replay recipes' deployment-specific translations (usage), never in invariants, the inject line, or block-mapping vocabulary; probing and delivery semantics (inotify / polling / push, at-least-once) stay executor-side — the wiki records intent and traces only
+  - **Open trigger vocabulary, fixed machinery**: `time` (the v0.3 schedule key) and `condition` (v0.4) are the first two words; future words (event streams? calendar boundaries?) extend the vocabulary, never the machinery; condition kinds are likewise an open set (first batch file|command|http|process|port|webhook — generic monitoring concepts, no executor's private vocabulary); pattern semantics fixed as no-match→match edge, default any change after baseline
+  - **One page per task, pure-directory scheme** (user ruling 2026-10-06, the single-declaration-page proposal rejected): the directory is the full declaration set, no root declaration page — contrast with why the project domain needs `wiki/projects.md` (its container lies outside wiki), while cron task pages are already inside wiki; quick views go through the derived index page
+  - **Reconciliation + replay** (user ruling): the declaration is the source of truth — drift enters the check attached audit (the active page set diffed per form against each readable executor-side list), the replay recipe standardized; writing system state and deleting/stopping execution-side tasks both go through user confirmation (following the device attached-audit delegation precedent)
+  - **Execution-shape dichotomy lifted** (generalized from the bili ruling into a global criterion): any agent-judgment step → session (unattended session); purely mechanical → script (system task running a connector subcommand, zero quota) — form is orthogonal to trigger, the 2×2 matrix (time|condition × session|script) all four combinations legal; each domain merely tags form, no longer inventing its own cadence disclosures
+  - **Unified failure discipline** (lifted from lark-calendar): failed sources report via log, never blocking other tasks; repair delegations one-way derive into todo
+  - **Unattended-session SASU-L**: an agent woken by a scheduler or a conditional watch has zero priors — at replay the prompt or watch note must be self-contained (read the task page and execute per the page + report failures via log); the recipe belongs to this plugin's usage; this is the application of 'no knowledge layer leaking into the architecture' at the session boundary
+  - **machine anchor left blank**: locates the executing machine in multi-device deployments; keeps only the optional key, no device linkage built; refine through use
+- **Position in the family**: a global plugin (cross-cutting deferred-trigger automation), not a domain plugin, does not depend on domain; domain plugins attach and register via the on-demand bridge — this plugin holds 'who is present, what fires it, how to replay and reconcile'; task action shapes belong to each domain (the principle-11 bridge philosophy)
+
+## Structure
+
+- `wiki/cron/<task name>.md` — task page: `cron` block mapping mechanical zone (trigger / action / form / domain / status / last_run / machine optional) + two body sections — `## Task` (action details: which command to call or what the session opening reads, back-linking the owning domain's skill), `## Run Notes` (append-only and convergent: anomalies, repairs, change decisions; normal runs unrecorded — log already has lines, to prevent bloat)
+- No root declaration page: the directory is the full set; the derived index includes quick views
+
+## Invariants
+
+- Declaration-as-source: every executor — harness scheduler, system task scheduler, conditional executor — is a replaceable projection; replay and reconciliation both defer to the declaration pages
+- Executor names never enter invariants, the inject line, or field vocabulary — the replay recipes (usage) are their only home; trigger semantics declared wiki-side must remain translatable to any executor
+- Trigger vocabulary is open (extend words, not machinery); condition declarations carry executor-portable semantics only — what condition, edge, budget, cooldown; never how to probe or deliver
+- System-state writes require user confirmation: the script edition landing system tasks or watches, status changes syncing deletes/stops on the execution side — following the device attached-audit delegation precedent
+- Normal runs write no task-page history; run notes take only anomalies and changes; last_run is machine-maintained
+- status: paused / deprecated pages are never deleted (kept for the record); deprecated tasks remain in the directory for lineage reference
+- Three-way boundary: todo one-shot delegations (the human states the trigger) · calendar event facts (what happens when — reality states the trigger) · cron deferred-trigger automation intent, systematically recorded and archived (machine conditions state the trigger); task outputs land per each domain's discipline (e.g. lark-calendar's daily-refresh output goes into the month page's schedule section, bili digest refreshes the digest page)
+
+## Changelog
+
+- 0.4 (2026-10-08) deferred-trigger generalization (issue #29): schedule → trigger (time | condition forms, open kind vocabulary file|command|http|process|port|webhook), executor names withdrawn from the inject line into the replay recipes, trigger × form 2×2 matrix, per-form best-effort reconciliation (unreadable executor → info); executor-agnostic positioning ruled by the owner 2026-10-08
+- 0.3 (2026-10-06) inject line: sections lost to the kernel comment-strip clip restored (quoted values are now protected), tightened for budget headroom — issue #12 post-migration nit
+- 0.2 (2026-10-06) inject line compressed to pointer density (issue #12 layer discipline) — procedural detail lives in usage / PLUGIN.md / skills
+- 0.1 (2026-10-06) established — three questions converged (a unified registry covering both session/script shapes, reconciliation + replay, one page per task); lark-calendar 0.2 / bili 0.2 / email 0.4 moved along with the bridge attachment (scattered cadence disclosures rewritten into place)

package/.meta/plugins/core/cron/PLUGIN.yaml

@@ -0,0 +1,24 @@
+id: cron
+schema_version: 1
+version: 0.4
+bridge: 按需
+depends:
+  - wiki
+  - trust
+  - log
+updated: 2026-10-08
+attachment:
+  - "wiki/cron/ — deferred-trigger territory (one page per task, pure-directory scheme — the directory is the full declaration set, no root declaration page, quick views via the derived index)"
+  - "wiki/cron/<task name>.md — task page (type: cron; cron block mapping mechanical zone + two body sections)"
+fields:
+  cron: "block mapping (task page) — trigger (deferred-trigger declaration; v0.4 generalizes the v0.3 schedule key, schedule reads as the time form): time form = crontab 5-field or human-readable cadence, local timezone by default; condition form = condition <kind> <target> [pattern] [interval] [max_fires] [cooldown], kind first batch file|command|http|process|port|webhook (open vocabulary — extend words, not machinery), pattern semantics fixed as no-match→match edge (default any change after baseline) / action (the action in one sentence) / form (execution shape: session edition | script edition — criterion: any agent-judgment step means session, purely mechanical means script; orthogonal to trigger, all four combinations legal) / domain (owning domain, tagged when a domain plugin registers via the bridge, omittable for cross-domain tasks) / status (active in-service | paused suspended | deprecated retired) / last_run (most recent run or fire time, machine-maintained) / machine (optional: executing-machine anchor for multi-device location; no linkage built)"
+inject: "Deferred-trigger territory wiki/cron/ (one page per task, the pure directory = the full declaration set): task page type: cron + cron block mapping (trigger: time (crontab 5-field) | condition <kind: file|command|http|process|port|webhook>, condition grammar in PLUGIN.md; action/form session|script/domain/status/last_run/machine) + ## Task + ## Run Notes append-only; declaration-as-source, every executor a replaceable projection — executor names live only in the replay recipes (usage), wiki records intent and traces, probing/delivery semantics stay executor-side; replay lands active pages execution-side upon user confirmation; reconciliation per-form diff against readable executor lists in the check attached audit; intent-change sync both directions; failures report via log only, never blocking others; boundaries — todo one-shot, calendar facts, cron deferred-trigger automation intent; on-demand bridge (domain tasks: page + depends)"
+usage:
+  - Registration (domain plugin via the bridge / direct human creation): build wiki/cron/<task name>.md — cron block mapping minimal key set (trigger/action/form/status) + a `## Task` section (action details: which command to call or what the session opening reads, back-linking the owning domain's skill); condition-form triggers declare executor-portable semantics only — what condition, edge, budget and cooldown; never executor-specific probes or delivery details; domain-plugin registrations tag domain and hang depends cron
+  - Replay — the 2×2 translations (executor names live here and only here): time+session → harness-scheduler unattended session, prompt self-contained (read wiki/cron/<task name>.md and execute per the page, report failures with a log line, never block other tasks); time+script → system timer / crontab; condition+session → the deployment's conditional executor as a watch (name = page name, note self-contained pointing at the task page); condition+script → system timer running a stateful edge-detection script (state file holds the last-seen match, fire on no-match→match, zero harness dependency — inline recipe, v1 ships no script artifact); system-state writes upon user confirmation; when execution-side tasks diff against the declarations, add and delete with the declaration pages as the authority
+  - Run traces: a normal completion or fire writes a log line (type other, tagging the task name) + a mechanical last_run update on the task page; anomalies enter `## Run Notes`, append-only and convergent; repair delegations → todo (one-way derivation)
+  - Reconciliation (check attached-audit discipline): per-form best-effort — the active page set diffed against each readable executor-side list (scheduler tasks / system tasks / conditional-executor watches), drift → warning; unreadable or absent executor → info skip, never error; time form: last_run beyond the schedule period with status: active → warning (projection-lost signal — the condition form has no cadence staleness, it rides this reconciliation); paused/deprecated pages still running on the execution side → error
+  - Pause and deprecation: a human changes status → the agent synchronously deletes/stops the execution-side task (scheduled task or watch) upon confirmation; deprecated pages are never deleted (kept for the record)
+checks:
+  - Mechanical: a type: cron page landing outside wiki/cron/ → error; task page missing the cron block or the minimal key set (trigger/action/form/status) → warning; malformed condition trigger (kind outside the open vocabulary or missing target) → warning; time form: last_run beyond the schedule period with active → warning (projection-lost signal)
+  - Semantic (attached audit deferred): per-form drift between readable execution-side lists (scheduler / system tasks / conditional-executor watches, best-effort) and the declaration page set → warning; unreadable executor → info

package/.meta/plugins/core/device/PLUGIN.md

@@ -0,0 +1,38 @@
+# device: device profiles
+
+## Design Overview
+
+- **Why it exists**: static asset facts of personal devices (computers, phones, peripherals) — serial number, purchase date, warranty end — previously had nowhere to live: retrieval relied on chat memory, warranty expiry on human memory. This plugin establishes the minimal norm: one page per device as native knowledge, fields mechanically consultable, an expiry reminder flow
+- **Position in the family**: a global plugin, zero territories, zero commands, zero type value additions — devices are not a source outside wiki (no pulling, no reconciliation; human-registered native knowledge), so no domain is established; pages reuse the notes territory (type: entity as a suggested form), retrieval covered naturally; this plugin adds only two layers, 'field norm + expiry mechanism'
+- **Key rulings**:
+  - Reuse notes, no new territory: entity is already in the registry's default form vocabulary, the provenance definition fits (knowledge whose true copy lives in wiki); an independent territory costs one notch more in structure — rejected
+  - Minimal key set + open extension: serial / purchased / warranty_until fixed as three keys (the attached audit scans only the third), remaining keys (model, vendor, etc.) free for instances — the architecture does not enumerate
+  - Expiry reminders go through the delegation flow, not a bridge: the attached audit presents a list → user confirms → a todo line appended as a delegation — the todo page's existing 'append upon delegation' semantics; nothing written automatically, no todo dependency edge; the 30-day expiry window is hard-coded, refine through use
+  - Asset linking across plugins establishes no dependency: invoice photos materialized in vault, linked via wikilink — the user-profile evidence-domain precedent
+  - Static facts carry no TTL: the device block mapping gets no stale_after — not a pulled artifact, no expiry semantics; trust optional, human registration being itself human evidence
+  - Tool-environment summary section (2026-10-04 v0.2): the body's `## Tool Environment` records presence-level info on connectors/runtimes/channels — a cross-device lookup registry (the AGENTS shell reaches only this machine; device pages cover all relevant devices, the shell pointing to the pages); presence-level granularity prevents drift (exact versions looked up live), synced when software is (un)installed; no full software inventory — 'what should be known is not stored; it is computed on demand'
+- **Rejected alternatives**:
+  - Establishing a domain (the domain family): devices are not an external source, no adapter, no pulling — rejected
+  - An independent territory wiki/devices/: high structural cost, notes retrieval already covers it — rejected
+  - A device command: registration is low-frequency (only when a new device is bought), conversational editing suffices, no command-count bloat — rejected
+  - Automatic writes to todo: contrary to the 'disposal goes through confirmation' convention — rejected
+- **Mechanism back-references**: notes territory rules and the append-only discipline; trust events (verified appended with each review); todo append-upon-delegation; the attached-audit contract scripts/check.py
+
+## Structure
+
+- `wiki/notes/` one page per device: type: entity (suggested form, open); page name free, same names disambiguated by suffix
+- `device` block mapping: serial / purchased / warranty_until minimal key set, the rest open; invoice photos materialized in vault, linked via wikilink
+- Zero commands: registration via conversational editing, retrieval via query, expiry via the attached audit
+
+## Invariants
+
+- One page per device; the notes append-only discipline applies; deletion and modification remain the human's freedom
+- Nothing enumerated beyond the minimal key set — instances extend fields freely
+- Expiry disposal always goes through user confirmation; the attached audit only reports, never writes; a todo line = trigger condition (expiry date) + one sentence + by/at
+- Real-time status monitoring and control, and team device lending registration are not done — scope boundary; the tool environment is a semi-static summary, not real-time status, and may be recorded
+- Static facts carry no stale_after; trust is optional, human registration naturally carrying human evidence
+
+## Changelog
+
+- 0.4 (2026-10-06) inject line: sections lost to the kernel comment-strip clip restored (quoted values are now protected), tightened for budget headroom — issue #12 post-migration nit- 0.3 (2026-10-06) inject line compressed to pointer density (issue #12 layer discipline) — procedural detail lives in usage / PLUGIN.md / skills- 0.2 2026-10-04: added the tool-environment summary section — the body's `## Tool Environment` records presence-level info on connectors/runtimes/channels, a cross-device lookup registry, the AGENTS shell pointing to the pages; presence-level granularity, (un)install syncing, no full inventory
+- 0.1 2026-10-04: established — reusing the notes territory (type: entity suggested), the device block mapping minimal key set, the attached-audit expiry scan (30-day window), expiry entering todo via delegation and confirmation; zero commands; depends wiki

package/.meta/plugins/core/device/PLUGIN.yaml

@@ -0,0 +1,21 @@
+id: device
+schema_version: 1
+version: 0.4
+depends:
+  - wiki
+updated: 2026-10-06
+attachment:
+  - "wiki/notes/ — home of device profile pages (one page per device, type: entity suggested, device block mapping registering serial/purchase/warranty)"
+  - "scripts/check.py — attached audit (warranty_until within 30 days of expiry / already expired → warning list)"
+fields:
+  device: block mapping (device profile page in notes) — serial (serial number) / purchased (purchase date YYYY-MM-DD) / warranty_until (warranty or coverage end date YYYY-MM-DD, the attached-audit scan item), a three-key minimal set; remaining keys open (model, vendor, etc.; the architecture does not enumerate)
+inject: "Device profiles: one page per personal device in wiki/notes/ (type: entity suggested); device block mapping minimal keys serial/purchased/warranty_until, rest open; body ## Tool Environment = presence-level connector/runtime/channel registry for cross-device lookup (synced on (un)install, no full inventory); invoice assets via vault + wikilink; attached audit scans warranty_until (30-day window → warning list; todo line only upon confirmation); no real-time monitoring, no team lending"
+usage:
+  - Registration: natural-language editing in conversation suffices (no command) — one page per device in `wiki/notes/`, type: entity (suggested form); page name free, same names disambiguated by suffix; `device` block mapping minimal keys serial / purchased / warranty_until, remaining keys open
+  - Tool environment: the device page body's `## Tool Environment` summary section — records connector presence (lark-cli, bb-cli, etc.), runtimes (python, node), channels (ssh, web entries) and the device's purpose; only presence-level, never exact versions (look up live); sync this section when software is (un)installed; no full software inventory; this section is the cross-device lookup registry — the AGENTS shell reaches only this machine, device pages cover all relevant devices, the shell pointing to the device pages
+  - Asset linking: invoice, photo, and screenshot assets are materialized in vault and linked to the device page via wikilink; cross-plugin references establish no dependency
+  - Trust: optional — human registration naturally carries human evidence; static facts get no stale_after (not pulled artifacts, no TTL semantics); the tool-environment section is presence-level and likewise carries none
+  - Expiry disposal: the attached audit presents the nearing-expiry list (warranty_until within 30 days or already expired) → reported in session → after user confirmation a todo line is appended as a delegation (trigger condition = expiry date + one sentence + by/at); never written automatically
+  - Retrieval: via the query channel as usual; notes territory rules apply in full (tags applied normally, append-only)
+checks:
+  - Mechanical (attached-audit script `scripts/check.py`, executed discovery-style by audit): device block mapping's warranty_until within ≤30 days of today → warning nearing expiry; already expired → warning expired; invalid date → warning

package/.meta/plugins/core/device/scripts/check.py

@@ -0,0 +1,29 @@
+#!/usr/bin/env python3
+# -*- coding: utf-8 -*-
+"""device plugin attached audit: scan device profile pages for warranty_until near-expiry and expiry.
+
+Near-expiry window is 30 days (hardcoded, adjust as we go); disposal goes through todo upon confirmation — this script only reports.
+"""
+from datetime import date
+
+
+def check(ctx):
+    issues = []
+    today = date.today()
+    for rel, fm, _body in ctx.pages:
+        dev = fm.get("device")
+        if not dev or not isinstance(dev, dict):
+            continue
+        wu = str(dev.get("warranty_until") or "").strip()
+        if not wu:
+            continue
+        try:
+            due = date.fromisoformat(wu)
+        except ValueError:
+            issues.append({"level": "warning", "message": f"{rel}: warranty_until invalid date: {wu}"})
+            continue
+        if due < today:
+            issues.append({"level": "warning", "message": f"{rel}: warranty/coverage expired {wu} (add to todo upon confirmation for disposal)"})
+        elif (due - today).days <= 30:
+            issues.append({"level": "warning", "message": f"{rel}: warranty/coverage near-expiry {wu} (≤30 days; add to todo upon confirmation for disposal)"})
+    return issues

package/.meta/plugins/core/domain/PLUGIN.md

@@ -0,0 +1,43 @@
+# domain: Domain Abstraction
+
+## Design Summary
+
+- **Why it exists**: the **outer root** of the dual-root concept — the ontological declaration of "outer": wiki recognizes only inner and outer; a domain is the form in which information sources outside wiki exist, i.e. an adapter contract waiting to be filled in. A concept-declaration plugin: it establishes the abstraction, laws, and disciplines; concrete domains are instantiated via depends edges — the source of the domain growth mechanism, see Section 8 of mechanics
+- **Key rulings**:
+  - Six contract questions: external territory, landing strategy, identity proof, wiki-side territory, write model, trust model. Designing a domain means answering them one by one
+  - Three laws: landing is essentially a write-model choice; translation cost determines projection density; governance pages live inside wiki, governance targets outside
+  - Two disciplines plus the admission ticket: borrowing vault or pointers is the default posture, self-standing containers are the exception — when to except: write-model divergence, or structural-rigidity divergence; domains must be discoverable within wiki; reconcilability is the admission ticket — relics whose source has already vanished do not establish a domain, they belong to the native territory
+  - Instantiation is expressed entirely in the depends graph: domain bases connect directly to this plugin, in-domain plugins belong to their domain transitively; inner-side plugins attach to wiki, not to this plugin
+
+## Structure
+
+No structure or files of its own. Instantiation is expressed entirely in the depends graph: domain-base plugins depend directly on this plugin; in-domain plugins depend on their respective domains — e.g. structure depends on vault, lark-docs depends on lark — transitivity means membership; inner-side plugins such as notes and sessions attach to wiki, not to this plugin.
+
+## Invariants
+
+Six contract questions, each domain answers for itself:
+
+- External territory — where the information lives: `vault/`, systems reachable via lark-cli, `projects/**`
+- Landing strategy — materialize via vault, self-standing container, pointer without landing
+- Identity proof — vault uses path plus hash; lark uses a one-to-one token-to-page mapping; project uses path plus a two-way diff against the declaration page
+- Wiki-side territory — where the domain's projection pages live: `wiki/vault/`, `wiki/lark/<profile>/`, declaration pages; territory paths are self-disclosed by each domain's injection line
+- Write model — append-only, full read/write, regenerable overwrite
+- Trust model — immutable originals, lazy TTL refresh, living documents
+
+Three laws:
+
+- The landing choice is essentially a write-model choice: final-state assets go into an append-only repository, e.g. vault; process containers get full read/write, e.g. project; when truth lives elsewhere, use pointers, e.g. lark
+- Translation cost determines projection density: arbitrary formats take a 1:1 mirror; behind APIs take pointer pages; md-native takes declaration-only disclosure
+- Governance pages inside wiki, governance targets outside — structure.md and profile.md share the same shape
+
+Two disciplines:
+
+- Borrowing vault or pointers is the default posture, self-standing containers are the exception — when to except: write-model or structural-rigidity divergence; project landing in vault would be crippled, that is the paradigm case
+- Domains must be discoverable within wiki: declaration page or injection line; unregistered means nonexistent
+- A domain's admission ticket is reconcilability: the external territory is alive and accessible, identity proof can be established, and the wiki-side territory path is stated within the domain declaration — only when all three are in place may a domain be established; relics whose source has already vanished, e.g. session minutes — once the conversation runtime vanishes the page is the true body — do not establish a domain, they belong to the native territory
+
+Where the entropy goes: cross-domain semantic disambiguation is completed at adapter write time, reads rely on path origin; within wiki the vocabulary stays unified and the link graph fully connected; the tag doctrine is untouched, free growth within domains keeps holding.
+
+## Changelog
+
+- 0.1 2026-09-22: established — distilled from the 2026-09-19 domain problem report and four rounds of discussion; the three instances vault, lark, and project brought into compliance first

package/.meta/plugins/core/domain/PLUGIN.yaml

@@ -0,0 +1,8 @@
+id: domain
+schema_version: 1
+version: 0.1
+depends: []
+updated: 2026-10-06
+attachment: []
+fields: {}
+inject: "Domain abstraction (outer): wiki recognizes only the inner/outer distinction; an outer domain = an adapter contract (external territory / landing strategy / identity proof / wiki-side territory / write model / trust model), declared by each domain plugin itself, with in-domain plugins belonging to the domain transitively; landing is essentially a write-model choice (final-state assets → append-only repository, process container → full read/write, truth elsewhere → pointer), and projection density follows translation cost (mirror / pointer / disclosure-only); borrowing vault or pointers is the default posture, self-standing containers are the exception (criteria: write-model or structural-rigidity divergence); a domain must be discoverable within wiki (declaration page or injection line)"