Hunter OS Discord integration: canonical data, cards, audit, and /hunter

[AreteDriver]

Implementation plan and audit are now tracked in docs/projects/HUNTER_OS_DISCORD_PLAN.md on branch feat/hunter-os-discord-v1.

Objective

Integrate Hunter OS into the existing Animus Discord application as a canonical, Wilds-only knowledge domain with:

• structured data;
• audit/provenance;
• deterministic mobile cards;
• /hunter read interface;
• later forum publishing;
• grounded conversational routing.

Critical Phase 0 gate

The live Discord command list shows commands not all present in the current standalone bot source. Before adding /hunter, establish which process/code path owns the live application token and global command synchronization.

Initial vertical slice

• Rathian
• Hunting Horn universal controls/system rules
• Combat Healer HH + LBG
• Omega Planetes special encounter

V1 exit

Read-only /hunter monster|weapon|guide|search|audit|card, deterministic cards, isolated Hunter OS data, tests/lint passing, and no regressions to existing Animus commands.

See the plan document for source audit, schema, security boundaries, phases, risks, and definition of done.

[AreteDriver]

Initial work started.

Audit findings

• Live Discord command surface does not fully match tools/animus_discord_bot.py on main. /build exists in the separate kernel bot; /animus_status and /ping are not present in the current main code search. Runtime ownership remains Phase 0 gate.
• Standalone bot uses broad Animus memory for conversational context. Hunter OS will remain isolated from general memory for correctness/privacy.
• Core does not declare the Discord dependency used by the standalone tool; dependency/runtime ownership will be resolved before live wiring.
• Existing Hunter OS sources include later audited documents plus older UI/manual generations. Migration will use explicit provenance and semantic target fields rather than silently overwriting legacy differences.
• Special encounters require a different record/card family from normal monsters.

Implementation

Draft PR #129 now contains:

• Hunter OS project plan/audit;
• animus.hunter_os models/repository/audit foundation;
• source-grounded seed records for Rathian, Hunting Horn, Combat Healer HH+LBG, and Omega Planetes;
• foundation tests.

The first lint run found one Hunter OS import-order issue; fixed. Current lint failure is now limited to four pre-existing errors in untouched files. Core test CI is still running.

[AreteDriver]

Architecture clarified and plan updated.

Forums are display-only/reference surfaces. The three existing forums (Weapons, Monsters, Hunter Guide) will contain curated cards + searchable summaries only. Animus should not use them as conversational threads.

The existing Monster Hunter chat channel is the conversational interface. Friends can ask natural questions there and Animus will answer from canonical Hunter OS records.

Updated execution order:

1. runtime ownership audit;
2. canonical Hunter OS foundation;
3. mobile card renderer;
4. grounded MH chat routing;
5. full data migration;
6. forum publisher;
7. patch maintenance.

A friend-facing /hunter command is no longer required. Any /hunter commands will be owner/admin maintenance tools (audit/card/publish/status) if useful.

[AreteDriver]

Security-first chat work is now implemented on draft PR #129.

Added:

• HunterOSChatPolicy with deny-by-default channel/guild/admin allowlists;
• mentions required by default;
• DMs denied by default;
• isolated HunterOSChatService that never reads general Animus memory;
• natural-language record search across canonical record contents;
• Hunter-only system prompt that forbids general-memory/model-knowledge gap filling;
• tests for channel/guild isolation, admin allowlist, natural search, unknown-fact behavior, and no-memory grounding;
• future Discord bot routing that treats configured Hunter chat channels as a hard boundary and returns before MemoryLayer.recall();
• routine Discord message logs no longer include message text, only content length;
• security design doc: docs/projects/HUNTER_OS_SECURITY.md.

No live deployment is being attempted until Phase 0 identifies the actual running Discord command owner.

[AreteDriver]

Phase 0 runtime audit update from the live Ubuntu host:

• Exactly one local Animus Discord process is running.
• systemd unit: /etc/systemd/system/animus-discord.service.
• runtime entry point: /home/arete/projects/animus/tools/animus_discord_bot.py.
• runtime venv: packages/core/.venv.
• service environment: ~/.config/animus/discord.env.
• process has been running since 2026-09-21 13:37 PDT.
• local worktree is clean.
• live local HEAD is e030b7e634bd08770a61bbf4c2c55fdea22aafa4.
• that SHA does not exist on the GitHub remote, so the live deployment contains at least one local-only commit/history state.
• current filesystem grep finds /harvest and /ask in the standalone bot, while /build exists in the separate kernel implementation; /animus_status and /ping are not in the current filesystem search.

Conclusion: command ownership is now narrowed to the single systemd standalone bot on this host, but the live source must be preserved/pushed before reconciling the deployed local commit with remote main and PR #129. Do not restart or pull over the live checkout yet.

[AreteDriver]

Phase 0 backup branch inspected.

The live host commit e030b7e... is cleanly preserved on backup/live-discord-2026-09-22. Its only code delta from the common base is the removal of an unused json import in packages/kernel/src/animus_kernel/head/tool_orchestrator.py.

The current remote main and the live branch diverged by one commit each; the Hunter OS feature branch is based on remote main. I copied the live one-line lint fix into the Hunter OS branch so that deployment will not regress the running host's local fix.

The live tools/animus_discord_bot.py itself matches the remote version inspected. Extra Discord commands visible in the Integration UI are therefore not coming from a different local file/process. They are likely stale/guild-scoped registrations or registrations created by another historical runtime. Hunter OS chat does not need new slash commands, so we can proceed without relying on those command registrations.

[AreteDriver]

Deployment configuration can now be prepared for the real shared Monster Hunter chat channel. Per the security design, the actual Discord channel/guild IDs will stay in the host environment file, not canonical Hunter OS YAML or repository source. The existing Hunter OS Forum parent/thread IDs are already observable from the live bot logs; only the server/guild ID remains needed for the optional second allowlist layer.

[AreteDriver]

Text-first pivot completed for today's Discord library publish.

Created minimal deployment branch deploy/hunter-os-text-v1 from the preserved live-host branch, with no changes to the running bot.

Draft PR #130 contains:

• 40 Weapons sections/messages (14 weapon controls + HH/LBG specialist + HH songbook/role data);
• 37 Monsters sections/messages (35 audited monster/special encounter entries + variant rule);
• 24 Hunter Guide sections/messages (quick reference, combat healer, Palico, farming, database, progression, Artian);
• idempotent Discord REST publisher;
• safe separate-worktree deployment instructions.

Validation: all current sections fit under the 1900-character safe Discord message limit without truncation. Images are deferred to a later upgrade.