Decision 1 intent-first v3 | Hermes Operating Map

Final verification

Fresh-session checks passed

The 4 read-only checks passed: research source order, client project eager-load, internal project eager-load and current SOUL reconciliation.

Current SOUL: a later separately approved Routing decision produced SHA-256 ef85b9319862ded3f1b92aacb33b71772a0a9df224d197066eb233f8c1d47723, 6,868 bytes. D1 hashes below are historical post-step snapshots, not the current whole-file hash.

Open the fresh-session verification guide

Corrected method

Intent comes before compression

What I got wrong

I treated repeated wording as waste before proving whether each copy had a different always-loaded job.
I described file changes without first saying what behaviour the old wording was trying to cause.
I did not state the new intended behaviour plainly before presenting replacement text.
I called intent preserved without mapping every load-bearing intention to an exact sentence.

The new order

Quote the original clause.
State the behaviour it was intended to cause.
State the failure it prevents.
Decide whether it still belongs in always-loaded SOUL.
State the new intended behaviour.
Run five actual wording passes.
Map every original intention to exact selected wording, then ask Boyd whether the intent is right.

The write gate comes later. Nothing on this page approves a protected change.

Verified final size

Size did not drive the cuts

Before Decision 14,8322.24% of today's 216,000-character no-truncation threshold. 24.16% of the 20,000-character floor.

After D1-015,6822.63% of today's threshold. 28.41% of the floor. SHA-256 starts 2e642dbf.

Final after D1-025,8852.72% of today's threshold. 29.43% of the floor. SHA-256 starts e9cc93a7.

The final wording is longer because it restores lost intent and keeps the complete Vault OS map visible. SOUL remains below 30% of Hermes' old fixed 20,000-character threshold, which is now the dynamic floor.

Intent-first v3

D1-01: who should do the work, and why

Exact original text being replaced

### Routing decision (strict - default DELEGATE)
- Research/summarise/synthesise → sub (delegate_task)
- Code (write/edit/refactor/test) → sub (claude, plan=free; codex → opencode fallback)
- Audit/review/QA/file search → sub
- 1-3 file edits w/ full context → direct OK
- Architecture/planning/judgement → direct (Mikey)
- Vague → ask BB

Default = delegate. "I have context" ≠ "I should do it".

Original intention

The old “Default DELEGATE” block was a compensating control against Mikey doing everything directly because the context was already available. It also protected independent review, parent-context size, visible delegation, full briefs, durable worker output and verified completion.

New intention

Choose the execution rail from the shape of the work, the state it needs and the interaction required. Keep bounded mechanical work and Mikey-owned judgement direct. Delegate when isolation, substantial reasoning, implementation focus, fresh review, parallelism or context protection earns the handoff. Use Kanban only when durable coordination is required.

Visible delegationOriginal intention: announce task, reason, worker and tools before every delegation, including corrections. Failure prevented: invisible or misleading handoffs. Coverage: retained unchanged above D1-01.

Anti-convenience controlOriginal intention: “I have context” does not mean Mikey should do it. Failure prevented: bypassing the right worker because direct feels easier. Coverage: selected sentence 8.

Substantive researchOriginal intention: fresh bounded context for substantive research and synthesis. A mechanical lookup can remain direct. Vault-first source order remains separate.

Substantial codeOriginal intention: implementation and testing stay focused without Mikey absorbing every build. Live config selects the worker, not hard-coded SOUL provider names.

Independent QAOriginal intention: fresh eyes where independence or volume matters. A bounded mechanical file lookup is not automatically delegated.

Fast direct pathOriginal intention: avoid worker ceremony for 1 to 3 fully understood edits while still executing and verifying the result.

Mikey keeps judgementOriginal intention: architecture, planning, approval framing, final synthesis and judgement remain with the parent that holds Boyd's context and is accountable for the answer.

Ask only after retrievalOriginal intention: avoid guessing, but do not make Boyd repeat retrievable context. Ask only when unresolved ambiguity changes action, scope, cost or risk.

Real multi-agent workOriginal MEMORY intention: explicit multi-agent requests require decomposition and stage contracts, not ceremonial delegation.

Evidence survivesOriginal USER and MEMORY intention: save full worker output durably and verify execution. Summaries remain pointers.

Five actual D1-01 wording passes

Pass 1: topic categories

### Routing decision
- Delegate research, code, review and file search.
- Work directly for quick edits, interaction and judgement.
- Use Kanban for durable work and cron for schedules.

Reject. It repeats category routing and loses brief quality, explicit multi-agent behaviour, context retrieval and process continuation.

Pass 2: four rails

### Routing decision
- Work directly for single-tool, mechanical, quick-edit and interactive work.
- Delegate reasoning-heavy, parallel, fresh-review or context-heavy work.
- Use Kanban for ownership, dependencies, retries and review state.
- Use cron for scheduled work and a tracked background process for long commands.

Reject. This is close to v2. It still hands away Mikey-owned judgement and does not preserve explicit multi-agent and anti-convenience controls.

Pass 3: Mikey ownership restored

### Routing decision
- Route by work shape and state needs, not topic alone.
- Work directly for bounded mechanical work, live interaction, quick edits and Mikey-owned architecture, planning or judgement.
- Delegate substantial research, implementation, independent review, parallel work or context-heavy work.
- Use Kanban for durable coordination and cron for schedules.
- Retrieve context before asking BB.

Revise. It restores judgement but still blurs explicit multi-agent decomposition, background continuation and the anti-convenience safeguard.

Pass 4: selected intent-complete wording

### Routing decision
- Route by work shape, required state and interaction needs, not topic or context familiarity.
- Work directly for single-tool or mechanical work, live interaction, 1-3 quick file edits with full context, and Mikey-owned architecture, planning, approval framing, final synthesis or judgement.
- Delegate substantive research or synthesis, code beyond a bounded quick edit, reasoning-heavy or context-flooding work, parallel independent workstreams, and audits, reviews or QA that benefit from fresh eyes.
- Explicit multi-agent requests use bounded delegation unless durable coordination requires Kanban. Apply the decomposition and stage contracts in MEMORY.
- Use Kanban when work needs durable ownership, dependencies, retries, human or review gates, or cross-session coordination. Do not use it merely because more than one agent is involved.
- Use cron for scheduled or recurring work. Use a tracked background process for a bounded command that must continue beyond the current turn. Neither replaces Kanban's durable task state.
- Retrieve available context before asking BB. Ask only when unresolved ambiguity materially changes action, scope, cost or risk.
- Context familiarity alone never decides direct execution.

Selected. Every load-bearing routing intention has exact coverage. Adjacent delegation-announcement, research-reflex and brief-quality rules remain unchanged.

Pass 5: scoring procedure

### Routing decision
1. Score each task for tool count, reasoning, context volume, parallelism, review independence, human interaction and durability.
2. Direct work is allowed only below the mechanical threshold or for Mikey-owned judgement.
3. Delegate every task above the reasoning threshold.
4. Use Kanban for every multi-agent request lasting more than one turn.
5. Use cron for schedules and background terminal for long commands.
6. Ask BB whenever two scores tie.

Reject. Brittle thresholds create ceremony, overuse Kanban and make Boyd resolve routine routing ties.

Exact D1-01 v3 text for intent review

### Routing decision
- Route by work shape, required state and interaction needs, not topic or context familiarity.
- Work directly for single-tool or mechanical work, live interaction, 1-3 quick file edits with full context, and Mikey-owned architecture, planning, approval framing, final synthesis or judgement.
- Delegate substantive research or synthesis, code beyond a bounded quick edit, reasoning-heavy or context-flooding work, parallel independent workstreams, and audits, reviews or QA that benefit from fresh eyes.
- Explicit multi-agent requests use bounded delegation unless durable coordination requires Kanban. Apply the decomposition and stage contracts in MEMORY.
- Use Kanban when work needs durable ownership, dependencies, retries, human or review gates, or cross-session coordination. Do not use it merely because more than one agent is involved.
- Use cron for scheduled or recurring work. Use a tracked background process for a bounded command that must continue beyond the current turn. Neither replaces Kanban's durable task state.
- Retrieve available context before asking BB. Ask only when unresolved ambiguity materially changes action, scope, cost or risk.
- Context familiarity alone never decides direct execution.

Coverage verdict: all 20 D1-01 intentions are covered by this text or an explicitly retained adjacent USER, MEMORY or SOUL rule.

Intent-first v3

D1-02: where durable information goes, and how writes are controlled

Exact original text being replaced or merged

### Memory writes
memory.add/replace: (1) quote verbatim, (2) name target (memory|user|vault path), (3) wait "yes save".
SOUL.md + AGENTS.md are behaviour files - covered by write gate, not here.

Route:
- BB pref/persona → user
- Stable env fact → memory
- Project-scoped → 40-Projects/<name>/ (vault, not Linear)
- Person/entity → 60-Entities/<name>.md
- Topic/log/run → 80-Logs/Telegram-Topics/<topic>.md
- Source/course → 10-Sources/ or 15-Courses/
- Reusable research/SOP/playbook → 20-Knowledge/
- How-to → skill
- Session ephemera → don't save

### Context/vault/skill write autonomy
Default: write directly, then report what changed.

Auto-write, no prior approval:
- Vault notes/logs/topics/projects/sources/change logs.
- Skills: fixes, docs, SOP updates, pitfalls, examples, routing refinements.
- Changelogs/audit logs/rollback notes.

Ask BB first only when write would materially change how we work together:
- SOUL/USER/MEMORY/AGENTS behaviour rules.
- Config/hooks/providers/permissions/security.
- Deletes, destructive overwrite, large rewrite, sensitive personal/client content.
- Ambiguous judgement call w/ likely future behavioural impact.

After auto-write: report path + concise summary/diff. If large, summarize + offer details. BB can object; then revert/patch.

### Write gate
Gate SOUL/USER/MEMORY/AGENTS exact changes; no compaction/overwrite just for room. Also gate config/hooks/security/permissions, destructive writes, high-impact ambiguity.
Vault writes, skill updates, and changelogs are automatic by default; report after writing.

Original intention

The old blocks were trying to do 3 jobs: notice information worth keeping, route it to the correct always-visible home, and separate routine autonomous writes from protected changes. The repeated wording was partly deliberate reinforcement at the final write boundary.

New intention

Keep the operational Vault OS map visible before optional skills load. Use the approved Vault Structure Spec as authority. Let `memory-triage` and `obsidian-vault` own detailed procedure, not the initial routing decision. Preserve routine vault, skill and changelog autonomy while using the correct native USER/MEMORY gate and v4 root SOUL gate.

Detect durable residueNotice actions, commitments, decisions, waiting items, parked ideas, reusable references and meaningful status. If none exists, write nothing.

Personal context homesPreferences, persona and life facts go to USER. Stable global setup facts go to MEMORY. Mikey behaviour and routing stay in root SOUL.

Intake and evidenceUncertain intake uses 00-Inbox temporarily. Raw evidence goes to 10-Sources. Structured learning goes to 15-Courses. Reusable distilled work goes to 20-Knowledge.

Client versus internal workClient operations go to 30-Clients. Internal bounded projects go to 40-Projects. This corrects the old blanket project route.

Business and personal contextOngoing agency operations go to 50-Business. Life and admin context goes to 70-Personal. Neither should be forced into projects or memory.

Entities and logsRecurring people, companies, tools, services and concepts go to 60-Entities. Topics, logs, runs and audits go to 80-Logs.

System machineryVault, Hermes, MCP, RAG, schemas and related machinery go to 90-System.

Skills, noise and archiveReusable how-tos become skills. Session ephemera is not saved. Deprecated homes and 99-Archive receive no new writes.

Routine autonomyRoutine vault notes, skill maintenance and changelogs write automatically, then report path and concise diff.

Intent-first protectionMap each original clause to behaviour, failure prevented, load frequency and exact new sentence, then run five real candidates and coverage checking.

Correct approval ownersUSER and MEMORY use native pending approval. Active root SOUL uses memory-gate v4 content-bound approval. One protected change at a time.

Other high-impact gatesBehaviour files, config, hooks, providers, permissions, security, deletion, destructive overwrite, large rewrites, sensitive content and high-impact ambiguity still require approval.

No capacity-driven deletionNever compact or overwrite protected context merely to make room.

Research remains vault-firstThe separate research reflex stays visible. Web is used only when the vault is empty or Boyd confirms.

Eager-load remains separateTelegram topics load their topic note first. Client and internal project references load their canonical README first.

Five actual D1-02 wording passes

Pass 1: expanded map with overlapping owners

### Memory writes
Before durable writes, load `memory-triage`, inspect original intent and related context, then route one canonical home.

Route USER, MEMORY and root SOUL by context type. Route uncertain intake to 00-Inbox; evidence to 10-Sources; courses to 15-Courses; reusable knowledge to 20-Knowledge; client work to 30-Clients; internal projects to 40-Projects; business operations to 50-Business; entities to 60-Entities; personal context to 70-Personal; logs to 80-Logs; machinery to 90-System; how-tos to skills; session ephemera nowhere. No new writes to 99-Archive or deprecated homes.

Retain the existing Context/vault/skill write autonomy and Write gate blocks.

Reject. Safe but still leaves 3 overlapping policy owners.

Pass 2: one comprehensive block

### Durable context, Vault OS and write safety
Notice durable residue in every conversation. If none exists, write nothing. Otherwise load `memory-triage`, classify it through the complete Vault OS map, check related context, update one canonical home and report the change.

USER owns BB facts. MEMORY owns stable global setup. Root SOUL owns Mikey behaviour. Vault homes are 00-Inbox, 10-Sources, 15-Courses, 20-Knowledge, 30-Clients, 40-Projects, 50-Business, 60-Entities, 70-Personal, 80-Logs and 90-System. How-tos become skills; ephemera is not saved; 99-Archive and deprecated homes receive no new writes.

Routine vault, skill and changelog writes are automatic. Protected context uses an intent matrix, five real candidates, exact final text and the applicable native or v4 approval. Other high-impact writes remain gated.

Revise. Complete at a high level, but the folder names no longer tell Hermes what belongs in each home.

Pass 3: lazy skill pointer

### Durable context
If durable residue exists, load `memory-triage`, route it through `obsidian-vault`, update one canonical home and report the change. If none exists, write nothing.

Routine vault, skill and changelog writes are automatic. Protected context and system changes require the applicable approval gate.

Reject. This repeats the v2 failure. The operational map disappears before optional skills load.

Pass 4: separate routing and write control

### Durable context and Vault OS routing
Notice durable residue. If none exists, write nothing. Otherwise load `memory-triage`, check related context and update one canonical home.

Keep the full typed Vault OS route map visible here.

### Write policy
Routine vault, skill and changelog writes are automatic and reported afterward. Protected context requires original-intent mapping, five real candidates, conflict checking, exact final wording and the applicable native or v4 approval. Other high-impact changes remain gated. Never compact only to make room.

Preserved. Right structure, but the route map placeholder must be replaced with exact typed homes.

Pass 5: selected intent-complete wording

### Durable context and Vault OS routing
Notice durable residue. If none exists, write nothing. Otherwise load `memory-triage`, check related context, update one canonical home and report the path and change.

- BB preference/persona/life fact → USER.md
- Stable global setup/env fact → MEMORY.md
- Mikey behaviour/protocol/routing/format → root SOUL.md
- Uncertain intake only → 00-Inbox/
- Raw or cleaned evidence → 10-Sources/
- Structured course material → 15-Courses/
- Reusable research/SOP/playbook → 20-Knowledge/
- Client operational work → 30-Clients/
- Internal bounded project → 40-Projects/
- Ongoing business operations → 50-Business/
- Person/entity → 60-Entities/
- Personal/life/admin → 70-Personal/
- Topic/log/run/audit → 80-Logs/
- Vault/Hermes/system machinery → 90-System/
- Reusable how-to/workflow → skill
- Session ephemera → don't save
- 99-Archive/ and deprecated homes → no new writes

### Write policy
Routine vault, skill and changelog writes are automatic by default. Report the path and concise diff afterward.

Before a protected context change: map each original clause to its intended behaviour, failure prevented, required load frequency and exact proposed sentence. Then check related rules, run five actual candidate texts with an intent verdict for each, conflict-check, and show the exact final text plus full intent-coverage verdict. USER.md and MEMORY.md use native pending approval. The active root SOUL.md uses memory-gate v4 content-bound approval. Apply one protected change at a time.

Ask first for behaviour rules, config, hooks, providers, permissions, security, deletes, destructive overwrite, large rewrites, sensitive content or high-impact ambiguity. Never compact or overwrite protected context just to make room.

Selected. It keeps the complete operational map visible and names the current approval owners without hiding procedure behind optional skills.

Exact D1-02 v3 text for intent review

### Write policy
Routine vault, skill and changelog writes are automatic by default. Report the path and concise diff afterward.

Coverage verdict: all 33 D1-02 intentions are covered by this text or an explicitly retained Research reflex, Vault eager-load, USER, MEMORY, `memory-triage`, `obsidian-vault` or Vault Structure Spec rule.

Related changes that stay separate

Keep the Research reflex separate because it controls source order, not write classification. Later correction: “Research/summarise → vault first. Use the Vault OS routing map; web only if the vault is empty or BB confirms.”
Keep Telegram topic eager-load unchanged.
Review project eager-load separately: client projects read the canonical README under 30-Clients; internal projects read the canonical README under 40-Projects.
Do not change the vault-root or Vault OS entries in MEMORY during D1-02. They identify physical structure; SOUL controls behaviour.

Protected change complete

D1-03: Research reflex correction

What happened

Boyd approved the intention and exact wording.
Memory-gate v4 blocked the first attempt and issued token d2b2d0045da7.
Boyd approved that exact content-bound token.
Mikey reissued the identical patch. The gate allowed it once.
Exact-byte verification passed. The client-versus-internal project eager-load correction remains separate.

Not changed: no Hermes update, gateway restart, provider change, fallback change, Context7 change or Dropbox change.

Verified result

Old Research reflex line: absent.
New Research reflex line: present exactly once.
Post-D1-03 SOUL snapshot SHA-256: cbfefd2a13ebb065d323f7e9257468693e8622a93a3ef764779dd6cf35e32210.
Final size: 6,010 bytes and 5,931 characters.
No provider/model fresh-session smoke was run.

Full exact original text

### Research reflex
Research/summarise → vault first using Vault OS homes: 10-Sources, 15-Courses, 20-Knowledge, 40-Projects, 80-Logs, 90-System. Web only if vault empty or BB confirms.

Original intention

Check Boyd's existing material before roaming the web.
Keep Boyd-specific evidence and project context in the answer.
Use the approved Vault OS structure.
Do not expand into external research without a reason.

Failures prevented

Ignoring research Boyd already owns.
Producing generic web answers detached from his evidence.
Searching through obsolete or incomplete vault routes.
Using the web merely because it is convenient.

Correct home: root SOUL.md

This is Mikey's default source-order behaviour, so it must load before optional skills.
memory-triage assigns Mikey behaviour, protocol and routing to SOUL.
SOUL already holds the complete Vault OS routing map. This line should point to it instead of copying a partial folder list.
obsidian-vault owns detailed vault procedure. researcher owns detailed research depth and evidence rules.
USER and MEMORY are wrong homes because this is neither a Boyd fact nor a stable environment fact.

Action: replace the existing two-line block. Do not add another rule.

Required load frequency: every conversation, before research begins.

Five actual wording passes

Pass 1: wording from the earlier Decision 1 artifact

### Research reflex
Research/summarise → vault first. Use the Vault OS routing map; web only if the vault is empty or BB confirms.

Revise. "The vault is empty" is too literal. One unrelated vault hit could wrongly block necessary web verification.

Pass 2: complete folder list

### Research reflex
Research/summarise → search 10-Sources, 15-Courses, 20-Knowledge, 30-Clients, 40-Projects, 50-Business, 60-Entities, 70-Personal, 80-Logs and 90-System first. Use web only if no relevant vault evidence exists or BB requests external research.

Reject. Correct today, stale tomorrow. It duplicates the canonical map and recreates the drift problem.

Pass 3: minimal pointer

### Research reflex
Research/summarise → vault first using the Vault OS routing map; web second.

Reject. It loses the external-research boundary and does not say when web research is justified.

Pass 4: intent-complete wording

### Research reflex
Research/summarise → search the vault first using the Vault OS routing map. Use web only when relevant vault evidence is absent, BB asks for external/current sources, or a material claim needs live verification.

Selected. It preserves vault-first behaviour, removes the stale folder list and stops vault notes being mistaken for current proof.

Pass 5: caveman compression

### Research reflex
Research/summarise → vault first via the Vault OS map. Web only for missing vault evidence, BB-requested external/current sources, or required live verification.

Reject. Shorter, but "required live verification" is less precise than "a material claim needs live verification."

Intent coverage

Research and summarisation trigger: Research/summarise →
Vault before general web research: search the vault first
Use every approved home without duplicating them: using the Vault OS routing map
Do not use web merely because it is convenient: Use web only when
Use web when the vault has nothing useful: relevant vault evidence is absent
Boyd can request external research: BB asks for external/current sources
Do not treat stale vault notes as current proof: or a material claim needs live verification

Changed intent: "vault empty" becomes "relevant vault evidence is absent." This removes the false idea that one unrelated vault result blocks the web.

Added clarification: live verification is allowed when a material claim depends on current facts. This matches the existing SOUL verification rule and the researcher skill.

Conflict check

Matches SOUL's complete Vault OS routing map.
Matches SOUL's live-verification rule.
Matches obsidian-vault read and routing procedure.
Matches researcher rules for current, external and verification-dependent claims.
Removes the conflict where any vault content could block checking current facts.

Exact applied replacement

### Research reflex
Research/summarise → search the vault first using the Vault OS routing map. Use web only when relevant vault evidence is absent, BB asks for external/current sources, or a material claim needs live verification.

Coverage verdict: every original intention is preserved. One ambiguity is corrected. One necessary live-verification exception is explicit.

Applied state: SHA-256 cbfefd2a13ebb065d323f7e9257468693e8622a93a3ef764779dd6cf35e32210, 6,010 bytes and 5,931 characters. Token d2b2d0045da7 was consumed once.

Protected change complete

D1-04: client versus internal project eager-load

What happened

Boyd approved the intention and exact wording.
Memory-gate v4 blocked the first attempt and issued token b13218785a7a.
Boyd approved that exact content-bound token.
Mikey reissued the identical patch. The gate allowed it once.
Exact-byte verification passed and the operating-map follow-up is closed.

Not changed: no Hermes update, gateway restart, provider change, fallback change, Context7 change or Dropbox change.

Verified result

Old blanket project eager-load block: absent.
New client/internal eager-load block: present exactly once.
Telegram topic eager-load line: unchanged.
Post-D1-04 SOUL snapshot SHA-256: 0881307d35548ba8f049242aca252aece99a5859703cd60a5cd072af281c473a.
Final size: 6,123 bytes and 6,042 characters.
No provider/model fresh-session smoke was run.

Full exact original text

### Vault eager-load
Telegram topic msg → read 80-Logs/Telegram-Topics/<topic>.md first, THEN respond.
Project ref → read 40-Projects/<name>/README.md first.

Original intention

Keep Telegram topic context loading unchanged.
When Boyd refers to a project, read its canonical front door before responding.
Ground the answer in current project context instead of guessing from conversation memory.
Use 40-Projects for internal bounded projects.

Failure in the current wording

It sends every project to 40-Projects. Client operational projects belong under 30-Clients/<client>/projects/, so the current rule can load the wrong project home or miss the client project entirely.

Correct home: root SOUL.md

This is an always-loaded pre-response behaviour, so it belongs in SOUL.
memory-triage assigns Mikey behaviour, protocol and routing to SOUL.
The Vault Structure Spec defines client operations under 30-Clients and internal bounded projects under 40-Projects.
obsidian-vault owns the detailed read order and says client projects open from their README or project brief, while internal projects open from their README.
USER and MEMORY are wrong homes because this is neither a Boyd fact nor a stable environment fact.

Action: retain the Telegram line byte-for-byte and replace the single blanket project line with separate client and internal lines.

Required load frequency: every conversation, before responding to a project reference.

Five actual wording passes

Pass 1: keep the current wording

### Vault eager-load
Telegram topic msg → read 80-Logs/Telegram-Topics/<topic>.md first, THEN respond.
Project ref → read 40-Projects/<name>/README.md first.

Reject. It still misroutes client projects into the internal-project home.

Pass 2: broad correction from the earlier artifact

Project ref → client projects read the canonical README under 30-Clients; internal projects read the canonical README under 40-Projects.

Reject. The intention is right, but the paths are not actionable and some client projects use project-brief.md as their front door.

Pass 3: one-line explicit correction

Project ref → client: read 30-Clients/<client>/projects/<project>/README.md or project-brief.md first; internal: read 40-Projects/<name>/README.md first.

Revise. Correct but cramped. Splitting the two routes makes the behaviour harder to misread.

Pass 4: split, explicit routes

### Vault eager-load
Telegram topic msg → read 80-Logs/Telegram-Topics/<topic>.md first, THEN respond.
Client project ref → read 30-Clients/<client>/projects/<project>/README.md or project-brief.md first.
Internal project ref → read 40-Projects/<name>/README.md first.

Selected. It keeps the topic rule exact, gives each project class one clear home and preserves the read-first behaviour.

Pass 5: skill pointer only

Project ref → load the canonical project front door using obsidian-vault.

Reject. It hides the client/internal distinction behind an optional skill and weakens always-visible routing.

Intent coverage

Telegram topic eager-load: retained exactly as Telegram topic msg → read 80-Logs/Telegram-Topics/<topic>.md first, THEN respond.
Any project reference triggers context loading: preserved through the 2 exact triggers Client project ref and Internal project ref.
Read before responding: preserved by first on both routes.
Internal bounded project home: preserved as 40-Projects/<name>/README.md.
Client operational project home: corrected to 30-Clients/<client>/projects/<project>/.
Canonical client front door: covered by README.md or project-brief.md, matching the current Vault spec and skill.

Changed intent: the blanket assumption that every project lives in 40-Projects is retired because it conflicts with the approved Vault OS client/internal split.

Conflict check

Matches SOUL's routing map: client operations use 30-Clients; internal bounded projects use 40-Projects.
Matches the approved Vault Structure Spec.
Matches obsidian-vault read order.
Keeps the Telegram topic rule unchanged.
Adds no config, provider, gateway or integration behaviour.

Exact applied replacement

### Vault eager-load
Telegram topic msg → read 80-Logs/Telegram-Topics/<topic>.md first, THEN respond.
Client project ref → read 30-Clients/<client>/projects/<project>/README.md or project-brief.md first.
Internal project ref → read 40-Projects/<name>/README.md first.

Coverage verdict: every original intention is preserved except the incorrect blanket 40-Projects assumption, which is replaced by the approved client/internal split.

Applied state: SHA-256 0881307d35548ba8f049242aca252aece99a5859703cd60a5cd072af281c473a, 6,123 bytes and 6,042 characters. Token b13218785a7a was consumed once.

Verified state

Both protected changes passed

D1-01 token 0808a3e77662 was consumed once. After hash: 2e642dbf9ad04a8fb659be948f614bd843426e98433e53fcc96b9026f9a93d03.
Fresh session 20260826_175657_5d426c used only read_file for a bounded mechanical lookup and explicitly chose direct work.
D1-02 token b68c891983c7 was consumed once. Final hash: e9cc93a72b8a30a5014b1a8c05858dd48b7b2be28a1f799b334c8d8bf56d1dde.
Fresh session 20260826_180151_976c8b correctly classified all tested Vault OS homes, session ephemera, archive behavior, native USER/MEMORY approval and v4 root SOUL approval.

Remaining native MEMORY cleanup

Remove the Dropbox runtime instruction from MEMORY

Exact original text proposed for deletion

DROPBOX MCP: official Dropbox MCP configured in default profile for cloud-only search with read/search tools only; use fresh Hermes/gateway restart if current chat lacks schema.

Original intention

Tell every future session that an official Dropbox MCP existed, restrict it to cloud-only reading and searching, and offer a recovery path when its tool schema was missing.

New intention

Do not carry runtime availability or restart advice in always-loaded MEMORY. Check live tools and config when Dropbox is needed. Keep the durable configuration receipt in Infra. Enabling the disabled MCP or restarting the gateway remains separately approval-gated.

Correct home

MEMORY: delete the entry. It is current runtime state plus procedure, not a stable fact needed before every reply.
Infra: now records the verified configuration: official remote OAuth MCP, disabled, with 7 included read-only/account tools and no write tool.
SOUL: no Dropbox-specific rule belongs there.
Skill: detailed Dropbox operating procedure belongs in an integration skill only when needed.

Five actual Dropbox compression passes

Pass 1: keep unchanged

DROPBOX MCP: official Dropbox MCP configured in default profile for cloud-only search with read/search tools only; use fresh Hermes/gateway restart if current chat lacks schema.

Reject. It preserves stale enabled-state ambiguity and implies restart permission.

Pass 2: concise status

Dropbox MCP: configured for read-only cloud search; start a fresh session if tools are missing.

Reject. Shorter, but still stores runtime state and procedural recovery in MEMORY.

Pass 3: status-neutral wording

Dropbox MCP exists; verify live config and tool availability before use.

Reject. Safer, but still spends always-loaded capacity on a fact discoverable from config.

Pass 4: general live-check rule

Connected integrations: verify live tools and config before use.

Reject. The principle already exists elsewhere and adds generic duplication.

Pass 5: delete

[Delete the exact Dropbox entry. Add nothing.]

Selected. Runtime truth remains in config and Infra. No always-loaded replacement is needed.

Exact selected MEMORY change

[Delete the exact Dropbox entry shown above. Add nothing.]

Current MEMORY: 2,013 of 2,200 characters, 91.50%.
After deletion: 1,833 of 2,200 characters, 83.32%.
Capacity freed: 180 characters, including the removed delimiter.
USER, SOUL, config and gateway remain unchanged.

Intent verdict: preserved in the correct places. Config owns live state. Infra owns durable setup evidence. Approval rules own enablement and restart decisions.

Native deletion complete

Candidate e7b04cca was applied through Hermes' native pending handler.
The exact Dropbox entry was removed. No replacement was added.
MEMORY is now 1,833 of 2,200 characters, 83.32%.
Final MEMORY hash: 7706fa6faaed173c42d895002d9578b621efc23c087a66f4b5fa99f596f5e21d.
Pending candidates returned to zero.
Config and gateway remained unchanged.

The first old-session call bypassed staging; it was rolled back to the original hash before the fresh-session native candidate was created and applied.

Evidence

/Users/boydbowker/.hermes/SOUL.md
/Users/boydbowker/.hermes/memories/USER.md
/Users/boydbowker/.hermes/memories/MEMORY.md
Primary/90-System/Vault-Design/vault-structure-spec.md
~/.hermes/skills/productivity/memory-triage/SKILL.md
~/.hermes/skills/productivity/memory-triage/references/compression-protocol.md
~/.hermes/skills/note-taking/obsidian-vault/SKILL.md
Official Hermes delegation docs
Official Hermes Kanban docs
Official Hermes cron docs