RFC: First-Class Construct Support in Loa

[zkSoju]

Intent & Purpose

Loa should support how people actually work — not prescribe how they should work.

Everyone is different. Some people work like a dagger — singular focus, one context window, precise cuts until the problem is solved. Some work like a conductor — steering between perspectives, composing on the fly, mode-switching when the energy shifts. And there are styles we haven't seen yet. The diversity of human cognition means there will always be more ways to work than we can anticipate.

Constructs are expertise packaged as composable building blocks. Loa is the environment where those blocks get assembled into personal workflows. The Operator OS — where a user defines named modes mapped to construct compositions — is one methodology for this, designed by one user for their own ADHD-aware cognitive patterns. It's not universal. It's an example of what becomes possible when the environment supports evolution.

The framework's job is not to build tools for other people. It's to build structure that helps people do deeper work for themselves and better learn how they work. It's just a game. There's many ways to play and no right way to play. We provide an environment where evolution can happen.

This RFC proposes the infrastructure to make that environment real: a construct index for awareness, name resolution for activation, composition pipes for connecting constructs, and ambient presence so the framework is there when you need it and invisible when you don't.

---

Context

This RFC emerges from a deep DX session examining how constructs should integrate with Loa, grounded in a full bazaar audit of all 24 live constructs and research into progressive disclosure patterns from game design (RuneScape, Dark Souls, BOTW) and developer ecosystems (skills.sh, lazy.nvim, Homebrew).

Companion RFC: loa-constructs#181 covers the network side — install surface, explorer, and schema hygiene sprint.

Origin: Conversation between @janitooor and @zkSoju about better tooling support when not on golden path rails, and first-class support for the constructs network.

Problem Statement

Construct composition already happens in practice. Users manually orchestrate multi-construct workflows — naming agents by construct in TeamCreate, piping dig findings into observer canvases, getting adversarial review from construct-specific perspectives. The pattern is proven. The infrastructure to support it consistently is missing. This RFC makes explicit what's already implicit.

Loa creates awareness of constructs but not to the precision needed for natural use.

The Concrete Failure

When the user says "observer" or "I want to use K-Hole for deep research," the agent doesn't load the persona or activate the construct context without heavy prompting. Constructs are files in directories. They should be entities with presence.

Composition requires explicit manual invocation every time. "These constructs should work together" requires the user to orchestrate each step. "Adversarial review from these standpoints" requires the user to name each agent, specify each persona, describe the composition. The user IS the pipe. The framework should be.

What Loa Knows vs. What It Should Know

Layer	Current	Needed
Phases	plan, build, review, ship	No change
Modes	Personal cognitive modes (user-defined, e.g. Operator OS)	Modes should compose with constructs via an archetype resolver
Protocols	beads, QMD, flatline	Protocols should run by default and leave ambient evidence — currently they only activate when explicitly named
Constructs	Directories in .claude/constructs/packs/	Name resolution, composition runtime, ambient awareness

The framework knows about phases, modes, and protocols. It does not have a construct layer — no name resolution, no composition routing, no ambient awareness of what's installed or how constructs connect.

The Protocol Consistency Gap

Protocols (beads, QMD, phases) don't run unless the user explicitly names them. If the user says "use beads," it happens. If they don't, it doesn't. QMD gets stale because it's never updated. The agent uses grep instead of QMD. Beads don't track work outside explicit sprints.

The result: the user says "let's wrap this up," the agent revisits what it did. But if the user forgets, the work is abandoned. Open threads are lost because nothing was tracking them.

This isn't "protocols run but aren't visible." Protocols don't run at all unless explicitly invoked. The concierge isn't too intrusive — the concierge isn't at the desk.

The Unix Pipe Gap

The user describes constructs as Unix tools: composable, pipeable, adversarial-reviewable. Examples of what should work consistently:

• "K-Hole's findings should feed Observer" → pipe dig output to observer input
• "Adversarial review from these standpoints" → spawn agents by construct, each brings its expertise
• "These constructs should work together for this" → composition activates automatically

Currently this requires explicit, manual orchestration every time. The user is the pipe. The framework should be.

The Off-Rails Gap

The golden path (/plan → /build → /review → /ship) works for structured projects and is relatively simple — most workflows can map to it. But most daily work is off-rails — visual iteration, quick research, freestyle exploration. This space has no structure.

Important insight: activities like deep research and design exploration are often pre-planning activities. They build context that makes /plan better. They're not alternatives to the golden path — they're inputs to it. The golden path assumes you arrive at /plan already knowing what you want. The pre-planning is how you figure out what you want.

Design Principles

The Hotel Experience Paradox

From Octalysis Group (Yu-kai Chou): the more hotels automate personalization, the less personal it feels. "Not special, but watched."

Loa has the same risk. Protocols that run invisibly feel like a broken surveillance system — you know they're supposed to be watching, but you can't tell what they see. The fix isn't more automation — it's the concierge model:

Hotel Drive	Loa Equivalent
Earned recognition (remember me because we've MET)	Know my constructs because I've USED them, not because you scanned my config
Agency (let me shape the stay)	Let me design my own modes, compose my own constructs, pipe them my way
Surprise & discovery (show me something I didn't know existed)	Surface compositions I haven't tried, constructs adjacent to what I use
Human connection (the staff, not the system)	The persona voice, not the protocol enforcement

The framework should be:

present options → honor the choice → step aside → be there when called

Not:

detect intent → enforce protocol → track compliance → report status

Everyone Works Differently

Loa must support the full spectrum of working styles — not just two, but the unbounded diversity of how people actually think and create:

• The dagger — one context window, singular focus, precise cuts. Golden path rails are natural. Deep task tracking with beads. One problem until it's solved. The entire context window is used for a singular task. Very little steering needed.
• The conductor — multiple perspectives, steering between modes, composing on the fly. Agent swarms / TeamCreate is natural. Quick iteration, visual feedback, mode-switching when the energy shifts.
• Styles we haven't seen yet — every person's cognition is different. Some will be visual-first. Some will be research-first. Some will work in bursts, others in sustained focus. Some will use the golden path for everything. Some will never touch it. We cannot predict the diversity.

The framework doesn't adapt for any single style. It builds the flexibility that supports ALL mental models. The Operator OS (FEEL/ARCH/DIG/SHIP modes) is one user's personal cognitive toolkit — designed for their ADHD-aware mode switching. It's not universal. It's an example of what becomes possible when the environment supports self-composition.

Loa's role: help people discover how they work best, not tell them how to work. The modes emerge from use. The compositions emerge from exploration. The personal OS emerges from the person.

Game Design Progressive Disclosure

Three types of progressive disclosure map to three DX surfaces:

Type	Game Reference	Loa Surface
Functional (interface reveals one tab at a time)	RuneScape Tutorial Island	The install CLI — one construct at a time
Spatial (world reveals connections through shortcuts)	Dark Souls interconnected world	The composition graph — connections discovered through use
Systemic (rules reveal depth through emergent combinations)	BOTW's four runes	Construct composition — universal pieces that combine in ways the designers didn't predict

The ecosystem should be felt before it's understood. Not explained, not onboarded — felt. The way RuneScape's skill tab works by always being there. The way Dark Souls' world reveals connections only after you've walked the long way.

Proposals

L1: Construct Index (Keystone — Unblocks Everything)

A machine-readable file generated on session start that maps every installed construct to its activation paths:

# .run/construct-index.yaml (generated by sync-packs.sh extension)
constructs:
  k-hole:
    persona: grimoires/personas/STAMETS.md
    quick_start: /dig
    skills: [dig, deep-research, domain-discovery, ...]
    commands: [dig, forge, discover, config, research]
    writes: [grimoires/k-hole/research-output/]
    reads: []
    gates: {}
    composes_with: []
  observer:
    persona: grimoires/personas/KEEPER.md
    quick_start: /observe
    skills: [observing-users, shaping-journeys, ...]
    commands: [observe, ...]
    writes: [grimoires/laboratory/canvases/, grimoires/laboratory/journeys/]
    reads: [grimoires/k-hole/research-output/]
    gates: {}
    composes_with: [crucible, artisan]

Generated, not authored. sync-packs.sh already runs on session start — extend it to produce this index. The CLAUDE.md instruction tells the agent to check this file when a construct name is mentioned.

Blast radius: One file, one script extension. Non-breaking. Falls back gracefully if file doesn't exist.

Dependency: Requires the network-side schema hygiene sprint (loa-constructs#181 P4) to populate workflow.gates, quick_start, and composition_paths across the 24 stalls.

L2: Name Resolution

When the user says "observer", "use observer", "I want K-Hole's perspective":

1. Look up the name in .run/construct-index.yaml
2. Load the persona file
3. Activate the construct's skill set as primary context
4. Set the construct's read/write paths as active grimoire scope

Implementation: CLAUDE.md instruction addition that references the construct index. No code change needed — the index file does the work.

Note: Command name collisions (/observe = gecko vs observer, /dig = k-hole vs hypha) need to be resolved on the network side first. The index should use construct slugs as the primary identifier, with commands as secondary routing.

L3: Composition as Pipe

When the user says "pipe dig into observe" or "K-Hole's findings should feed Observer":

1. Check construct index for K-Hole's writes paths
2. Check Observer's reads paths
3. Confirm the material chain exists (path overlap)
4. Execute K-Hole's skill, pass output path to Observer's skill

If no material chain exists, the agent says so honestly: "K-Hole writes to grimoires/k-hole/research-output/. Observer doesn't currently read from there. Want me to connect them?"

For TeamCreate composition: When spawning agents named by construct ("observer", "k-hole", "artisan"), each agent should auto-load its persona from the construct index. The naming convention should trigger persona loading:

Agent(name="observer", team_name="review-council")
# → auto-loads KEEPER.md persona, observer skills, observer read/write paths

This makes construct-named teams the standard pattern for multi-perspective work. The user said: "if you label each of the team members by constructs, it'll be very clear to me that these things are happening."

Feedback routing: When a construct-embodied agent identifies an issue, route it to the construct's repo (if declared in construct.yaml repository field), not to Loa. Gecko should be able to walk stalls and open targeted, high-quality issues on construct repos.

L4: Personal Operator OS Support

The golden path is the main quest. Everything else — daily work, visual iteration, research, exploration — is the open world.

Operator OS is a methodology, not a feature. It's the practice of:

1. Noticing which cognitive state you're in
2. Naming it (giving it a mode)
3. Mapping constructs to that mode
4. Trusting the isolation between modes
5. Switching when the energy shifts

One user's implementation: FEEL/ARCH/DIG/SHIP — four modes mapped to constructs (artisan, arcade, k-hole, arcade). Another user might have three modes, or six, or entirely different names. A visual designer might have SKETCH/REFINE/CRITIQUE/SHIP. A security engineer might have SCAN/TRACE/HARDEN/DEPLOY.

What Loa provides:

• Construct composition — combine any constructs into a working set (the "archetype")
• Mode definitions — users can define their own modes, each with a name, construct set, and workflow gates
• Mode switching — when you say a mode name, the archetype activates
• Isolation guarantees — modes don't bleed into each other

The archetype resolver reads installed constructs' workflow.gates and merges them:

# .run/archetype.yaml (example — user-defined, not prescribed)
active_constructs: [observer, artisan, k-hole]
merged_gates:
  prd: skip
  implement: required
  review: visual
entry_point: /observe

When no archetype is active, Loa operates normally. Users opt in by invoking a construct or mode. Never forced. The framework helps people discover how they work — it doesn't tell them how to work.

What Loa does NOT provide:

• A prescribed set of modes
• A "correct" way to compose constructs
• A required workflow for off-rails work

L5: Ambient Protocol Presence

Protocols should run by default and leave ambient evidence — not as blocking gates, but as the concierge being present at the desk.

Protocol defaults:

• QMD: kept warm, preferred over grep for codebase search, updated on file changes
• Beads: lightweight "open threads" mode even outside sprints — tracking discussed items so nothing falls through
• Session greeting: if constructs are active, surface a brief ambient greeting:

Active: k-hole (v1.2.1), artisan (v1.0.0), observer (v3.0.0)
Compositions: k-hole → observer (research → canvases)
Entry: /dig | /feel | /observe
Beads: 3 open threads from previous sessions

Not a dashboard. A greeting from the concierge. Visible when relevant, silent when not.

Open thread awareness: The agent maintains a lightweight log of discussed-but-not-completed items. On session start, surfaces any stale threads: "3 open threads from previous sessions. Want to review?" This is beads-light — the concierge's notepad.

Sequencing

Network P4 (schema hygiene) → L1 (construct index) → L2 (name resolution) → L3/L4/L5

1. Network-side schema hygiene — populate workflow.gates, quick_start, composition_paths across 24 stalls
2. L1 (construct index) — extend sync-packs.sh to generate .run/construct-index.yaml
3. L2 (name resolution) — CLAUDE.md instruction to check index on construct name mention
4. L3 (composition pipe) — path-based composition routing
5. L4 (personal OS support) — archetype resolver reads index + gates
6. L5 (ambient presence) — session greeting + protocol defaults + open thread tracking

L1 is the keystone. Everything flows from the index.

Out of Scope

• Network-side changes (install command, explorer, schema hygiene) → loa-constructs#181
• Construct certification / OSINT verification → separate initiative
• Prescribing specific workflows or mental models → explicitly excluded
• Building a specific Operator OS for all users → the framework supports building personal ones

Questions for Discussion

1. Should the construct index be YAML or JSON? YAML is human-readable, JSON is faster to parse.
2. Should L2 (name resolution) be a CLAUDE.md instruction or a hook? Instruction is simpler. Hook could auto-inject the index into context.
3. How should L3 handle composition when the material chain doesn't exist? Suggest connecting? Auto-create the path? Just warn?
4. Should L5 (ambient greeting) be opt-in or opt-out? The hotel paradox suggests opt-in is safer.
5. How do we support users building their own Operator OS (personal modes, personal workflows) without the framework becoming too flexible to be useful?
6. What should protocol defaults look like? QMD warm by default is useful but has compute cost. Beads tracking open threads by default is useful but adds noise. Where's the line?

---

🤖 Generated with Claude Code

[zkSoju]

Additional Context: Protocol Consistency Gap (from @zkSoju)

The L5 proposal (ambient protocol evidence) understated the problem. The issue isn't "protocols run but aren't visible." Protocols don't run at all unless explicitly invoked.

What's Actually Happening

Protocol	Expected	Actual
QMD	Kept warm, used for semantic search, updated on file changes	Stale. Agent uses grep instead. Only invoked when user explicitly says "use QMD."
Beads	Lightweight task tracking — not sprint-level, just open threads	Not tracking unless user starts a sprint. Work discussed but not completed gets lost.
Phases	Ambient structure even for small tasks	Only activated on golden path. Off-rails work has no structure.

The Forgetting Pattern

The user describes a specific failure mode:

1. User and agent discuss work → some items are identified
2. User says "let's wrap this up" → agent revisits and tries to close loops
3. But if the user doesn't say "let's wrap this up" → agent moves on, work is abandoned
4. Open threads are lost because nothing was tracking them

Beads should solve this — even lightweight tracking of "we discussed X, it's not done yet" would prevent the forgetting pattern. But beads aren't being used outside explicit sprint context.

What This Changes in the RFC

L5 goes from "ambient evidence of protocols" to something deeper:

L5a: Protocols should activate by default, not on mention.

• QMD: keep warm, prefer over grep for codebase search
• Beads: track discussed work items even outside sprints — lightweight "open threads" mode
• The construct index (L1) should include protocol state alongside construct state

L5b: Open thread awareness.
The agent should maintain awareness of discussed-but-not-completed items and surface them:

"We discussed X earlier but didn't close it. Want to revisit?"

This is the concierge remembering you said you wanted a wake-up call — not waiting for you to ask again. It's the difference between the framework being available and the framework being present.

Connection to the Hotel Paradox

The hotel paradox warned against over-automation feeling invasive. But the current state is the opposite problem: under-automation feeling neglectful. The concierge isn't following you to your room (good) — but the concierge also isn't at the desk when you walk through the lobby (bad).

The fix isn't aggressive protocol enforcement. It's ambient awareness with light touch:

• QMD warm in the background → agent silently has better search
• Beads tracking open threads → agent can remind without nagging
• Session greeting showing what's active → user knows the concierge is present

[zkSoju]

Critical Reframe: Operator OS Is a Methodology, Not a Feature

The RFC's L4 (Freestyle Mode) currently says "the four modes ARE the freestyle runes" — mapping /dig, /feel, /systems, /prototype as universal primitives. This is wrong. Those four modes are one user's personal cognitive tools. Prescribing them as the answer is the exact mistake the Hotel Paradox warns against.

The Correction

Operator OS is a methodology for composing constructs into personal workflows that match how YOU work. It's not four specific modes. It's the practice of:

1. Noticing which cognitive state you're in
2. Naming it (giving it a mode)
3. Mapping constructs to that mode (which expertise helps in this state?)
4. Trusting the isolation between modes (FEEL can't break ARCH)
5. Switching when the energy shifts

The four modes (FEEL/ARCH/DIG/SHIP) are one person's implementation of this methodology — designed for ADHD-aware mode switching, grounded in their specific work patterns. Someone else might have three modes, or six, or different names entirely. A visual designer might have SKETCH/REFINE/CRITIQUE/SHIP. A security engineer might have SCAN/TRACE/HARDEN/DEPLOY.

What This Means for L4

L4 should NOT be "four universal runes." L4 should be:

Loa supports building personal Operator OS configurations.

The framework provides:

• Construct composition — combine any constructs into a working set (the "archetype")
• Mode definitions — users can define their own modes, each with a name, a set of constructs, and workflow gates
• Mode switching — when you say a mode name, the archetype activates
• Isolation guarantees — modes don't bleed into each other

The framework does NOT provide:

• A prescribed set of modes
• A "correct" way to compose constructs
• A required workflow for off-rails work

The Game Frame

"It's just a game. There's many ways to play and no right way to play. We provide an environment where evolution can happen."

This is the design philosophy for the entire framework, not just L4:

• Constructs = the pieces (Lego blocks, RuneScape skills, BOTW runes)
• Operator OS = how you compose them (your personal build, your skill loadout, your rune set)
• Loa = the environment (the game world, the physics engine, the sandbox)
• The golden path = the tutorial (one valid way through, not the only way)

The environment enables evolution. It doesn't prescribe form. The user discovers how they work best BY using the tools, not by reading a manual. The modes reveal themselves through practice — "I keep switching to this state when I'm doing visual work, let me name it FEEL" — not through a feature list.

Updated L4 Proposal

L4: Personal Operator OS Support

Instead of hardcoding four modes, Loa should support:

1. Archetype definitions — a user-authored config that maps named modes to construct compositions:

# User's personal operator OS (example — not prescribed)
modes:
  dig:
    constructs: [k-hole]
    persona: STAMETS
    gates: { prd: skip, sprint: skip }
  feel:
    constructs: [artisan, observer]
    persona: ALEXANDER
    gates: { prd: skip, review: visual }

2. Auto-composition — when a mode is invoked, load the constructs, merge gates, activate persona. The archetype resolver already proposed in the RFC does this — it just shouldn't assume which modes exist.

3. Discovery through use — users who don't define modes still get construct activation via name resolution (L2). Operator OS is the power-user layer, not the default layer. The default is: say a construct name, it activates. Modes are for users who want to compose multiple constructs into a named state.

4. Evolution support — the framework should make it easy to add, remove, and modify modes as the user discovers how they work. Not a one-time config — a living document that evolves with the user.

This preserves the RFC's technical proposals (construct index, name resolution, archetype resolver) while removing the prescription of specific modes. The infrastructure is the same. The philosophy is different: build the sandbox, not the castle.

[zkSoju]

Rigorous Feedback: What's Missing, What's Wrong, What Needs Sharpening

Reading this RFC against the full arc — from the construct council through the bazaar audit, the dig research, the hotel paradox, the protocol consistency gap, and the "build the sandbox" reframe — here's what's missing, what needs correction, and what can be enriched.

---

1. L1 (Construct Index) Has a Staleness Problem

The index is generated on session start by sync-packs.sh. But what happens when:

• The user installs a construct mid-session? Index is stale.
• The user deletes a construct? Index shows a ghost.
• A construct's grimoire artifacts are created during the session (first dig creates grimoires/k-hole/research-output/)? The composition paths weren't real at session start but are now.

The index needs to be living, not snapshot. Options:

• Regenerate on any construct install/uninstall (hook on constructs-install.sh)
• Regenerate on mode/construct invocation (lazy refresh)
• Accept staleness with a validity marker (generated_at timestamp, agent checks freshness)

The lazy refresh is most aligned with the hotel paradox — update when relevant, not continuously.

2. L2 (Name Resolution) as CLAUDE.md Instruction Is Fragile

The user's core feedback is: "protocols don't run unless I name them." A CLAUDE.md instruction telling the agent to check the construct index is the same category of invisible protocol. The agent might not read it. The agent might read it and not follow it. The user would be back to "I don't know if it's happening."

The name resolution needs to be structural, not instructional. Options:

• A hook (PreToolUse or UserPromptSubmit) that detects construct names in user input and injects the relevant persona/context
• The construct index itself could be injected into CLAUDE.md as a lightweight section: "You have these constructs installed: [list with quick_start commands]"
• Session start greeting (L5) naturally surfaces construct names, making the agent aware

The hook approach is most reliable but has overhead. The CLAUDE.md injection is simplest — sync-packs.sh already writes to .claude/constructs/CLAUDE.constructs.md. Extending it to include a construct-name-to-activation mapping makes the agent structurally aware, not instructionally aware.

Proposed change to L2: Instead of a standalone CLAUDE.md instruction, extend the existing CLAUDE.constructs.md managed file to include an activation guide:

## Installed Constructs

When the user mentions a construct by name, load its persona and activate its context.

| Name | Persona | Entry Command | Reads From | Writes To |
|------|---------|---------------|------------|-----------|
| k-hole | grimoires/personas/STAMETS.md | /dig | — | grimoires/k-hole/research-output/ |
| observer | grimoires/personas/KEEPER.md | /observe | grimoires/k-hole/research-output/ | grimoires/laboratory/ |
| artisan | grimoires/personas/ALEXANDER.md | /synthesize | grimoires/laboratory/ | grimoires/artisan/ |

This is already in the agent's context window on every session. No new file needed. The activation table makes name resolution structural.

3. L3 (Composition Pipe) Needs the "Both Directions" Case

The pipe is described as unidirectional: K-Hole writes → Observer reads. But real composition is often bidirectional or multi-step:

• /dig → /observe → /feel (three-stage pipe)
• Observer → K-Hole (observer finds a gap, k-hole researches it — reverse flow)
• Artisan + Observer simultaneously (not a pipe, a merge — both examining the same artifact from different lenses)

The RFC describes pipes but not merges or reverse flows. The Unix analogy needs extending:

• Pipe: dig | observe | feel — sequential, artifact flows forward
• Tee: dig | tee observe feel — dig output goes to both observer and artisan simultaneously
• Composition: observe & artisan — both active at once, different lenses on the same work

Proposed enrichment to L3: Define three composition patterns, not just the pipe:

Pattern	Unix Analogy	Example	How It Works
Pipe	a | b	dig findings → observer canvases	Sequential. Output path of A matches input path of B.
Fan-out	a | tee b c	dig findings → observer + artisan simultaneously	Output path of A matches input paths of B and C.
Lens merge	a & b	observer + artisan examining the same component	Both active simultaneously, different read paths, shared context.

The TeamCreate pattern already enables fan-out and lens merge (spawn named agents, they work in parallel). The RFC should acknowledge this as the existing mechanism.

4. "Modes as Pre-Planning Activities" Is a Major Insight Not Captured

The user said: "dig and feel help build context for the plan." This means the golden path has a PREAMBLE that's currently invisible:

Current golden path:     /plan → /build → /review → /ship
Actual user workflow:    [dig] [feel] [systems] → /plan → /build → /review → /ship
                         ^^^^^^^^^^^^^^^^^^^^^^^^
                         pre-planning context building
                         (currently invisible to the golden path)

The golden path should know that pre-planning context exists. When the user invokes /plan, the agent should check: "Are there dig sessions, observer canvases, or taste artifacts in the grimoire from recent work? These might inform the plan."

Proposed enrichment — L6: Context-Aware Golden Path Entry:
When /plan is invoked, the agent checks grimoire directories for recent artifacts:

• grimoires/k-hole/research-output/dig-session-*.md → "Found recent research. Include in planning context?"
• grimoires/laboratory/canvases/ → "Found user feedback canvases. Include?"
• grimoires/artisan/taste.md → "Found taste tokens. Include as design constraints?"

This is the concierge saying "I noticed you did some research earlier — would you like me to bring those notes to the planning session?" Not automatic inclusion. An offer. Agency preserved.

5. Operator OS Self-Composition Is Underspecified

The reframe comment correctly says Operator OS is a methodology, not a feature. But HOW does a user build their personal OS? The RFC proposes a YAML config:

modes:
  dig:
    constructs: [k-hole]
    persona: STAMETS

This assumes the user already knows what modes they want. But the deeper insight is: modes emerge from use, they aren't designed upfront.

The user said: "help other people do deeper work for themselves and better learn how they work."

What's missing: the discovery mechanism. How does the system help users notice their patterns? Ideas:

• Session retrospective: After a long session, surface patterns: "You switched between K-Hole and Artisan 4 times today. You tend to research before designing. Want to name this pattern?"
• Usage heatmap: Over time, show which constructs are used together, how often, in what sequence. Not a dashboard — an ambient signal.
• Mode suggestion: "You've been using observer + artisan together for the last 3 sessions. Want to create a mode called 'FEEL' that activates both?"

This is the RuneScape skill tab at its deepest: it doesn't just show what you've trained. It shows what you've trained TOGETHER. The compositions you keep returning to are your emerging modes.

Proposed enrichment — L7: Mode Discovery Through Use:
Track construct co-activation patterns in persistent memory (grimoires/loa/memory/). After N sessions with a recurring pattern, surface it as a mode suggestion. The user names it or dismisses it. Evolution through observation, not prescription.

6. The "Open Thread Awareness" Needs a Mechanism

The protocol comment proposed: "The agent should maintain awareness of discussed-but-not-completed items." But what tracks them?

Options:

• Beads in lightweight mode: A "threads" bead type that's lighter than sprint tasks. Just a topic + status (open/closed) + last-discussed timestamp.
• Grimoire file: grimoires/loa/THREADS.md — append-only log of open items. Session start reads it, session end updates it.
• Memory system: The persistent memory at grimoires/loa/memory/observations.jsonl already exists. Open threads could be a memory type.

The grimoire file is simplest and most aligned with existing patterns. NOTES.md already exists for observations — add THREADS.md for open items:

## Open Threads

- [ ] Beacon persona rewrite (2026-03-19) — persona says SEO, skills do agent-commerce
- [ ] Command collision: /observe (gecko vs observer) — needs rename decision
- [ ] webgl-particles needs construct.yaml — architecturally invisible

Session start: agent reads THREADS.md, surfaces any items older than N days: "3 open threads from previous sessions. Want to review?"

This is beads-light. It's the concierge's notepad — "you mentioned wanting a wake-up call."

7. The Feedback Routing to Construct Repos Needs Quality Gates

The RFC mentions that gecko should walk stalls and open targeted issues on construct repos. The user explicitly said: "we want to avoid low-quality slop."

What prevents slop:

• Gecko findings must include file:line evidence (already in the diagnose skill methodology)
• Issues must reference the specific construct.yaml field or SKILL.md section with the problem
• Issues should be categorized by the bazaar audit taxonomy: identity-reality drift, schema gap, composition gap, governance gap
• A template for construct issues that structures the finding

Proposed enrichment to L3/feedback routing:
Define a construct issue template:

## [CONSTRUCT_NAME] — [CATEGORY]

**Finding**: [One sentence]
**Evidence**: [file:line reference]
**Impact**: [What breaks or is blocked]
**Suggested fix**: [Specific change]
**Source**: Gecko bazaar audit / user feedback / agent observation

Quality gate: findings without file:line evidence don't get filed. Observations without evidence stay in gecko's notes until grounded.

8. The RFC Assumes Claude Code as the Only Runtime

The proposals reference .run/, CLAUDE.md, sync-packs.sh, and Claude Code hooks. But Loa's own documentation says: "Skills must never assume a specific runtime." The Runtime Contract exists at docs/integration/runtime-contract.md.

If the construct index is a .run/construct-index.yaml file, it's Claude Code specific. If name resolution is a CLAUDE.md instruction, it's Claude Code specific.

For the MVP, this is fine. Claude Code is the primary runtime. But the RFC should acknowledge the runtime boundary and note which proposals are runtime-specific vs. runtime-agnostic:

Proposal	Runtime-Specific?	Notes
L1 (construct index)	Agnostic — YAML file, any runtime can read it	Good
L2 (name resolution)	Specific — CLAUDE.md instruction	Needs runtime abstraction later
L3 (composition pipe)	Agnostic — grimoire filesystem	Good
L4 (personal OS)	Agnostic — YAML config	Good
L5 (ambient evidence)	Specific — session greeting format	Needs runtime abstraction later

This doesn't block shipping. It just acknowledges the debt.

---

9. The Deepest Missing Piece: What Makes This Worth Building

The RFC is technically sound but undersells the vision. The user said something that should be in the opening paragraph:

"These are things that I've actually applied using them... adversarial review from all of them, different perspectives, composing them together, piping through each other."

This already works. The user is already doing it. They're manually orchestrating construct composition — naming agents by construct, piping dig into observe into feel, getting adversarial review from multiple construct perspectives. The RFC isn't proposing something new. It's proposing to make something that's already happening CONSISTENT and SUPPORTED instead of manual and fragile.

That's the strongest argument for the RFC: the usage pattern exists. the infrastructure doesn't.

The user described their experience: "I explicitly invoke it every time. This is friction." The RFC removes that friction. Not by adding automation. By making the pipe a first-class operation.

Proposed addition to the Problem Statement:

Construct composition already happens in practice. Users manually orchestrate multi-construct workflows — naming agents by construct in TeamCreate, piping dig findings into observer canvases, getting adversarial review from construct-specific perspectives. The pattern is proven. The infrastructure to support it consistently is missing. This RFC makes explicit what's already implicit.

---

Summary of Proposed Changes

Addition	Where	Impact
Lazy refresh for construct index	L1 enrichment	Prevents staleness
CLAUDE.constructs.md activation table	L2 redesign	Structural awareness, not instructional
Three composition patterns (pipe, fan-out, lens merge)	L3 enrichment	Covers real usage patterns
L6: Context-aware golden path entry	New proposal	Connects pre-planning to planning
L7: Mode discovery through use	New proposal	Helps users build personal OS
THREADS.md for open items	L5/protocol enrichment	Solves the forgetting pattern
Construct issue template + quality gate	Feedback routing	Prevents slop
Runtime boundary acknowledgment	Cross-cutting	Honest about debt
"Usage exists, infrastructure doesn't" framing	Problem statement	Strongest argument for the RFC