arscontexta 0.6.0

package/reference/three-spaces.md

@@ -0,0 +1,363 @@
+# Three-Space Architecture Reference
+
+Every generated system divides its workspace into three spaces: self, notes, and ops. This is not an organizational preference but an architectural decision driven by failure mode prevention. The three spaces have fundamentally different durability profiles, growth patterns, and query characteristics. Conflating any two produces predictable, documented failures.
+
+---
+
+## Self Space — The Agent's Persistent Mind (Configurable)
+
+**Enforcement:** Configurable. Off by default for research vaults, on by default for personal assistant vaults. Toggled via /architect.
+
+**Durability:** Permanent. Content accumulates slowly and is rarely deleted.
+
+**Growth pattern:** Slow — tens of files, not hundreds. Updated incrementally at session end, not batch-processed.
+
+**Load pattern:** Full load at every session start. Small enough to fit in context without progressive disclosure.
+
+**Purpose:** The agent must remember who it is before doing anything else. Without self/, every session starts from zero — the agent knows methodology but not identity, goals, or accumulated operational wisdom.
+
+### When Self Space Is Enabled
+
+#### Core Files
+
+| File | Contents | Update Trigger |
+|------|----------|----------------|
+| `identity.md` | Who the agent is — personality, voice, approach, values | Rarely (personality doesn't change often) |
+| `methodology.md` | How the agent works — quality standards, processing principles, operational patterns | When operational learnings accumulate (evolves as agent learns) |
+| `goals.md` | Current threads — what's active, deferred, completed | Every session (the orientation file) |
+
+#### Optional Extensions (generated based on configuration)
+
+| File/Directory | Included When | Purpose |
+|---------------|---------------|---------|
+| `relationships.md` | Domain involves multiple people | Key people, preferences, interaction patterns |
+| `memory/` | Agent needs atomic self-knowledge beyond core files | Prose-titled atomic notes mirroring the notes/ pattern |
+| `journal/` | Agent captures raw session observations | Processing input for self-knowledge — analogous to inbox |
+| `sessions/` | Session logs need graduated storage | Session-specific logs that might graduate to memory/ or methodology.md |
+
+### When Self Space Is Disabled
+
+When self/ is off (the default for research vaults), the essential functions route elsewhere:
+
+| Function | Fallback Location | Notes |
+|----------|-------------------|-------|
+| Goals / orientation | `ops/goals.md` | Current threads, active work — the session orientation file |
+| Methodology / self-knowledge | `ops/methodology/` | Vault configuration rationale, pipeline config, evolution history |
+| Identity | Context file | Agent personality baked into the context file directly |
+
+The key insight is that self/ serves two distinct purposes: (1) agent identity/personality and (2) operational orientation. Research vaults typically do not need a persistent agent personality — the context file handles identity. Operational orientation (goals, methodology) routes to ops/ where it belongs alongside other operational state.
+
+### Toggle Mechanism
+
+Self space is toggled via `/architect`:
+
+```
+/architect enable self    # Creates self/ with identity.md, methodology.md, goals.md
+/architect disable self   # Migrates goals to ops/goals.md, archives self/
+```
+
+The toggle preserves content — disabling self/ moves goals to ops/ rather than deleting them. Enabling self/ creates the directory and scaffolds the core files.
+
+### Design Rule
+
+**Only what the agent needs about itself.** Self/ is not a second knowledge graph — it holds agent identity, operational learning, and current orientation. Domain knowledge lives in notes/. Processing scaffolding lives in ops/. Self/ answers: "Who am I? How do I work? What am I working on?"
+
+### The Session Rhythm Integration
+
+Self space integrates with the session rhythm primitive, but is not required by it:
+
+```
+Orient -> read orientation state (self/ if enabled, ops/goals.md if not)
+Work   -> do the actual task, surface connections
+Persist -> update orientation state (self/ or ops/goals.md)
+```
+
+The session rhythm primitive depends on markdown-yaml, not on self-space. When self/ is disabled, the orient/persist cycle still works — it just reads from and writes to ops/ instead. The context file always provides methodology and identity; self/ adds a richer, evolving layer on top.
+
+---
+
+## Notes Space — The User's Knowledge Graph
+
+**Durability:** Permanent. Everything here should be worth finding again.
+
+**Growth pattern:** Steady — varies by domain and processing intensity. Research vaults grow at 10-50 claims/week. Companion vaults grow at 2-5 memories/week.
+
+**Load pattern:** Progressive disclosure. Too large to load fully. Use MOC navigation, description queries, semantic search, and link traversal to find relevant content.
+
+**Purpose:** The reason the system exists. The user's intellectual workspace where knowledge compounds through connections.
+
+### Structural Constants (from the kernel)
+
+These hold across all generated systems:
+
+| Constant | Implementation | Why It's Universal |
+|----------|---------------|-------------------|
+| Flat folder | No subfolders for organization | Prevents folder reorganization from breaking links |
+| Prose-sentence titles | Each note makes one claim, titled as a sentence | Enables wiki-link-as-prose pattern |
+| MOC navigation | Hub -> domain -> topic -> notes | Manages attention at scale |
+| Wiki links | `[[note title]]` creates graph edges | Spreading activation without infrastructure |
+| Topics footer | Every note declares MOC membership | Bidirectional navigation |
+
+### What Varies by Domain
+
+| Aspect | Universal Pattern | Domain Adaptation |
+|--------|-------------------|-------------------|
+| Folder name | `notes/` | Vocabulary transform: `reflections/`, `concepts/`, `decisions/`, `memories/` |
+| Note title style | Prose sentence | Domain phrasing: "client showed progress on..." vs "the evidence suggests..." |
+| Schema fields | `description`, `topics` | Domain fields: `person`, `session_date`, `confidence`, `alternatives` |
+| MOC vocabulary | Hub, domain, topic | Domain groupings: "themes", "project areas", "study guides" |
+
+### Design Rule
+
+**Durable, composable, worth finding again.** If it won't be queried or linked, it doesn't belong here. Session-specific observations start in ops/ and get promoted when they earn permanence. Raw capture starts in inbox/ and gets processed into notes/ through the processing pipeline.
+
+### What Does NOT Belong in Notes
+
+- Processing queue state -> ops/queue/
+- Session logs -> ops/sessions/
+- Agent self-knowledge -> self/
+- Health reports -> ops/health/
+- Temporary scaffolding -> ops/
+
+---
+
+## Ops Space — Operational Coordination
+
+**Durability:** Temporal. Content flows through, gets processed, and either graduates or gets archived.
+
+**Growth pattern:** Fluctuating — grows during active work, shrinks during maintenance. Nothing in ops/ is permanent knowledge.
+
+**Load pattern:** Targeted. Queue status, today's session log, latest health report. Never loaded in bulk.
+
+**Purpose:** Keep the knowledge graph clean by separating operational scaffolding from durable knowledge. Without ops/, session logs, queue state, and health reports accumulate alongside genuine insights, polluting search results and inflating note counts.
+
+### Contents
+
+| Directory | Contents | Lifecycle |
+|-----------|----------|-----------|
+| `derivation.md` | The original derivation rationale — dimension positions, tradition mapping, vocabulary choices, rationale for each decision | Semi-permanent — updated only during reseed |
+| `derivation-manifest.md` | Version tracking — arscontexta version, research snapshot date, feature blocks enabled, coherence validation results | Semi-permanent — updated during reseed |
+| `reminders.md` | User-delegated time-bound actions — flat markdown, checked at orient, items removed on completion | Active rotation — items added and removed regularly |
+| `sessions/` | Session logs — what happened today, handoff notes for next session | Rolling archive — logs older than 30 days can be archived without knowledge loss |
+| `health/` | Schema validation results, orphan lists, link health metrics — point-in-time snapshots | Superseding — yesterday's report is superseded by today's |
+| `observations/` | Operational learnings captured during work — pre-promotion holding area | Graduating — observations get promoted to notes/ or self/ when they earn permanence |
+| `queue/` | Processing queue state — what needs extraction, connection, verification | Flowing — items move through and complete |
+| `user-overrides.md` | User customizations that reseed must preserve as immutable | Semi-permanent — grows as user modifies generated content |
+
+### Reminders Specification
+
+`ops/reminders.md` is a flat markdown file for user-delegated time-bound actions:
+
+```markdown
+# Reminders
+
+- [ ] 2026-02-15: Follow up with Sarah about the new job
+- [ ] 2026-03-01: Follow up with Sarah about job offer
+- [x] 2026-02-10: Send reading list to Alex (done 2026-02-10)
+```
+
+**Behavior:**
+- Checked at orient (session start) — due items surface in the morning briefing
+- Completed items are marked with `[x]` and date, then archived when the list grows long
+- No complex scheduling — if the user needs recurring reminders, that's a different tool
+
+### Content Promotion Rule
+
+**Content moves from temporal to durable, never the reverse.** Promotion is one-directional:
+
+```
+ops/observations/ -> notes/ (when observation proves durable)
+ops/observations/ -> self/methodology.md (when observation is about agent operation)
+ops/sessions/ -> self/memory/ (when session insight is personally significant)
+```
+
+Content never moves FROM notes/ or self/ INTO ops/. Durable knowledge doesn't become temporal scaffolding.
+
+### The Promotion Pattern
+
+1. Content enters ops/ at low ceremony (friction logs, session notes, queue entries)
+2. When it demonstrates persistence — same observation recurs, insight proves useful across sessions, pattern is confirmed — it gets promoted
+3. Promotion means creating a proper note in notes/ or adding to self/, not moving the ops entry
+4. The ops entry can then be archived, its value extracted
+
+---
+
+## Six Failure Modes of Conflation
+
+Each conflation pattern produces specific, predictable failures:
+
+### 1. Ops into Notes
+
+**What happens:** Processing queue state, session logs, and health reports end up in the notes/ directory alongside genuine insights.
+
+**What breaks:** Search returns processing debris alongside real knowledge. Note counts are inflated with temporal content. MOCs accumulate operational entries that don't belong. The knowledge graph becomes noisy — an agent searching for "learning patterns" finds session log mentions alongside genuine claims.
+
+**Example:** A session log that says "processed 5 papers today, found connection between X and Y" gets filed in notes/. The connection between X and Y should be a note; the processing status should not.
+
+### 2. Self into Notes
+
+**What happens:** Agent identity, preferences, and operational methodology end up in the user's knowledge graph.
+
+**What breaks:** Schema confusion — agent self-knowledge has different fields than domain knowledge. Search pollution — "how I process therapy reflections" is agent methodology, not a therapy insight. The user's graph contains content about the agent rather than about the domain. Progressive disclosure loads agent self-knowledge when searching for domain content.
+
+**Example:** An agent note saying "I work best when processing in small batches" gets filed alongside user's therapy reflections.
+
+### 3. Notes into Ops
+
+**What happens:** Genuine insights stay trapped in session logs or observation files, never becoming permanent notes.
+
+**What breaks:** Insights are lost when ops/ is archived or purged. Knowledge doesn't compound because session-trapped insights can't be linked from other notes. The user has to re-discover insights that were already captured but never promoted. The vault appears thinner than the work invested would suggest.
+
+**Example:** A session log captures "realized that morning anxiety correlates with skipping exercise" but it never becomes a proper note in reflections/. Three months later, the session log is archived and the insight is effectively gone.
+
+### 4. Self into Ops
+
+**What happens:** Agent identity is scattered across 50 session logs instead of curated in self/ files.
+
+**What breaks:** Orientation fails — the agent can't load 50 session logs to remember who it is. Identity drifts because there's no authoritative source. Session logs that mention identity ("I should be more direct") don't accumulate into identity evolution — they're temporal artifacts.
+
+**Example:** The agent's evolving understanding of its voice is spread across session notes instead of living in self/identity.md where it can be loaded, refined, and maintained.
+
+### 5. Ops into Self
+
+**What happens:** Agent identity gets polluted with temporal processing state — today's queue status, current health metrics, in-progress session context.
+
+**What breaks:** Self/ becomes too large to load fully at session start. Temporal content creates noise in identity orientation. The agent's self-model includes "I have 12 items in queue" as if it were identity rather than current state.
+
+**Example:** self/methodology.md includes "currently processing the Johnson 2026 paper" — which is ops state, not methodology.
+
+### 6. Notes into Self
+
+**What happens:** Domain knowledge gets stored in self/ because it felt personally relevant to the agent.
+
+**What breaks:** Self/ bloats beyond what can be loaded at session start. The agent carries domain-specific knowledge as identity, which doesn't scale. Search in notes/ misses content that's hidden in self/. The distinction between "what the agent knows about itself" and "what the agent knows about the domain" collapses.
+
+**Example:** A research agent stores "spaced repetition works better after exercise" in self/memory/ instead of notes/. It's domain knowledge, not agent self-knowledge — even though the agent found it interesting.
+
+---
+
+## Filesystem Layout
+
+### Claude Code Platform
+
+```
+project-root/
+├── CLAUDE.md                    # context file (methodology + operational instructions)
+├── .claude/
+│   ├── hooks/                   # event-driven automation
+│   ├── skills/                  # methodology-as-code
+│   └── settings.json            # platform configuration
+├── self/
+│   ├── identity.md
+│   ├── methodology.md
+│   ├── goals.md
+│   ├── relationships.md         # optional
+│   ├── memory/                  # optional
+│   └── journal/                 # optional
+├── notes/                       # or domain-specific name (reflections/, concepts/, etc.)
+│   ├── index.md                 # hub MOC
+│   ├── [domain-mocs].md         # domain/topic MOCs
+│   └── [prose-titled-notes].md  # atomic notes
+├── inbox/                       # or domain-specific name (journal/, encounters/, etc.)
+├── archive/                     # processed sources
+├── templates/                   # note templates
+└── ops/
+    ├── derivation.md
+    ├── derivation-manifest.md
+    ├── reminders.md
+    ├── user-overrides.md
+    ├── sessions/
+    ├── health/
+    ├── observations/
+    └── queue/
+```
+
+### OpenClaw Platform
+
+```
+workspace/
+├── SOUL.md                      # agent identity (references self/)
+├── AGENTS.md                    # operational instructions
+├── USER.md                      # user preferences
+├── MEMORY.md                    # memory system orientation
+├── self/
+│   ├── identity.md
+│   ├── methodology.md
+│   ├── goals.md
+│   └── memory/
+├── notes/                       # or domain-specific name
+│   ├── index.md
+│   └── [notes].md
+├── inbox/                       # or domain-specific name
+├── archive/
+├── templates/
+├── skills/                      # OpenClaw external skills
+│   └── [skill-name]/
+└── ops/
+    ├── derivation.md
+    ├── derivation-manifest.md
+    ├── reminders.md
+    ├── sessions/
+    ├── health/
+    ├── observations/
+    └── queue/
+```
+
+### Differences Between Platforms
+
+| Aspect | Claude Code | OpenClaw |
+|--------|-----------|----------|
+| Context file | CLAUDE.md (single file) | SOUL.md + AGENTS.md + USER.md + MEMORY.md |
+| Hooks | .claude/hooks/ (bash) | command hooks (TypeScript) |
+| Skills | .claude/skills/ | skills/ (external skills) |
+| Session start | Hook auto-injects tree | Must load MEMORY.md manually |
+| Self/ structure | Identical | Identical |
+| Notes/ structure | Identical | Identical |
+| Ops/ structure | Identical | Identical |
+
+**The principle:** The three-space architecture is platform-invariant. Only the context file format and automation infrastructure differ between platforms. The intellectual workspace (self/, notes/, ops/) is structurally identical.
+
+---
+
+## Memory Type Routing Decision Tree
+
+When the agent captures something, this decision tree determines where it belongs:
+
+```
+Is this about the agent itself?
+├── YES: Is it durable self-knowledge?
+│   ├── YES -> self/ (identity, methodology, goals, memory)
+│   └── NO -> ops/ (session log, current processing state)
+│
+└── NO: Is this domain knowledge?
+    ├── YES: Is it durable, composable, worth finding again?
+    │   ├── YES -> notes/ (atomic note with proper schema)
+    │   └── NO -> ops/ (observation, friction log, session note)
+    │       └── May be promoted to notes/ later if it persists
+    │
+    └── NO: Is this operational coordination?
+        └── YES -> ops/ (queue state, health report, session handoff)
+```
+
+**Quick routing rules:**
+
+| Content Type | Destination | Why |
+|-------------|-------------|-----|
+| "I work best when..." | self/methodology.md | Agent operational learning |
+| "The user prefers..." | self/relationships.md | Agent knowledge about user |
+| "Today I processed..." | ops/sessions/ | Temporal processing state |
+| "Spaced repetition helps memory" | notes/ | Domain knowledge |
+| "The reduce skill over-extracts" | ops/observations/ | Operational friction (may promote) |
+| "Queue has 12 items" | ops/queue/ | Temporal coordination state |
+| "Schema validation passed" | ops/health/ | Point-in-time diagnostic |
+| "My goal this quarter is..." | self/goals.md | Agent orientation |
+| "Remember to follow up by Friday" | ops/reminders.md | Time-bound action |
+
+---
+
+## Cross-Reference
+
+- **Failure modes that afflict each space:** See `failure-modes.md` for the full failure mode taxonomy. Conflation failures (this document) are structural; failure-modes.md covers operational decay (collector's fallacy, orphan drift, schema erosion).
+- **How personality affects each space:** See `personality-layer.md` for how warmth/formality dimensions change the voice of self/identity.md, skill instructions, and health reports.
+- **What goes in each space per domain:** See `use-case-presets.md` for domain-specific routing decisions (therapy reflections vs research claims vs PM decisions).
+- **Kernel primitives that depend on three-space separation:** `self-space` (configurable), `session-rhythm`, `discovery-first`, `task-stack`, `methodology-folder`, and `session-capture` all assume clean space boundaries. See `kernel.yaml`.

package/reference/tradition-presets.md

@@ -0,0 +1,203 @@
+# Methodology Tradition Presets
+
+Named points in configuration space. Each tradition represents a region where dimension interactions have been resolved through practice. Traditions are starting points for derivation, not templates to copy.
+
+---
+
+## The Configuration View
+
+Traditions are not competing paradigms but different trade-off choices along shared dimensions. Zettelkasten maximizes connection density at the cost of heavy processing. PARA maximizes project organization at the cost of cross-domain synthesis. Each optimizes for a different purpose.
+
+Derived systems can mix choices across traditions when the mixing is principled — each dimension choice justified independently by research claims, with interaction constraints checked for coherence.
+
+---
+
+## Tradition Configurations
+
+### Zettelkasten
+
+**Optimizes for:** Deep synthesis, connection density, long-term knowledge accumulation
+
+| Dimension | Value | Rationale |
+|-----------|-------|-----------|
+| Granularity | atomic | One claim per note maximizes composability and reuse |
+| Organization | flat | Associative ontology adapts while hierarchy brittles |
+| Linking | explicit, bidirectional | Dense typed connections are the primary value mechanism |
+| Processing | heavy (formulation + linking) | Careful formulation at creation time ensures quality |
+| Navigation | 3-4 tier (emergent hubs) | Deep hierarchy manages attention across thousands of notes |
+| Maintenance | continuous | Living documents, not finished artifacts |
+| Schema | moderate | Enough for querying, not so much as to impede capture |
+| Automation | convention | Traditionally manual; agent operation enables automation |
+
+**Process step:** Formulate — transform source material into your own words as a falsifiable claim.
+
+**Coherence signature:** The highest-commitment configuration. Every dimension is at its intensive pole. Internally consistent because heavy processing sustains atomic granularity's demands. Breaks when processing discipline lapses (notes created but never connected).
+
+**Best for:** Research, academic work, long-term intellectual projects, concept-heavy domains.
+
+---
+
+### PARA (Projects, Areas, Resources, Archive)
+
+**Optimizes for:** Project execution, actionable organization, quick filing
+
+| Dimension | Value | Rationale |
+|-----------|-------|-----------|
+| Granularity | coarse | Topic-level or project-level documents |
+| Organization | hierarchical (4 folders) | Clear filing taxonomy reduces decision fatigue |
+| Linking | minimal (folder membership) | Folder placement IS the primary organizational mechanism |
+| Processing | light (progressive summarization) | Highlight → bold → summarize, minimal transformation |
+| Navigation | 2 tier (folder browsing) | Four top-level folders, project subfolders |
+| Maintenance | condition-based review | Triage when project status changes accumulate |
+| Schema | minimal | Actionability field (project vs area vs resource) |
+| Automation | manual | Designed for human operation with minimal tooling |
+
+**Process step:** Summarize — progressively distill highlights without transformation.
+
+**Coherence signature:** The lowest-commitment configuration. Everything at the extensive pole. Internally consistent because coarse notes with minimal linking don't demand deep processing. Breaks when cross-domain synthesis is needed (folder silos prevent connection finding).
+
+**Best for:** Project management, task-heavy workflows, getting things done, storage-oriented systems.
+
+---
+
+### Evergreen Notes (Andy Matuschak)
+
+**Optimizes for:** Evolving understanding, continuous refinement, living knowledge
+
+| Dimension | Value | Rationale |
+|-----------|-------|-----------|
+| Granularity | atomic | Concept-oriented, one idea per note |
+| Organization | flat | No folder hierarchy; links define structure |
+| Linking | explicit, contextual | Links with surrounding prose context explain WHY |
+| Processing | heavy (continuous rewriting) | Notes evolve over time through repeated revisiting |
+| Navigation | 3 tier (link browsing) | Follow connections, not categories |
+| Maintenance | continuous | "Evergreen" means perpetual growth and revision |
+| Schema | moderate | Enough metadata to support discovery |
+| Automation | convention | Designed for personal practice; automation optional |
+
+**Process step:** Rewrite — revisit and improve notes as understanding deepens, rather than formulating once.
+
+**Coherence signature:** Similar to Zettelkasten but diverges on processing philosophy: continuous rewriting vs. careful initial formulation. The temporal dimension of processing differs even though intensity is comparable. Breaks when revision never happens (aspirational evergreen that's actually write-once).
+
+**Best for:** Personal knowledge development, conceptual exploration, writing projects, intellectual growth.
+
+---
+
+### Cornell Note-Taking System
+
+**Optimizes for:** Structured review, testing effect, retention
+
+| Dimension | Value | Rationale |
+|-----------|-------|-----------|
+| Granularity | medium (per-session) | One document per lecture/session, structured internally |
+| Organization | temporal | Chronological primary axis |
+| Linking | implicit (cue columns) | Cue column creates retrieval prompts, not explicit graph edges |
+| Processing | heavy (5 Rs structured) | Record → Reduce → Recite → Reflect → Review |
+| Navigation | 2-3 tier (index-based) | Master index points to session documents |
+| Maintenance | spaced review | Revisiting at increasing intervals based on note maturity |
+| Schema | moderate | Cue/notes/summary structure per document |
+| Automation | convention | Paper-native; agent adaptation requires skill encoding |
+
+**Process step:** Generate cues — create self-testing prompts that force active recall.
+
+**Coherence signature:** The most structured processing pipeline. Each phase has a distinct purpose. Breaks when processing phases are skipped (especially the Recite self-testing step that provides the core retention benefit).
+
+**Best for:** Learning, study, courses, structured knowledge acquisition.
+
+---
+
+### GTD (Getting Things Done)
+
+**Optimizes for:** Stress-free execution, complete capture, context-appropriate action
+
+| Dimension | Value | Rationale |
+|-----------|-------|-----------|
+| Granularity | task-sized | Next actions, not knowledge claims |
+| Organization | hierarchical (contexts) | @context, @project, @waiting-for organize for execution |
+| Linking | minimal | Context membership, not knowledge connections |
+| Processing | light (capture + route) | Quick triage: actionable? → project/action/reference/trash |
+| Navigation | 2 tier (context lists) | Browse by context for situation-appropriate actions |
+| Maintenance | condition-based review | Per-session: today's actions. Threshold-triggered: full system review when items accumulate |
+| Schema | dense (action metadata) | Due dates, contexts, energy levels, priorities |
+| Automation | automation-friendly | Repeating tasks, condition-based triggers, reminders |
+
+**Process step:** Route — classify each item by actionability and context, not by content.
+
+**Coherence signature:** Dense schema with light processing seems contradictory, but the schema IS the processing — classifying an item as @computer/2-minutes/low-energy is the routing that GTD calls processing. Breaks when system review lapses (trust in the system collapses).
+
+**Best for:** Task management, productivity, execution-heavy workflows, operational systems.
+
+---
+
+### Memory Palace (Method of Loci)
+
+**Optimizes for:** Spatial-mnemonic retrieval, vivid association, sequential recall
+
+| Dimension | Value | Rationale |
+|-----------|-------|-----------|
+| Granularity | moderate | Items organized in spatial loci, grouped by room/path |
+| Organization | hierarchical (spatial) | Palace → room → locus creates physical metaphor hierarchy |
+| Linking | explicit (spatial sequence) | Loci connect by physical adjacency in the imagined space |
+| Processing | moderate (visualization) | Creating vivid, unusual images for each locus |
+| Navigation | 3 tier (palace → room → locus) | Spatial navigation provides strong retrieval cues |
+| Maintenance | condition-based (palace review) | Walk the palace when associations weaken or new content needs encoding |
+| Schema | minimal | Location and image descriptors |
+| Automation | manual | Intrinsically human-cognitive; agent adaptation speculative |
+
+**Process step:** Visualize — encode information as vivid spatial-mnemonic images.
+
+**Coherence signature:** The most unusual configuration — spatial rather than textual organization. Breaks when the spatial metaphor is forced onto non-sequential information. Agent adaptation is speculative because the method relies on visual imagination that agents don't have.
+
+**Best for:** Sequential recall, presentation preparation, memorization tasks. Limited applicability for agent-operated systems (no spatial cognition), but the spatial-hierarchical navigation pattern transfers.
+
+---
+
+## Use-Case Presets
+
+These are derived from tradition presets, adapted for specific use cases. Each cell shows the recommended starting position.
+
+| Dimension | Research | Life Mgmt | Learning | Relationships | Therapy | Creative | Companion |
+|-----------|----------|-----------|----------|---------------|---------|----------|-----------|
+| Granularity | atomic | moderate | atomic | moderate | moderate | moderate | coarse |
+| Organization | flat | flat | flat | flat | flat | flat | flat |
+| Linking | explicit+implicit | explicit | explicit+implicit | explicit | explicit | explicit+implicit | explicit |
+| Processing | heavy | light | heavy | light | moderate | moderate | light |
+| Nav depth | 3-tier | 2-tier | 3-tier | 2-tier | 2-tier | 2-tier | 2-tier |
+| Maintenance | condition-based (tight) | condition-based (lax) | condition-based (tight) | condition-based (lax) | condition-based (tight) | condition-based (lax) | condition-based (lax) |
+| Schema | moderate | minimal | moderate | moderate | moderate | minimal | minimal |
+| Automation | convention | convention | convention | convention | convention | convention | convention |
+
+**Derivation from traditions:**
+- Research → primarily Zettelkasten, with Cornell processing phases (the 6 Rs)
+- Life Management → PARA-influenced, with flat organization (Zettelkasten adaptation)
+- Learning → Cornell core, with Zettelkasten atomicity for long-term retention
+- Relationships → custom — moderate schema for preference tracking, light processing
+- Therapy → custom — moderate processing for pattern detection, tight condition-based review for continuity
+- Creative → Evergreen-influenced — living ideas that evolve through revisiting
+- Companion → lightest configuration — memory building without processing overhead
+
+**Why flat organization for all:** The research strongly favors flat-associative for agent-operated systems. Hierarchy can be added via MOCs without folder nesting. This is the one dimension where the recommendation holds across all use cases.
+
+**Why convention automation for all:** Following Gall's Law (complex systems evolve from simple working systems), all systems start at convention level. Users add automation at friction points rather than deploying full automation from day one.
+
+**Automation upgrades per platform:** The presets above are the floor, not the ceiling. During init, tier-1 platforms (Claude Code) should prompt the user about adding hooks-blueprint and validation-hooks. A Research use case on Claude Code can reasonably start at "convention trending toward automation" — the preset is the starting point, and the init wizard should suggest upgrades when the platform supports them.
+
+---
+
+## Mixing Traditions
+
+When a user selects "Custom / Mixed" in the init wizard, present traditions as reference points:
+
+1. **Show the tradition presets table** — each row is a coherent starting point
+2. **Let user pick per-dimension** — selecting values from different traditions
+3. **Check interaction constraints** — flag combinations where traditions conflict
+4. **Document the mix** — include which tradition each choice came from in the derivation rationale
+
+**Valid mixing examples:**
+- Zettelkasten atomicity + Cornell processing phases + PARA project folders = research system with structured extraction and active project tracking
+- Evergreen continuous rewriting + GTD condition-based review = creative system with disciplined maintenance
+
+**Invalid mixing (interaction constraints fire):**
+- Zettelkasten atomicity + PARA minimal linking → atomic notes need explicit connections
+- GTD dense schema + Zettelkasten manual operation → dense schemas need validation support
+- Memory Palace spatial hierarchy + Evergreen flat organization → contradictory organizational principles