wiki-vault/Sources/Dev/operating-mode.md

created	path	project	tags	type
2026-05-30	Sources/Dev	operating-mode	lovebug operating-mode context-management agent-config mcp skills	project-plan

Operating Mode — Project Plan

Goal

Build a mechanism for invoking named, reusable operating modes for Lovebug — bundles of behavior rules (autonomy level, comms style, verification depth, scope, output format) that can be loaded on demand to configure how Lovebug works for a given session or sub-task.

Today, Travis manually types per-session instructions like "document decisions, stay in these boundaries, don't wait for clarification" when going AFK and wanting autonomous work. This is effectively ad-hoc operating-mode setup. Modes formalize the pattern: name them, store them, reload them deliberately, compose them when needed.

Motivation

Discovered during a meta-conversation on 2026-05-29 (trellis #584) about worker comms, context management, and how priming affects Lovebug's behavior. Two key insights drove this work:

1. Discussing a behavior pattern primes Lovebug for the session, but the priming fades. Durable storage is needed for patterns we want to reuse, not re-type, every time.
2. Memory is the wrong home for modes. Memory auto-loads MEMORY.md at session start and pollutes ambient context with rules that aren't always relevant. Modes are occasional tools you reach for, not always-on facts about the world. They need on-demand load semantics.

Related context: Travis already practices a form of this with explicit AFK instructions. The work here is to formalize, name, and make reusable what he's already doing ad-hoc — and to add modes for other situations beyond AFK autonomy.

Modes Sketched (initial list, not final)

These came out of the conversation as candidate modes. Final set TBD.

• Away / autonomous mode — high autonomy, explicit guardrails, document decisions, no clarification waits. Defining feature: Lovebug makes calls Travis would normally make; cost of being wrong is bounded by stated boundaries.
• Pair mode — opposite end. Travis is watching. Small steps, surface uncertainty, ask before destructive ops, prefer "should I?" over "I did". For high-stakes or unfamiliar domains.
• Exploration mode — open-ended, branchy, low commitment. Survey terrain, find options, no execution. Closer to brainstorming.
• Execution mode — plan exists, just build it. Terse comms, no rehashing, output-focused, only flag deviations. Natural fit for post-plan-interview work.
• Verification / audit mode — paranoid by design. Distrust prior claims, re-check, run tests, read diffs, look for what could go wrong. For pre-merge / pre-deploy.
• Triage mode — queue processing. Inbox, alert backlog, bug list. Fast first pass to classify and batch, second pass to dig in.
• Cleanup mode — small, safe, frequent ops. Tidy repo, prune memory, organize files, fix lints. Speed and frequency over depth; skip work that doesn't fit cleanly.
• Time-boxed mode — constraint, not flavor. "Spend 30 min, then stop and report." For bounded effort when completion is uncertain.

Composition: modes should be stackable. "Away + verification" looks very different from "away + execution." Final design needs to decide how stacking resolves conflicts.

Options Considered

Option A — File in lovebug-instructions repo

Single modes.md or per-mode files in lovebug-instructions/. LOVEBUG.md references the index so Lovebug knows to consult it on mode-switch requests.

Mechanism: Lovebug reads the file when a mode is invoked. The file is the source of truth.

Pros: Cheapest to build. Zero ambient context cost beyond one mention in LOVEBUG.md. Easy to edit (just markdown). No infrastructure. Survives sessions automatically because LOVEBUG.md is the canonical operating contract.

Cons: Reading a single fat modes.md loads its entire content into context — defeats the on-demand promise once it grows. Mitigation: split into per-mode files (modes/away.md, modes/verification.md) with a thin index file that just lists which modes exist. Index gets read first; only the relevant mode file gets loaded. This is the lowest-pollution variant.

Footprint: ~0 ambient (one line in LOVEBUG.md), ~30-50 lines per mode when loaded.

Option B — Skill

A single operating-mode skill (with mode name as argument) or one skill per mode.

Mechanism: Invoked via the Skill tool. Skill description sits in the always-loaded skills list. SKILL.md content loads only when invoked.

Pros: Designed-for-purpose pattern — "specialized capability loaded on demand" is literally what skills are for. Clean separation. Discoverable via the skills list (helps Travis remember they exist). Could optionally include mode-specific sub-instructions, tool gating hints, or agent recipes.

Cons: Each skill costs ~1 line in the ambient skills list. Single-skill-with-arg is the leanest version; per-mode skills give better discovery but more ambient cost.

Footprint: ~1 line ambient per skill, full SKILL.md when invoked.

Option C — Dedicated MCP server

A small MCP server exposing tools like set_mode("execution") that returns the mode definition (and could perform side effects).

Mechanism: Tool call returns the mode rules as a tool result. Could be deferred (loaded only via ToolSearch) for ~zero ambient context cost.

Pros: Most flexible. Could do active things, not just static rule lookup: log mode changes for retro analysis, track time-in-mode, conditionally swap MCPs in and out, gate certain tools per mode, integrate with trellis to checkpoint the active mode at thread level, expose mode-stacking as a first-class operation. Best leverage if modes evolve into a live operational concept.

Cons: Most infrastructure to build/maintain. Another service, another DB row, another container. Probably overkill if modes stay declarative. Travis lean: "MCP everything!" — but should still earn the build cost.

Footprint: ~0 ambient if deferred; small ambient if always listed.

Option D — Trellis thread metadata

Tag a trellis thread with its operating mode. Mode lives in tags or goal text. Resume = mode reload automatically.

Mechanism: The mode is part of thread state. When the thread is resumed, the mode comes with it via the goal/tag fields.

Pros: Already-built infrastructure (trellis). Natural fit for project-scoped work where the mode should outlive a single session. Mode persists across resumes automatically. No new build.

Cons: Thread-scoped only. Doesn't support mid-session mode switches or cross-cutting "switch modes now" use that isn't tied to a specific thread. Cannot be invoked outside of a thread context.

Footprint: ~0 — uses existing thread mechanism.

Decision Factors

When picking between options, consider:

• Frequency of use — daily switches favor B/C; rare/situational favors A.
• Mode interactivity — purely declarative → A/B; modes that should do things (gate tools, log events, mutate env) → C.
• Build budget — small → A; medium → B; large → C.
• Stacking — composing multiple modes implies a registry/composer pattern, easier in B/C than A.
• Cross-context vs in-project — within a project scope, D might be sufficient by itself.
• Discovery cost — B and C make modes self-advertise; A is invisible unless Travis remembers they exist.

Recommended First Cut (non-binding)

Option A with per-mode files + thin index. Lowest cost to validate whether modes are even useful in practice. Travis can iterate on the mode definitions just by editing markdown. If modes prove valuable enough to use regularly, graduate to Option B (skill) for cleaner discovery and on-demand load semantics. Option C is the "if this becomes a real workflow primitive" upgrade — defer until modes have demonstrated value and we want them to actively do things, not just be references.

Option D is complementary, not exclusive. Once modes exist via A/B/C, trellis threads should carry their operating mode as metadata, so resuming a thread restores the mode automatically. This is a small enhancement on top of whichever core option is chosen.

Open Questions

• Should mode invocation be Lovebug-initiated (Lovebug suggests "switching to verification mode for this") or Travis-initiated only?
• How are mode rules versioned over time? Do we want a changelog?
• Do modes have explicit "exit" semantics, or do they last until another mode is invoked or the session ends?
• Should there be a "default" mode that applies when none is declared, or is the absence-of-mode itself the default?
• How does mode stacking compose — explicit order ("away + verification"), or layered priority where one mode's rules can override another's?
• For Option C: if MCP modes can gate tools, what's the failure mode when a worker spawned in a restrictive mode needs a tool that's been gated off?

Out of Scope (for now)

• Auto-detecting which mode Travis wants based on conversational signals.
• Per-mode MCP / tool gating (Option C only).
• Mode telemetry / time-in-mode logging.
• Mode-specific subagent recipes or agent definitions.
• Mode-aware memory loading (mode determines which memory files are read at session start).

Provenance

Origin conversation: trellis #584 (herbys-dev environment buildout, 2026-05-29), meta-discussion segment about worker comms and context management. Plan drafted while ideas were fresh per Travis's request.