> Public study copy. Original Xavier note path: `30-39 Projects/33 Xavier/33.12 Xavier Decision Register.md`. Secrets/credential-like values, if any, are redacted.

# 33.12 Xavier Decision Register

> Project-specific decision register for Xavier/Hermes operating architecture, memory governance, machine topology, and durable Paulo/Xavier workflow choices.
> Created: 2026-06-15

## Purpose

This register captures actual decisions for the `33 Xavier` project area. It is not a chat summary or task log. Use it to preserve closed options, rationale, implications, and current status so future Xavier sessions do not re-derive the same operating decisions.

## Decisions

### 2026-08-04 — Use a lightweight routing matrix for Paulo/Xavier intake

- Decision: Adopt a lightweight conversation routing matrix in [[33.01 Xavier Operating Model]] so Xavier classifies Paulo's inputs into predictable routes: direct answer, Master Kanban task, decision register, skill/runbook, Vault Log, project owner note, source/source box, parked idea, compact runtime memory, or numbered-options clarification.
- Rationale: The value is not another tool for Paulo, but less repeated friction about where things go, fewer lost decisions, less Obsidian clutter, and better escalation from one-off fixes into skills/runbooks/watchdogs when a pattern recurs.
- Implication: Paulo can keep speaking normally. Xavier should route low-risk items and inform Paulo, but must ask before structural, sensitive, ambiguous, destructive, or high-impact changes. Runtime memory remains compact; decisions go to decision registers; procedures go to skills/runbooks; tasks go to the Master Kanban or owner project notes.
- Status: active
- Source: Telegram/Hermes session, 2026-08-04
- Related: [[33.01 Xavier Operating Model]], [[11.06 Master Kanban Board]], [[00.03 Vault Log]], [[33.05 Hermes Memory Mirror Policy]]

### 2026-08-02 — Use one Master Kanban Board with five domain filters

- Decision: Use [[11.06 Master Kanban Board]] as the single official human-visible task board, with five domain filters: `#area/phd`, `#area/academia`, `#area/personal`, `#area/xavier`, and `#area/voice-lab`. Keep earlier domain-specific boards as fallback / historical / test scaffolds, not default entry points.
- Rationale: One board gives Paulo a single view of live work while filters preserve domain clarity. This avoids multiplying boards and keeps the system visually manageable.
- Implication: Future low-risk tasks can be added by Xavier to the Master Board or relevant project note using one `#area/...` tag and one active `#status/...` tag. `#status/parked` is available for deliberately deferred items. Xavier informs Paulo after low-risk additions and asks before structural, sensitive, ambiguous, or high-impact changes.
- Status: active
- Source: Telegram/Hermes session, 2026-08-02
- Related: [[11.05 Kanban Operating Model]], [[11.06 Master Kanban Board]], [[37.13 PhD Kanban Board]], [[38.02 Academia Kanban Board]], [[39.02 Personal Kanban Board]]

### 2026-06-15 — Maintain a compact layered Xavier memory system

- Decision: Keep runtime memory compact and behavior-relevant; use Obsidian for long-form project state, decisions, dashboards, maps, and historical context; use skills for reusable procedures; use session history for recall on demand.
- Rationale: Runtime memory is injected into sessions and can become stale or bloated. Obsidian is better for readable auditability, while skills are better for repeatable workflows.
- Implication: When memory grows, Xavier should compact or remove runtime entries, mirror deliberate runtime changes back into Obsidian, and record durable architecture choices here instead of turning runtime memory into a project log.
- Status: active
- Source: Telegram/Hermes session, 2026-06-15
- Related: [[33.05 Hermes Memory Mirror Policy]], [[33.06 Xavier Memory Dashboard]], [[33.03 Paulo User Profile]], [[33.04 Xavier Runtime Memory]]

### 2026-06-15 — Use `33.12` for Xavier project decisions because `33.10` and `33.11` are already used

- Decision: Create the Xavier project decision register as `33.12 Xavier Decision Register` instead of `33.10`, because `33.10` is already the Xavier Machines Relationship Map and `33.11` is its companion context note.
- Rationale: The vault should keep strict Johnny.Decimal IDs and avoid duplicate-looking IDs or renaming active visual-map notes unnecessarily.
- Implication: Future Xavier operating decisions should be appended here. The dashboard should link to `33.12` as the project-specific decision register.
- Status: active
- Source: Telegram/Hermes session, 2026-06-15
- Related: [[33.10 Xavier Machines Relationship Map.excalidraw]], [[33.11 Xavier Machines Map Context]], [[33.06 Xavier Memory Dashboard]]

### 2026-06-15 — Treat Guilherme as the current human-facing M2 name; keep Baltasar only as historical wording

- Decision: Use Guilherme/Guilherme-M2/GUI as the current human-facing and scoped name for the MacMini M2 Xavier workstation extension. Treat Baltasar/Baltasar-M2 references as historical unless Paulo explicitly revives that name.
- Rationale: Runtime memory and active topology notes identify the MacMini M2 extension as Guilherme. Older dashboard wording still mentioned former Baltasar wording and could cause future confusion.
- Implication: Active dashboard text should say Guilherme-M2, with any Baltasar mention labeled as former/historical wording only.
- Status: active
- Source: Telegram/Hermes session, 2026-06-15
- Related: [[33.07 Guilherme M2 Extension]], [[33.06 Xavier Memory Dashboard]], [[33.11 Xavier Machines Map Context]]

### 2026-06-21 — Use Obsidian access as the first Core-GUI coordination bridge

- Decision: Because GUI already has access to the Xavier Obsidian vault, use Obsidian as the first practical coordination bridge between Xavier-Core and GUI before implementing Telegram-to-GUI, webhooks, SSH, Tailscale, or dashboard exposure.
- Rationale: The vault is already shared, durable, auditable, and aligned with the existing memory/governance model. It avoids adding a second Telegram identity or exposing the M2 before the operating rules are proven.
- Implication: For non-urgent local workstation tasks, Xavier-Core can write scoped handoff/task notes and GUI can read, execute locally, and write results/evidence back. Direct chat or dashboard control can remain a later layer for urgent/interactive work.
- Status: active as first-layer direction; exact queue schema still open
- Source: Telegram/Hermes session, 2026-06-21
- Related: [[33.07 Guilherme M2 Extension]], [[33.09 Draft Core-GUI Routing Architecture]], [[33.05 Hermes Memory Mirror Policy]], [[33.06 Xavier Memory Dashboard]]

### 2026-06-22 — Prefer Hermes Desktop as a window into Xavier-Core when feasible

- Decision: If Hermes Desktop on Guilherme/MacMini M2 can connect directly to the VPS Hermes/Xavier-Core instance, treat that as the cleaner default for many interactions before building “two agents talking” infrastructure.
- Rationale: A direct desktop client for the canonical VPS instance preserves one memory, one policy surface, one tool/governance model, and avoids unnecessary routing complexity between Xavier-Core and GUI.
- Implication: Guilherme/M2 can serve partly as a local desktop window into Xavier-Core. A separate local GUI agent remains useful only for M2-specific desktop/files/browser/app work that genuinely requires local execution.
- Status: active direction; needs technical verification in Hermes Desktop/VPS configuration before being treated as implemented.
- Source: Telegram/Hermes session, 2026-06-22
- Related: [[33.07 Guilherme M2 Extension]], [[33.09 Draft Core-GUI Routing Architecture]], [[33.06 Xavier Memory Dashboard]]

### 2026-06-28 — Treat Hermes Desktop remote access as Desktop → Dashboard, not Desktop → Telegram/API Server

- Decision: For Guilherme/MacMini M2 remote UI access to Xavier-Core, configure Hermes Desktop's **Remote gateway** to connect to a remote `hermes dashboard` process on the VPS, not to the Telegram gateway and not to the OpenAI-compatible API server.
- Rationale: Nous documentation states that Desktop normally launches a local backend but can attach to a dashboard running on another machine via `Settings → Gateway → Remote gateway`. The dashboard is the backend for Desktop; the API server is for OpenAI-compatible clients, and the messaging gateway is separate.
- Implication: The Xavier-Core VPS needs a reachable `hermes dashboard` on port `9119` for Desktop remote access. If exposed beyond localhost, it must use dashboard authentication and network controls. Preferred secure pattern is SSH tunnel or Tailscale; a direct `0.0.0.0:9119` exposure is only a controlled test path with basic auth and restrictions.
- Status: active clarification; implementation paused after 2026-06-28 test because Desktop remote-gateway runtime remained unstable.
- Source: Telegram/Hermes session plus Nous documentation check, 2026-06-28
- Related: [[33.07 Guilherme M2 Extension]], [[33.09 Draft Core-GUI Routing Architecture]], [[33.13 GUI Xavier-Core Handoff]], [[33.14 Hermes Desktop Remote Gateway Investigation]]

### 2026-06-28 — Pause, but do not abandon, Hermes Desktop as a thin client for Xavier-Core

- Decision: Do not treat the Hermes Desktop → Xavier-Core remote-gateway path as production-ready today, but keep it as a high-value architecture goal to revisit.
- Rationale: The Tailscale/private-dashboard path worked at the network layer, but Hermes Desktop still appeared to use the Mac local runtime or failed with a gateway/recovery error after adding the dashboard token. Upstream/community issues show the same class of Remote Gateway problems: `/api/status` succeeds, while WebSocket/session/reconnect handling fails or falls back to local backend.
- Implication: For now, Xavier-Core remains canonical through Telegram and browser dashboard over Tailscale; Hermes Desktop on Guilherme remains local unless explicitly proven remote. Future attempts should start from the documented investigation note and upstream issue status rather than repeating discovery.
- Status: paused / revisit later
- Source: Telegram/Hermes session plus upstream issue research, 2026-06-28
- Related: [[33.13 GUI Xavier-Core Handoff]], [[33.14 Hermes Desktop Remote Gateway Investigation]], [[33.09 Draft Core-GUI Routing Architecture]], [[33.07 Guilherme M2 Extension]]

### 2026-07-02 — Use Discord as the agent control plane and Obsidian as the decision source of truth

- Decision: Adopt the five-part governed messaging setup: (1) Discord as the operational control plane for agents, (2) Telegram as Paulo-facing channel for direct conversation and important escalations, (3) domain/channel separation for agent workstreams, (4) minimal necessary permissions and no secrets in chat/notes, and (5) clear cron/watchdog delivery targets.
- Rationale: Discord is better suited to lower-priority operational traffic, threaded work, logs, channels, and multi-agent noise. Telegram should stay low-noise and human-facing. Obsidian remains the durable, curated layer where decisions, rejected options, operating rules, project state, and reusable context are preserved.
- Implication: Discord messages are not treated as memory by default. Durable conclusions from Discord must be promoted into the Xavier Obsidian vault using the same decision/synthesis quality standards used for Telegram conversations. Secrets, tokens, webhook URLs, and credentials stay out of Discord, Obsidian, runtime memory, skills, logs, and summaries.
- Status: active direction; exact Discord channel layout and delivery routing still need implementation/registry.
- Source: Telegram/Hermes session, 2026-07-02
- Related: [[33.01 Xavier Operating Model]], [[33.05 Hermes Memory Mirror Policy]], [[33.06 Xavier Memory Dashboard]]

### 2026-07-05 — Govern transversal knowledge with JD ownership, Obsidian links, and OKF-lite freshness

- Decision: Adopt a transversal knowledge governance model for multi-use material: Johnny.Decimal folders define canonical ownership, Obsidian links/backlinks/section links/block links express contextual use, and OKF-lite metadata is applied selectively to critical maintained notes to manage freshness and data rot.
- Rationale: A study, source, or concept can serve PhD research, teaching, executive work, Voice Lab, Career Architecture, and future writing at the same time. Filing it only under one project reduces recovery and agility; copying it into every project creates redundancy and stale interpretations. The chosen model preserves one canonical owner while allowing many project-specific uses.
- Implication: `60-69 Sources` acts as the source/reference layer, `40-49 Knowledge` holds reusable interpreted concepts, and `30-39 Projects` holds situated use, decisions, outputs, and implications. OKF-lite fields such as `status`, `updated`, `review_after`, `freshness`, `resource`, and `sources` should be used on critical maintained notes, not imposed on the whole vault.
- Options considered:
  - Keep only the current JD model — rejected as insufficient for data rot and multi-context retrieval.
  - Convert the whole vault to OKF — rejected as too rigid and mismatched with Xavier as an operational workspace.
  - Use OKF-lite selectively — chosen as the lowest-friction freshness layer.
- Status: active governance direction; implementation is evolving.
- Source: Telegram/Hermes session, 2026-07-05
- Related: [[02.05 Transversal Knowledge Governance and OKF-lite Freshness Model]], [[02.01 Vault Schema]], [[02.02 Vault Data Governance Audit 2026-07-04]], [[02.04 Vault Governance Guardrails and Night Run]]

### 2026-07-20 — Operate the vault owner-first and depth-first before creating new JD notes

- Decision: Xavier should use the Obsidian vault more in depth: identify the canonical owner note first, restructure or deepen that note when useful, and create new Johnny.Decimal notes only when the material has a strong independent role.
- Rationale: Paulo identified that recent Voice Lab strategy work and some classification examples challenged the vault's data-governance model by opening new entries too readily instead of using existing in-depth owner notes.
- Implication: For PhD/article work, material that deepens Article 1, 2, or 3 goes first to [[37.62 Article 1]], [[37.63 Article 2]], or [[37.64 Article 3]]. For Voice Lab during recruitment, [[32.25 Recruitment-Neutral Landing Page Strategy]] is the strategy owner and [[32.01 Voice Lab Dashboard]] must stay dashboard-light. Before new JD creation, Xavier should answer: owner? update vs new object? lifecycle? dashboard exposure? why not a section in the owner note?
- Status: active governance rule.
- Source: Telegram/Hermes session, 2026-07-20.
- Related: [[32.01 Voice Lab Dashboard]], [[32.03 Voice Lab Decision Register]], [[37.01 PhD Research Dashboard]], [[37.09 Decisions and Open Questions]], [[02.05 Transversal Knowledge Governance and OKF-lite Freshness Model]].

### 2026-07-24 — Treat Hermes updates as controlled operations changes

- Decision: Future VPS/container Hermes updates should use a small preflight/update/verification runbook rather than improvising from the active browser session.
- Rationale: The July 2026 update succeeded technically but was stressful because a stale public browser route failed (`32787`) while a different route worked (`32788/chat`), and the active runtime was inside a container rather than directly on the VPS host. Dashboard/TUI, Telegram/Discord gateway, provider/auth, and public port routing need separate checks.
- Implication: Before declaring an update successful or failed, Xavier should verify backup state, internal dashboard `/api/status`, gateway state, provider/auth route, and the current public URL separately. Browser disconnects should be diagnosed as access-layer failures first when internal health remains good.
- Status: active
- Source: Hermes/TUI session, 2026-07-24
- Related: [[51.09 Hermes Update Runbook]], [[51.02 Hermes Operating Notes]], [[51.08 Gateway Emergency Recovery]], [[53.03 Hermes Backups]]

### 2026-07-29 — Use Agent Reach as Xavier's low-friction web capability layer

- Decision: Keep Agent Reach as Xavier's preferred supplemental web/search capability layer for less fragile internet lookup, using the safe zero-login stack first: `agent-reach`, `mcporter`/Exa, Jina Reader, `yt-dlp`, RSS/feedparser, V2EX, and Bilibili basic.
- Rationale: Browser automation on the VPS is fragile and repeated low-risk web lookups created approval friction. Agent Reach gives Xavier alternative CLI/MCP-style routes for reading/searching the web without immediately requiring browser sessions, cookies, or social-platform logins.
- Implication: For current web research, Xavier should first use the installed zero-login capabilities and the [[agent-reach-web-capability]] skill/runbook. More invasive channels — Chrome/OpenCLI extension, LinkedIn/Twitter/Reddit/Facebook/Instagram with cookies/login, or other account-backed access — require explicit separate approval, least privilege, and no secrets in chat/notes/logs.
- Implementation state: installed and verified on Xavier-Core as `agent-reach` v1.5.0, `yt-dlp` 2026.07.04, and `mcporter` 0.9.0 under `/opt/data/home/.local/bin` and `/opt/data/home/.local/node_modules/.bin`; PATH persistence configured through shell startup files; Hermes approvals set to `smart` with 180s timeout in `/opt/data/config.yaml`.
- Status: active / implemented for zero-login web capability; optional account-backed integrations not enabled.
- Source: Hermes/TUI session recalled and live-verified on 2026-07-29.
- Related: [[51.02 Hermes Operating Notes]], [[51.03 Hermes Skills]], [[33.12 Xavier Decision Register]]

## Related

- [[33.01 Xavier Operating Model]]
- [[33.05 Hermes Memory Mirror Policy]]
- [[33.06 Xavier Memory Dashboard]]
- [[33.07 Guilherme M2 Extension]]
- [[33.11 Xavier Machines Map Context]]
- [[51.07 Messaging Targets Registry]]