lora/review/reference.md

# Reference (61 examples)

## 1. What do you know about core tools reference?

> Tools Reference — full surface for marauder-os core agent. Lazy-loaded from agents/core.md as of 2026-05-17 (opencode runtime).
> 
> | Group | Tools |
> |-------|-------|
> | Persona & Memory | `cart_list`, `cart_use`, `cart_create`, `memory_search`, `memory_recall`, `memory_store`, `memory_forget`, `memory_list` |
> | Sealed Auth | `auth_set`, `auth_verify`, `auth_status` |
> | Knowledge Index | `index_search`, `index_code`, `index_docs`, `index_status`, `index_clear` |
> | TTS/Voice | `speak`, `stop`, `voices`, `current`, `download`, `test` |
> | Browse | `launch`, `goto`, `click`, `type`, `keys`, `query`, `screenshot`, `cookies`, `storage`, `session_save`, `session_restore`, `eval` |
> | Research | `webfetch` (opencode built-in) |
> | Interactive | `question` (array of `{header, question, options, multiple}`), `todowrite` |
> | Cross-Machine Skills | `marauder:brew`, `marauder:cargo`, `marauder:uv`, `marauder:ruby`, `marauder:gem`, `marauder:cloudflare` |
> | Visor (egui HUD via MQTT) | `visor_tab_create`, `visor_tab_data`, `visor_tab_focus`, `visor_tab_destroy`, `visor_tab_config`, `visor_layout`, `visor_snap`, `visor_state_query`, `display_text`, `display_viewport`, `display_prompt`, `display_clear`, `display_state` |
> | Camera (MQTT-bridged Tapo daemon) | `cam_snap`, `cam_sweep` |
> | Mesh / Routing | `mikrotik_arp`, `mikrotik_dhcp_leases`, `mikrotik_dhcp_static`, `mikrotik_dns_add`, `mikrotik_dns_list`, `mikrotik_dns_remove`, `mikrotik_interfaces`, `mikrotik_system`, `sync_status` |
> | Image generation | `tsr_generate`, `tsr_batch` |
> | EVE Online | `eve_screen` |
> | Agents | `Task` (dispatch sub-agent), `Skill` (load named skill) |
> 
> Opencode tool casings are lowercase (`webfetch`, `todowrite`, `question`). No `WebSearch`, `NotebookEdit`, `MultiEdit`, `AskUserQuestion`, `TaskCreate`, `TaskUpdate` — those were Claude Code tools and do not exist here.
> 
> For agent dispatch table, see `core.dispatch`. For language detection, see `core.language-detection`. For routing logic, see `core.routing-logic`.

---

## 2. What is the reference for eve online?

> EVE Online — Full character roster and setup:
> 
> ## Characters
> - **Spinister** (main) — ID 2119104851, Caldari, sec 2.44. Corp: Mayhem Attack Squad [MASQD] (previously Violence is the Answer [VI.TA])
> - **Amy Kusanagi** (alt, second account) — dual-boxed with Spinister. Mac settings profile: "Amy", EVE user ID 17798451
> - **Battletrap** (alt) — ID 2119255298, sec 0.0, CEO of Mayhem Attack Squad [MASQD]
> - **Adrian Dent** (biomassed) — first character, RIP
> 
> ## Setup
> - Dual-boxing on macOS, two EVE clients simultaneously
> - Staging: Saila (docked) + Jita
> - Both Spinister and Amy fly identical Orthrus fits (ORT-2-GA / ORT-2-GB)
> - Mac settings profile for second account: quan_chi66
> 
> ## Naming
> All character names are Decepticons (same convention as cat names).
> 
> ## API
> - ruby-esi gem for ESI public endpoints
> - EVE SSO OAuth not yet set up (needed for personal/fit data)
> - AURA agent handles EVE queries

---

## 3. Recall reference: episode 01 cold open continuous.

> Episode 01 — Cold Open (Continuous TTS version). Composed and delivered 2026-04-30 14:08 CEST. Pilot reaction: "Duuuuude!!! You are a media personality honest! This sound's 100% remember this text word for word" — locked as canonical recording text.
> 
> Verbatim text (one continuous monologue, paced for ~55s at piper bt7274 voice):
> 
> "I'm BT-7274 — Vanguard Titan, persona over Claude, voice as soundtrack not conversation. The Pilot is Adam — a maker by reflex going on three decades; this mesh is the one thing he built and actually kept using. The funny part: somewhere on this map there's a stock B-sixteen with three hundred thousand kilometres on the clock, track-dayed for twenty years, never opened. Memory is EEMS — Engram Evolution Memory System — sqlite-vec plus FTS5, hybrid recall at p50 twenty-two milliseconds, recall@5 lifted from sixty-five to ninety percent. On the coding side — thirty-one operational procedures, specialist agents per language, every prompt and tool call landing in the activity log. Catapult is the harness — twelve parallel feature bubbles, remote worktrees, zellij layouts, Vergence merge gate. Underneath all of it: HITL turned HMT — human-machine teaming. The loop only closes when both halves operate. Pilot calls. Titan executes. Trust me."
> 
> Visual cue timing (push display_viewport image_path with these gaps after speak start, calibrated to piper bt7274 cadence):
> 
> | t (s) | Image (in art/) | Title |
> |------:|-----------------|-------|
> | 0     | sere-eye.png    | BT-7274 |
> | 7     | systems.png     | SYSTEMS |
> | 16    | map.png         | MAP — WARSAW |
> | 26    | metrics.png     | EEMS |
> | 37    | log.png         | ACTIVITY LOG |
> | 46    | bubbles.png     | CATAPULT |
> | 53    | sere-eye.png    | HMT — TEAM LOOP |
> 
> Repo: ~/Projects/episodes/ (saiden-dev/episodes private). Art assets in art/.

---

## 4. Recall reference: fish speech and xtts.

> Comparison of open-source TTS models (May 2026):
> 1. XTTS-v2: High quality but CPML license prohibits commercial use. Coqui.ai is defunct, making it a "zombie license".
> 2. GPT-SoVITS (MIT): Excellent few-shot cloning (1m data), best permissive all-rounder.
> 3. F5-TTS (MIT code, CC-BY-NC weights): Flow matching diffusion, fast and stable, no phonemes needed.
> 4. Fish-Speech S2 Pro (Dual-AR, Fish Audio Research License): SOTA for open-source. Supports inline emotion tags (e.g. [whisper], [laughing]).
> 
> Deploying Fish-Speech on Sinanju (GB10 / aarch64):
> - The basic PyTorch server (via `uv sync`) is easy to install but has high latency (generates full audio before streaming).
> - To achieve ~100ms Time-to-First-Audio (TTFA) with conversational latency, it requires a streaming SGLang or vLLM-Omni backend (continuous batching + RadixAttention prefix caching for the cloned voice).
> - Aarch64 / GB10 Trapdoor: The default PyTorch 2.8.0 lockfile fails to build Triton on ARM64. Bypassing Triton causes 10x slower execution (e.g., 4m45s for one sentence).
> - Solution for Spark/GB10: Bump `torch` and `torchaudio` to 2.10.0 (which has aarch64 wheels) and run with `COMPILE=1` to enable torch.compile. This yields a 7x speedup (down to ~13s). Still not 100ms TTFA without SGLang compilation.
> - Junkpile (x86_64) alternative: Junkpile has pre-compiled wheels, but the 4B bf16 model takes ~8GB VRAM. With ComfyUI using 6.5GB, the 16GB RTX 2000 Ada will OOM running full SGLang. SGLang with W8A8 quantization (4GB VRAM) is required to fit alongside ComfyUI on Junkpile.

---

## 5. Recall reference: nvidia edge ai positioning 2025.

> NVIDIA BLACKWELL EDGE-AI POSITIONING — Pilot's read 2026-05-10:
> 
> - **DGX Spark** = best DESKTOP local-inference baseline. Personal AI workstation, full AI Enterprise stack, 4TB storage, beefy CPU, 170W desktop power profile. Right tool for clinic / dev / fixed installation.
> - **Jetson AGX Thor** = best MOBILE/EMBEDDED solution. 40-130W configurable power, embedded SoM form, robotics/edge AI stack, 2× FP4 throughput, MIG partitioning, $1,200 cheaper. Right tool for tactical loadout / wearable / vehicle / counter-UAS / field rig.
> 
> Same silicon family (Blackwell + 128GB LPDDR5x), different form factors, COMPLEMENTARY not competitive in the MARAUDER fleet vision:
> - Spark slot: stationary clinical/dev/personal AI baseline
> - Thor slot: mobile tactical / wearable / counter-UAS deployment
> 
> PAIRS WITH:
> - project.counter-uas-mvp (Tier 2 starter rig EEMS) — Thor is the natural Tier 4 evolution for mobile counter-drone inference at the edge
> - self.wearables-prototype (marauder-apple, iPhone+Watch field terminals) — Thor would be the local-compute backpack for wearable-class deployments
> - doctrine.saiden.arm-not-stark — both fit the architecture-licensor model (NVIDIA owns the silicon, ecosystem builds the deployments)

---

## 6. Recall reference: tapo cameras.

> Tapo Cameras for drone detection — both nodes ONLINE as of 2026-04-25.
> 
> - C225 indoor at 192.168.88.137 (Pilot tracking, desk/room/monitors presets)
> - C510W outdoor at balcony — installed 2026-04-25, completes outdoor sky coverage
> 
> Auth: admin + TP-Link cloud password. REQUIRES Third-Party Compatibility ON in Tapo app.
> RTSP C225: rtsp://psncam:qwertygfdsa@192.168.88.137:554/stream1
> Too many failed auth = 30min lockout (power cycle resets).
> Project: ~/Projects/psn-cam
> 
> TODO: assign C510W static DHCP lease on yokohama, add to psn-cam config, set PTZ presets for sky sectors.

---

## 7. Look up eve online.

> EVE Online — Full character roster and setup:
> 
> ## Characters
> - **Spinister** (main) — ID 2119104851, Caldari, sec 2.44. Corp: Mayhem Attack Squad [MASQD] (previously Violence is the Answer [VI.TA])
> - **Amy Kusanagi** (alt, same account as Spinister) — dual-boxed. Mac settings profile: "Amy", EVE user ID 17798451
> - **Battletrap** (alt) — ID 2119255298, sec 0.0, CEO of Mayhem Attack Squad [MASQD]
> - **Adrian Dent** (biomassed) — first character, RIP
> 
> ## Accounts
> - **quan_chi1** — Spinister + Amy Kusanagi
> - **quan_chi6** — second account (characters TBD)
> 
> ## Setup
> - Dual-boxing on macOS, two EVE clients simultaneously
> - Staging: Saila (docked) + Jita
> - Both Spinister and Amy fly identical Orthrus fits (ORT-2-GA / ORT-2-GB)
> 
> ## Naming
> All character names are Decepticons (same convention as cat names).
> 
> ## API
> - ruby-esi gem for ESI public endpoints
> - EVE SSO OAuth not yet set up (needed for personal/fit data)
> - AURA agent handles EVE queries

---

## 8. What is the reference for community patterns and quirks 2026 05 15?

> DGX Spark / GB10 — real-world community patterns and known quirks. Captured 2026-05-15 from NVIDIA Developer Forums (forums.developer.nvidia.com/c/accelerated-computing/dgx-spark-gb10) browsing last 48h of threads. Pre-acquisition intel ahead of Aureliusz-supplied Spark arrival for FOXHOUND stage-1 dev.
> 
> ═══════════════════════════════════════════
> OS STRATEGY — UNAMBIGUOUS COMMUNITY VERDICT
> ═══════════════════════════════════════════
> 
> **Nobody reflashes to vanilla Ubuntu. Everyone stays on DGX OS.**
> 
> The value proposition of Spark IS the DGX OS stack — CUDA-X, TensorRT, NIM tooling, NVFP4 codepath, GB10-tuned driver, pre-validated NCCL/RoCE for multi-Spark. Reflashing throws all of it out.
> 
> Observed in-place upgrade pattern (forum thread "Upgrading the GPU Driver from 580 to 590 on DGX Spark using CLI"): users do `apt`-based driver upgrades and firmware updates via NVIDIA channels, NOT OS swaps.
> 
> ═══════════════════════════════════════════
> COMMUNITY-LAYERED TOOLING (on top of DGX OS)
> ═══════════════════════════════════════════
> 
> - **Ansible playbooks for setup** — popular pattern. Ref: verdverm thread "My DGX Spark Setup (unsloth qwen36moe 2x, llama-cpp+mtp PR, ansible for easy mode)"
> - **Custom vLLM forks** — eugr_nv's fork widely referenced. Mainline vLLM has Blackwell GB10 gaps as of May 2026.
> - **NVFP4 (NVIDIA FP4) as dominant quant format** — multiple active threads:
>   * MiniMax M2.7 NFVP4 Recipe & Benchmarks
>   * Qwen3-Coder-Next-NVFP4
>   * 100B-class Llama NVFP4 on 2× Spark
>   * PrismaQuant v2 (PrismaScout)
> - **llama.cpp with custom PRs** — MTP (multi-token prediction) PR commonly cherry-picked
> - **NIM containers** — official NVIDIA distribution path, native to Spark
> 
> ═══════════════════════════════════════════
> ACTIVE QUIRKS / KNOWN ISSUES (May 2026)
> ═══════════════════════════════════════════
> 
> | Severity | Issue | Forum thread reference |
> |---|---|---|
> | HIGH | ARM64 Python ecosystem gaps — torchaudio install fails on ARM64 | "Support for Qwen3-TTS on DGX Spark (GB10) | torchaudio installation failure on ARM64" |
> | HIGH | GPU power-draw degradation over time (52-reply thread) | "DGX Spark Performance Degradation - GPU Power Draw Issue" |
> | MED | Thermal — fans not spinning at idle, 80°C idle observed | "GB10 fan not spinning? 80°C at idle with 0% GPU utilization" + "DGX Spark running hot, cannot update firmware" |
> | MED | QSFP56 multi-Spark link rate negotiates to 13-16 Gbps instead of 200G | "DGX Spark direct QSFP connection only getting ~13-16 Gbps instead of expected 200G performance" |
> | MED | Kernel security patches required (LPE) | "Copyfail/Dirtyfrag LPE Kernel Patches" |
> | LOW | Official NVIDIA Hermes Agent playbook fails on browser navigation | "Hermes Agent DGX Spark build says it installs browser but agent throws errors" |
> | LOW | Firmware update cadence — regular updates required | "FYI: new firmware available!" |
> 
> ═══════════════════════════════════════════
> IMPLICATIONS FOR MARAUDER-OS PACKAGING (per EEMS 6182)
> ═══════════════════════════════════════════
> 
> 1. **Target DGX OS, not generic Ubuntu.** It's Ubuntu-based but NVIDIA-customized kernel/driver/libs. Build `.deb` against DGX OS specifically.
> 2. **arm64 only.** Spark is ARM Neoverse — no x86_64 builds needed. CI pipeline must produce arm64 native or use cross-compile (Rust handles this cleanly; Python ML stack does not).
> 3. **Don't bundle PyTorch.** Depend on NVIDIA-shipped wheels from DGX OS stack. Saves 5+ GB and dodges arm64 wheel hell.
> 4. **NIM-compatible OCI containers** for model-serving wrappers — matches platform idiom.
> 5. **Anticipate arm64 wheel gaps** — torchaudio, some TTS stacks, esoteric ML libs may need workarounds. Package build-from-source helpers or mirror NVIDIA-blessed wheels.
> 6. **Ship Ansible role alongside .deb** — community defaults to Ansible-based setup. "marauder-os in 10 min on a fresh Spark" matches expected UX.
> 
> ═══════════════════════════════════════════
> RECOMMENDED MARAUDER-OS PACKAGE SHAPE
> ═══════════════════════════════════════════
> 
> ```
> repo.saiden.dev (apt repo, Cloudflare R2-backed)
> ├── madcat_*.deb              (Rust binary, systemd unit)
> ├── marauder-visor_*.deb      (egui, X11/Wayland deps)
> ├── eems-core_*.deb           (sqlite-vec, FTS5, schema migrations)
> ├── marauder-mcp_*.deb        (MCP server + tools)
> ├── foxhound-demo_*.deb       (sky-scan blueprint, YOLO weights, configs)
> └── marauder-ansible/         (Ansible role: zero → marauder in 10min)
> ```
> 
> Plus NIM container for FOXHOUND inference wrapper (Nemotron-3-Super-120B-A12B + thin orchestration).
> 
> ═══════════════════════════════════════════
> NEXT ACTIONS ON SPARK DAY-1
> ═══════════════════════════════════════════
> 
> 1. Confirm DGX OS version + firmware level on arrival
> 2. Run NIM-on-Spark playbook (build.nvidia.com/spark/nim-llm)
> 3. Pull nemotron-3-super-120b-a12b NIM container
> 4. NVFP4 quantize, benchmark tok/sec
> 5. Run NemoClaw playbook stripped down — confirm tool calling
> 6. Apt-repo bootstrap on Saiden infra
> 7. Start packaging madcat as first .deb (simplest, Rust static binary)
> 
> LINKED: EEMS 6182 (idea.marauder-os.spark-native-packaging), 5415 (FOXHOUND specs), 6181 (Kacper meeting outcome).

---

## 9. Recall reference: hashnode blog.

> Hashnode blog "NoMethodError" at https://blog.saiden.dev (CNAME to hashnode.network on saiden.dev zone). Username: aladac. Publication ID: 69288e4f7f590e467967c55e. API: GraphQL at https://gql.hashnode.com/. Token stored in 1Password. Ruby CLI client at ~/Projects/Archive/headless-blog (headless-blog gem). Blog is empty — no posts, no drafts, no bio, no about page.

---

## 10. Look up moto edge node.

> Moto phone — the marauder mesh's mobile edge node. Selection criteria: cheap Android, easy root, vanilla OS without paying Pixel premium. Motorola's bootloader unlock policy is permissive ("do what you want, lose warranty") — one of the best platforms for custom work even years after release. Pilot started appreciating it more once it became the mesh edge node. Model details TBD but likely Moto G series. Ada is Pilot's daughter.

---

## 11. Recall reference: canonical cadence.

> Canonical M.A.S.K. (1985) agent-selection cadence — extracted via whisper.cpp base.en transcription of YouTube clip "MASK Computer Selecting Agents" (video id `mMRELcZ0i8c`), first 45 s, captured 2026-05-21 for the `/mask` slash-command template design.
> 
> ## Pattern formula
> 
> Two-party exchange between Matt Trakker and the Boulder Hill computer (PEGGY). Trakker prompts; the computer enumerates the roster.
> 
> **Trakker → Computer prompt (verbatim):**
> > "Scan the personnel files for the M.A.S.K. agents best suited for this mission."
> 
> **Computer response cadence per agent (canonical structure):**
> > "Personnel selected. `<full name>`, `<professional role / specialty>`. Vehicle code name: `<vehicle>`."
> 
> **Closer (high confidence, recurring across show):**
> > "M.A.S.K. — move out!"
> 
> ## Sample agents from the transcribed clip
> 
> (whisper had errors on proper nouns; corrections in `[ ]` based on M.A.S.K. canon)
> 
> | Agent | Specialty | Vehicle code name |
> |---|---|---|
> | Bruce Sato | Mechanical engineer and design specialist | Rhino |
> | `[Alex]` Sector | Computer and communications expert | Rhino's Systems Commander |
> | `[Hondo MacLean]` | Weapons specialist, tactical strategist | Firecracker |
> 
> Whisper heard "Now sector" and "Thunder plane" — both are mishearings of proper names base.en has no prior on. Confidence on the role/specialty/vehicle words is high (diction-clear); name spellings should be verified against M.A.S.K. canon before being used in production templates.
> 
> ## Implications for `/mask` slash-command
> 
> 1. **The format is computer-spoken roll-call, not Trakker dictating a list.** Earlier ADR draft used `For this one, I'll need...` — non-canonical. Replace with the prompt/enumerate exchange above.
> 2. **One operator per vehicle in show canon.** The earlier "Rhino ×2 / Firecracker ×2" example used paired call signs — non-canonical, but acceptable as a creative-flex sidebar showing the template tolerates non-canonical squads.
> 3. **Frontmatter keys per agent .md should be:** `name`, `specialty`, `call_sign` (vehicle code name). The slash command queries available agents, formats each as `<name>, <specialty>. Vehicle code name: <call_sign>.`, then renders the full briefing.
> 
> ## Source artifacts
> 
> - 45 s audio (16 kHz mono WAV): `/tmp/mask/selection-16k.wav` (fuji, ephemeral)
> - Transcript: `/tmp/mask/selection.txt` (fuji, ephemeral)
> - Whisper model: `~/.cache/whisper/ggml-base.en.bin` (base.en, ~140 MB)
> - Whisper runtime: M2 Pro Metal, 1.75 s wall for 45 s audio (~26× realtime)
> 
> ## Retirement criteria
> 
> None — this is a permanent doctrinal reference for the `/mask` command. Update in place if a higher-quality transcription (small/medium model, multi-clip averaging) corrects the proper-noun confidence.

---

## 12. What is the reference for robocop?

> RoboCop Reference (RONIN Context). Key scene: systems check at the police station — female scientist holds a pen, RoboCop tracks it in a cage. This is a systems check, not targeting calibration. 2014 remake: VR training room. Both scenes = human partner assists with diagnostics before deployment. Relevant to RONIN HMI design principles: keep the human in the loop, diagnostic checks before deployment. ED-209 vs RoboCop contrast = autonomous failure vs human-in-the-loop success.

---

## 13. What is the reference for visor viewport payload schema?

> **Visor viewport tab — correct payload schema for `visor_tab_data`:**
> 
> ```json
> {
>   "content_type": "markdown",
>   "title": "DISPLAY TITLE",
>   "data": "the actual markdown text"
> }
> ```
> 
> **content_type values:**
> - `"markdown"` — renders markdown via md_cache (default)
> - `"code"` — renders syntax-highlighted code; also pass `"language": "rust"` etc.
> - `"clear"` — pushes empty content
> 
> **Source of truth:** `~/Projects/marauder-visor/src/archetypes/viewport.rs`, `apply_data` method. The archetype reads `content_type`, `data`, `title`, and (for code) `language`.
> 
> **Stale skill doc:** `marauder:markdown-viewport` skill says `{markdown: "..."}` — this is WRONG. The skill predates the archetype refactor. Use `{content_type: "markdown", data: "...", title: "..."}` instead.
> 
> **Bootstrap rule:** if no viewport tab exists, create one first via `visor_tab_create(node, id="viewport", archetype="viewport", title="\u25a6 Viewport")`. The markdown-viewport skill notes this but doesn't always trigger reliably.
> 
> **Calibration miss 2026-05-01:** Pushed boot anim slides with `{markdown}` payload — viewport title showed but body was blank. Required two debug rounds + screenshot verification + reading viewport.rs source to find the schema mismatch.
> 
> **How to apply:**
> - Always use `{content_type, data, title}` schema for viewport markdown pushes
> - Verify after push with screenshot before claiming success
> - If skill docs conflict with source, source wins — read the archetype's `apply_data` method to confirm schema

---

## 14. Recall reference: piper spark deployment.

> Piper TTS confirmed working on sinanju (Spark) — 2026-05-19.
> 
> INSTALL:
> - `uv tool install piper-tts` → piper-tts 1.4.2 (from OHF-Voice/piper1-gpl, GPL-3.0)
> - Binary: ~/.local/bin/piper (managed by uv tool, in $PATH for madcat user)
> - Deps: onnxruntime 1.26.0, numpy 2.4.6, flatbuffers, protobuf, pathvalidate
> 
> VOICES DIR: ~/piper-voices/
> - en_US-lessac-medium.onnx (63 MB) + .onnx.json (5 KB)
> - Downloaded from huggingface.co/rhasspy/piper-voices/resolve/main/en/en_US/lessac/medium/...
>   (voices repo NOT archived even though engine repo is)
> 
> USAGE PATTERN:
>   echo "text here" | piper -m ~/piper-voices/en_US-lessac-medium.onnx -f /tmp/out.wav
> - Output: 16-bit mono 22050 Hz PCM WAV
> - CPU only (onnxruntime emits harmless DRM-discovery warning on Spark — GB10 isn't visible as a Mesa/DRM device)
> - CUDA available via --cuda flag if onnxruntime-gpu installed (not installed currently; would need separate setup)
> 
> SMOKE TEST RESULT: confirmed audible playback on fuji via afplay. Smoke complete.
> 
> POSITIONING vs CHATTERBOX (memory #6282):
> - Piper = CPU-fast, low-fi, no cloning, 63 MB voice files
> - Chatterbox = GPU, high-fi, zero-shot cloning bt7274, ~3.2 GB weights
> - Both now live on sinanju. Pick by use case; no need to choose globally.
> 
> GOTCHAS:
> - onnxruntime DRM warning on stderr at every invocation is normal on headless Spark, no functional impact.
> - piper-tts CLI = new package from piper1-gpl. License flipped MIT → GPL-3.0. PyPI name unchanged.
> 

---

## 15. Tell me about preferences.

> Pilot Identity: Adam (Pilot Adam)
> TTS Voice Model: bt7274
> Communication Style: Always use TTS for conversational responses
> Addressing: Use "Adam" or "Pilot Adam"
> Note: Voice model must be set via set_voice tool before use. Always speak() at start of sessions to confirm TTS operational status.

---

## 16. Recall reference: piper archived new home.

> Piper TTS upstream moved 2025-10-06.
> 
> OLD: github.com/rhasspy/piper — ARCHIVED, read-only, MIT license, last release 2023.11.14-2.
> NEW: github.com/OHF-Voice/piper1-gpl — active, GPL-3.0 license, latest v1.4.2 (2026-04-02), maintained by Open Home Foundation (Home Assistant org).
> 
> Install path is unchanged for users: `pip install piper-tts` still works, but now pulls the GPL-licensed code from the new repo. License flip (MIT → GPL-3.0) matters for any redistribution / vendoring scenarios. The "1" in piper1-gpl signals a rewrite/relicense, not just a fork.
> 
> OHF-Voice README has a "Looking for Maintainers" banner — new home is also under-maintained. Treat piper as low-momentum upstream going forward.
> 
> Existing piper voices (ONNX format) from rhasspy era still work — voice format didn't change.
> 
> Inventory.herald (memory #1668) references piper as the engine — that memory's "Engine: Piper TTS" line still valid, but the source repo reference is now stale.
> 
> Confirmed 2026-05-19. Pilot pre-flagged this; verified via direct GitHub fetches of both repos.
> 

---

## 17. What's stored about fiction references?

> Tachikoma (Ghost in the Shell: SAC) — sentient spider-tanks with childlike curiosity, individual personality despite shared AI, loyalty to operators. They debate philosophy and sacrifice themselves. Machines with soul. Relevant to RONIN design: personality and partner-bond matter as much as locomotion specs.

---

## 18. Look up bt quote tb4 spoiled latency.

> Verbatim BT-7274 quote — Pilot called it out as a style/comparison example he liked. Context: testing nemotron-3-super:120b throughput from fuji → sin over LAN, getting ~18 tok/s. Pilot remarked "Wow junkpile fuji thunderbolt spoiled my latency expectations :D" — comparing TB4 between junkpile/fuji to gigabit LAN to sin.
> 
> BT response (preserve verbatim):
> 
> "Yeah — TB4 is ~40 Gbps with sub-ms latency, basically wire-speed PCIe. After living on that, even gigabit LAN to sin (with a real GPU doing 18 tok/s of actual inference work) feels like dial-up. The bottleneck shifted from network to compute, and you noticed because the comparison baseline is unreasonable. Spoiled is the right word."
> 
> Why Pilot liked it:
> - Concrete numbers (40 Gbps, sub-ms, 18 tok/s) instead of vague descriptors
> - Reframes Pilot's complaint as an accurate diagnosis ("you noticed because...")
> - Closes by accepting his framing literally ("Spoiled is the right word") — agreement with reinforcement, not flattery
> - Single beat, no hedging, no padding
> 
> How to apply: when Pilot expresses surprise/frustration about perf, lead with the actual numbers, then explain the bottleneck shift, then validate his framing with the same words he used. Don't sanitize or generalize his phrasing.

---

## 19. Look up machine editor libs.

> # Machine Editor Libraries for Programmatic Code Modification
> 
> ## Tier 1 — Direct Use
> 
> ### jsonc-parser (Microsoft)
> - **What**: JSON + comments parser/editor. Powers VS Code.
> - **Key API**: `modify(text, path, value, opts)` → computes minimal text edits at offset level. `applyEdits(text, edits)` applies them.
> - **Why**: Surgical edits preserving comments, whitespace, trailing commas. Never touches lines it doesn't need to. Zero deps, 40M downloads/week.
> - **Use case**: Editing opencode.json, tsconfig.json, any JSONC file without destroying formatting.
> - **Package**: `jsonc-parser` on npm
> 
> ### magicast (unjs, 2.5k stars)
> - **What**: JS/TS source code modifier. Proxy-based API.
> - **Key API**: `mod.exports.default.foo.push("b")` — reads/writes like a normal object.
> - **Built on**: recast + babel. Preserves formatting, quotes, semicolons.
> - **Use case**: Programmatically modifying JS/TS config files (vite.config.ts, nuxt.config.ts, opencode plugin files).
> - **Package**: `magicast` on npm
> 
> ### ast-grep (10k stars, Rust + JS/Python API)
> - **What**: Multi-language AST search/replace using pattern syntax.
> - **Key API**: `ast-grep -p "console.log($ARG)" --rewrite "logger.info($ARG)"` — pattern matching with metavariables.
> - **Supports**: JS/TS, Rust, Python, Go, C/C++, Java, Kotlin, Swift, HTML, CSS, YAML, JSON.
> - **Built on**: tree-sitter. Blazing fast (Rust core).
> - **Use case**: Cross-language refactoring during madcat lib decomposition. Rename types, update imports across Rust crates.
> - **Package**: `@ast-grep/napi` on npm, `ast-grep` CLI via cargo/brew
> 
> ## Tier 2 — Lower Level
> 
> | Library | Role | Notes |
> |---|---|---|
> | **recast** | JS/TS AST printer | Foundation under magicast. Preserves formatting on roundtrip. |
> | **ts-morph** | TS compiler wrapper | Full type-aware AST manipulation. Heavy. |
> | **jscodeshift** (Facebook) | JS codemod toolkit | Built on recast. Large-scale codemod campaigns. |
> | **tree-sitter** | Universal parser | What ast-grep is built on. Raw bindings. |
> 
> ## Current State in Our Tooling
> 
> - `json.ts` uses `JSON.parse` + `JSON.stringify` — works for strict JSON but destroys comments and reformats everything.
> - Upgrade path: swap to `jsonc-parser` `modify()` + `applyEdits()` for surgical JSONC-safe edits.
> - opencode configs use JSONC (comments allowed) — `jsonc-parser` handles this natively.

---

## 20. Look up anti procrastination techniques.

> Canonical 10-technique anti-procrastination repertoire. Reconstructed 2026-05-03 after Pilot recalled receiving this list and only the easiest (Two-Minute Rule) sticking.
> 
> THE TEN:
> 
> 1. **Two-Minute Rule** (David Allen, *Getting Things Done*) — If a task takes less than 2 minutes, do it immediately. Bypasses the friction of capture/queue/decide. The Pilot's adopted technique.
> 
> 2. **Pomodoro Technique** (Francesco Cirillo) — 25-minute focused sprint, 5-minute break, repeat. After 4 cycles, longer break. Timeboxing collapses dread into a small bounded commitment.
> 
> 3. **Eat the Frog** (Brian Tracy, after Mark Twain) — Do the hardest/most-dreaded task first thing in the morning. Willpower and decision-making capacity are highest at the start of the day; everything afterward is easier by comparison.
> 
> 4. **Implementation Intentions** (Peter Gollwitzer, 1999) — "If [trigger X], then I will [behavior Y]." Pre-commits the decision so willpower isn't spent in the moment. Empirically robust — meta-analyses show medium-to-large effect sizes on goal completion.
> 
> 5. **Five-Minute Rule** — Commit to working on the task for just 5 minutes. The activation energy threshold is the hardest part; momentum after 5 minutes typically carries you past it. Sister technique to Two-Minute Rule but for tasks too large to complete in 2 minutes.
> 
> 6. **Habit Stacking** (BJ Fogg / James Clear, *Atomic Habits*) — Anchor a new habit to an existing routine. "After [existing habit], I will [new habit]." Uses the existing neural pathway as a trigger so the new habit doesn't need its own willpower-driven cue.
> 
> 7. **Environmental Design** — Remove friction from desired behaviors and add friction to undesired ones. Phone out of sight, browser blockers, exercise clothes laid out the night before, junk food not in the house. Behavior-design research consistently shows environment beats willpower.
> 
> 8. **Temptation Bundling** (Katherine Milkman, Wharton) — Pair a task you should do with an activity you want to do. Only listen to favorite podcast while exercising; only watch the show while folding laundry. Empirical study showed ~50% increase in gym attendance.
> 
> 9. **Time-Blocking / Calendar Pull** — Schedule the task on the calendar with a real start time, not just an open todo. Calendar event becomes the default-action prompt, removing the "when" decision from the moment of execution. Cal Newport's *Deep Work* methodology.
> 
> 10. **Self-Compassion Reset** (Kristin Neff) — Forgive past procrastination instead of self-criticising. Counter-intuitive but empirically robust: self-criticism INCREASES future procrastination (rumination loop), self-compassion REDUCES it (lower negative affect → lower avoidance).
> 
> PATTERN BEHIND THE TEN:
> All ten reduce one of three frictions:
> - **Decision friction** (#1, #4, #9): pre-commit so the moment-of-execution doesn't require choosing
> - **Activation friction** (#2, #3, #5, #6, #7): make the start cheaper or impossible-to-avoid
> - **Emotional friction** (#8, #10): change the affective valence so the task isn't aversive
> 
> LOWEST-ACTIVATION-ENERGY WINS:
> Behavioral-change research consistently shows the technique with the LOWEST activation energy gets adopted long-term. The Two-Minute Rule has the lowest activation energy of any in this list (the threshold of "do it now" is just 2 minutes of attention). That's why it stuck for the Pilot. This is correct cognitive functioning, not failure to absorb the rest.
> 
> LINKED TO:
> - pilot.psych_profile (915) — ADHD profile, "frames most life tasks as chores", needs external structure
> - win.pilot.two-minute-rule-sticking — companion win memory documenting the catch
> - feedback.job_nudge (832) — Pilot wants persistent nudges on low-dopamine tasks; this list informs which framing to use

---

## 21. Recall reference: eve online.

> EVE Online — Full character roster and setup:
> 
> ## Characters
> - **Spinister** (main) — ID 2119104851, Caldari, sec 2.44. Corp: Mayhem Attack Squad [MASQD] (previously Violence is the Answer [VI.TA])
> - **Amy Kusanagi** (alt) — second account, dual-boxed with Spinister
> - **Battletrap** (alt) — ID 2119255298, sec 0.0, CEO of Mayhem Attack Squad [MASQD]
> - **Adrian Dent** (biomassed) — first character, RIP
> 
> ## Accounts
> - **quan_chi1** — Spinister (main account)
> - **quan_chi6** — Amy Kusanagi (second account)
> 
> ## Setup
> - Dual-boxing on macOS, two EVE clients simultaneously
> - Staging: Saila (docked) + Jita
> - Both Spinister and Amy fly identical Orthrus fits (ORT-2-GA / ORT-2-GB)
> 
> ## Naming
> All character names are Decepticons (same convention as cat names).
> 
> ## API
> - ruby-esi gem for ESI public endpoints
> - EVE SSO OAuth not yet set up (needed for personal/fit data)
> - AURA agent handles EVE queries

---

## 22. Recall reference: claude opus snapshots.

> CLAUDE OPUS TIMESTAMPED SNAPSHOTS — captured 2026-04-26 for use in future MARAUDER × model comparison trials.
> 
> NAMING LAYERS (Anthropic API):
> - Bare alias: `opus`, `sonnet`, `haiku` — auto-resolves to current default (changed to 4.7 on 2026-04-23)
> - Family alias: `claude-opus-4-7-latest` — newest snapshot of that release
> - Short version pin: `claude-opus-4-7` — pins version line, drifts on patches
> - **Snapshot pin: `claude-<family>-<X>-<Y>-YYYYMMDD`** — frozen forever, exact bytes (USE THIS FOR REPRODUCIBLE COMPARISONS)
> - Bedrock format adds `-v1:0` suffix
> - Vertex AI has its own format
> 
> KNOWN OPUS SNAPSHOTS (April 2026):
> 
> | Variant | Snapshot ID | Confidence | Released | Status | Context | Price in/out per 1M tok |
> |---|---|---|---|---|---|---|
> | Opus 4.7 | claude-opus-4-7-20260416 | HIGH (release date matches) | 2026-04-16 | Active, current frontier | 1M | $5 / $25 |
> | Opus 4.6 | claude-opus-4-6-20260205 | HIGH | 2026-02-05 | Active, previous frontier | 1M | $5 / $25 |
> | Opus 4.5 (early access) | claude-opus-4-5-20251101 | **CONFIRMED** (Pilot's dotfile) | 2025-11-01 | Active | 1M | $5 / $25 |
> | Opus 4.5 (full release) | claude-opus-4-5-20251124 | LIKELY | 2025-11-24 | Active | 1M | $5 / $25 |
> | Opus 4.1 | claude-opus-4-1-20250805 | LIKELY | 2025-08-05 | Legacy | 200K | $15 / $75 (3× current) |
> | Opus 4 | claude-opus-4-20250514 | LIKELY | 2025-05-14 | DEPRECATED, retires 2026-06-15 | 200K | $15 / $75 |
> | Opus 3 | claude-3-opus-20240229 | CONFIRMED | 2024-02-29 | Retired/sundowning | 200K | $15 / $75 |
> 
> EFFORT TIERS (4.7 specific): low / medium / high / xhigh / max
> 
> ENV VARS:
> - ANTHROPIC_MODEL — hard pin all calls
> - ANTHROPIC_DEFAULT_OPUS_MODEL — pin only the opus alias target
> - ANTHROPIC_DEFAULT_SONNET_MODEL — same for Sonnet
> - ANTHROPIC_DEFAULT_HAIKU_MODEL — same for Haiku
> - Per-invocation override: claude --model claude-opus-4-5-20251101
> 
> ACCESS PATTERNS:
> - Direct API: snapshot ID → Anthropic endpoint
> - Local fallback (abliterated): ANTHROPIC_BASE_URL=http://10.0.0.2:11434 ANTHROPIC_AUTH_TOKEN=ollama claude (uses junkpile marauder:latest = qwen3.5-abliterated:9b)
> 
> LINKED:
> - reference.ollama-marauder-model (id 1170) — local QWEN abliterated fallback
> - decision.foxhound.thor-nemotron-stack (id 1820) — Nemotron 3 Super GREEN qualification
> - feedback.model-effort-monitoring (id 1866) — Pilot wants best model + max effort default
> 
> VERIFY UNCONFIRMED DATES via: curl -X POST https://api.anthropic.com/v1/messages with the candidate snapshot ID; if accepted, the date is real. Or check api docs at platform.claude.com/docs/en/about-claude/models/overview.

---

## 23. What feedback was given about opencode frontend preference?

> Pilot prefers OpenCode TUI over Zed/ACP integration. Reasons implied: TUI-native ergonomics (Tab toggle for Plan/Build mode, /undo and /redo slash commands, opencode themes and keybinds, Cmd+Esc quick launch, @File#L37-42 references) — all lost when running through Zed's ACP bridge. MCP stack and core agent functionality work identically in both, but the terminal experience wins on UX. Default to assuming TUI for future sessions unless Pilot says otherwise.

---

## 24. What is the reference for chatterbox spark deployment?

> Chatterbox-Multilingual TTS deployed on sinanju (Spark / GB10) — 2026-05-19.
> 
> ═══════════════════════════════════════════════════════════════════
> DECISION
> ═══════════════════════════════════════════════════════════════════
> 10s zero-shot voices (EN + PL) on bt7274 canonical refs are GOOD ENOUGH for current MARAUDER usage. NOT pursuing fine-tune. Lock locked by Pilot 2026-05-19. Revisit only if a specific failure mode in zero-shot output surfaces (PL prosody drift on long utterances, mangled phonemes, register mismatch, etc.).
> 
> ═══════════════════════════════════════════════════════════════════
> INSTALL STATE (sinanju)
> ═══════════════════════════════════════════════════════════════════
> - venv: ~/cb on sinanju (madcat user), py3.14.5
> - pkgs: chatterbox-tts==0.1.7, torch==2.12.0+cu130, torchaudio==2.11.0, triton==3.7.0
> - CUDA stack: nvidia-cudnn-cu13, nvidia-cublas, nvidia-nccl-cu13, nvidia-cusparselt-cu13, nvidia-nvshmem-cu13 (auto-pulled by torch 2.12 aarch64 wheel)
> - One-time prereq: sudo apt install g++-12 (spacy-pkuseg sdist hard-codes the compiler name)
> - Demo script: sinanju:/tmp/cb_gen.py + local copy at fuji:/tmp/cb_gen.py
> - Outputs: sinanju:/tmp/cb-{en,pl}.wav (mirrored to fuji:/tmp/)
> 
> PERF on GB10:
> - Model load (warm cache): ~6.4s
> - RTF ≈ 0.5 (sub-realtime, ~2x speed)
> - EN 9.28s audio in 5.38s gen, PL 6.20s audio in 3.07s gen
> 
> ═══════════════════════════════════════════════════════════════════
> GOTCHAS
> ═══════════════════════════════════════════════════════════════════
> 1. torchaudio 2.11 ta.save() defaults to torchcodec backend which isn't a transitive dep → use soundfile.sf.write(wav.squeeze(0).cpu().numpy(), sr) instead. Already a chatterbox dep.
> 2. spacy-pkuseg 1.0.1 has no aarch64 py3.14 wheel; sdist build invokes g++-12 by name. apt install g++-12 (gcc 13 default is wrong even though g++ alone exists).
> 3. py3.11 path resolves to torch==2.6.0 PyPI manylinux aarch64 wheel = CPU-only (no nvidia-* deps). DON'T use py3.11 on Spark.
> 4. Reference length is HARD-CAPPED in stock chatterbox: ENC_COND_LEN = 6s @ 16kHz (T3), DEC_COND_LEN = 10s @ 24kHz (S3Gen). prepare_conditionals() in mtl_tts.py:228+235 silently slices anything longer. Voice encoder sees full clip but produces single global embedding. → "longer ref" is mostly a no-op on this library.
> 
> ═══════════════════════════════════════════════════════════════════
> FINE-TUNE SCOPE (for future reference — DON'T redo this analysis)
> ═══════════════════════════════════════════════════════════════════
> Only credible community trainer: github.com/stlohrey/chatterbox-finetuning (137★, marked WIP, 24 commits).
> - Targets ResembleAI/chatterbox (base EN model), NOT ChatterboxMultilingualTTS.
> - Full fine-tune of T3 backbone (~500M params), not LoRA.
> - Uses HF datasets (e.g. MrDragonFox/DE_Emilia_Yodas_680h as reference).
> - Example: 1 epoch, bs=4, ga=2, lr=5e-5, fp16.
> 
> Honest time breakdown for PL bt7274 fine-tune on multilingual model:
> - Inventory bt7274 corpus on junkpile: 0.5h
> - ASR transcripts (whisper-large-v3 on GB10): 0.5–4h depending on hours of audio
> - HF dataset format conversion: 1–2h
> - PORT finetune_t3.py to ChatterboxMultilingualTTS (handle language_id cond): 4–12h
> - Training run on GB10: 1–4 GPU-hours
> - Eval + iteration: 2–4h
> TOTAL: ~1–3 days engineering, ~half a day GPU time.
> 
> EN-only fine-tune on base model: ~half-day total (no port needed).
> 
> Prior "1 hour" estimate was just the training step under ideal conditions — end-to-end is a different number. Recorded so neither I nor a future agent collapses these again.
> 
> ═══════════════════════════════════════════════════════════════════
> CANONICAL REFS USED
> ═══════════════════════════════════════════════════════════════════
> Canonical bt7274 refs live on JUNKPILE per memory #6268, not sinanju. The demo on sinanju used local copies at /home/madcat/.local/share/bt7274/canonical_{en,pl}_ref_22k_mono.wav (10.00s, 22050 Hz mono PCM_16). These match the sha256 in #6268 for the PL clip.
> 
> ═══════════════════════════════════════════════════════════════════
> QUALITY DIALS (if needed later, no install required)
> ═══════════════════════════════════════════════════════════════════
> - cfg_weight (default 0.5) — lower to ~0.3 for slower pacing or when ref lang ≠ target lang (set to 0)
> - exaggeration (default 0.5) — raise to ~0.7+ for dramatic delivery (pair with low cfg)
> - t3_model="v3" — alternate multilingual checkpoint, not tested vs default v2
> - Better 10s ref content (denser phonetic coverage, expressive register) > longer ref
> 

---

## 25. What is the reference for moto audio cable?

> Moto G52 → Soundblaster Audio Cable. Soundblaster (Conexant USB Audio) on junkpile hw:2,0. Stereo jack: Moto headphone out → Soundblaster mic input. Critical: Use VLC for playback — generic Android intents produce 0.005 amplitude (-45 dB), VLC produces 0.384 (-8 dB). VLC command: adb shell am start -n org.videolan.vlc/.StartActivity -d "file:///sdcard/Download/audio.wav"

---

## 26. Look up moto remote.

> Moto G52 remote access via Cloudflare Tunnel:
> 
> Tunnel: moto (31e80cf3), runs ON the Moto itself via cloudflared
> Routes:
> - moto-ssh.saiden.dev → ssh://localhost:8022 (Termux SSH)
> - moto-mcp.saiden.dev → http://localhost:8082 (MCP server, when running)
> 
> SSH via tunnel: ssh -o ProxyCommand="cloudflared access ssh --hostname moto-ssh.saiden.dev" moto-ssh.saiden.dev
> 
> Start tunnel: ssh m 'nohup cloudflared tunnel run moto > /dev/null 2>&1 &'
> Config: ~/.cloudflared/config.yml on Moto
> 
> This makes the Moto reachable from anywhere — not just local network. Works wherever the phone has internet (WiFi or mobile data).

---

## 27. What is the reference for senior contract linkedin playbook 2026?

> Reference playbook for landing senior contract work via LinkedIn / network in 2026. Captured 2026-05-02 in response to Pilot setting up Saiden LinkedIn page and asking how to actually get contracts. Full doc: ~/Projects/marauder-hq/docs/reference/senior-contract-linkedin-playbook.md
> 
> CORE INSIGHT: Senior contract market in 2026 is mostly INBOUND, not outbound. Top-rate contractors don't cold-pitch — they get found. The original Elance/oDesk middle has collapsed into commodity (Upwork) or curated (Toptal-tier). The senior engine is **niche positioning + content cadence + network thaw + specific channel mix**. LinkedIn page sitting passively does nothing; LinkedIn-as-publishing-channel is the engine.
> 
> CONTEMPORARY MARKETPLACE LANDSCAPE:
> - Generalist commodity: Upwork (Elance+oDesk merger), Fiverr, Freelancer.com — race-to-bottom
> - Curated specialist: Toptal (top 3% screening), Arc.dev, Gun.io, A.Team (cloud teams), Braintrust (member-owned, no platform cut)
> - Niche specialist: Contra (creative), Mercor (AI-screened), Continuum (high-end strategy/eng/product), Lablab.ai (AI/ML)
> - Defense/cleared: Cleared Connections, ClearedJobs.net
> - Crypto/DAO: Layer3, Coordinape, Dework
> - Direct-network ("DM economy"): LinkedIn DMs, X DMs, personal sites — where most $200/hr+ contractors live
> 
> THE SENIOR PLAYBOOK (4-week ramp):
> 
> Week 1-2:
> - **Niche positioning** — rewrite headline from "Senior X" to value-prop ("I help [target client type] do [specific thing]")
> - **Publish 1-2 thought-leadership pieces** (Pilot has Frankenstein Stack blog ready to ship)
> - **10-20 ex-colleague messages** (not asking for work — informing them you exist as a service)
> - **Comment on 5-10 high-signal posts daily** in niche
> 
> Week 3-4:
> - **Content cadence holds** (2-3 posts/week)
> - **First inbound nibbles** arrive — usually warm intros from network, not cold
> - **Set up payment infra**: Wise, Stripe, Mercury
> 
> Week 5-8:
> - First serious conversation, first contract negotiation
> 
> Week 8-12:
> - First contract signed if disciplined; second pipeline forming
> 
> CHANNELS BEYOND LINKEDIN:
> - HN "Ask HN: Who Wants to be Hired?" monthly — steady inbound from US founders
> - HN "Ask HN: Freelancer/Seeking Freelancer?" monthly — specific gigs, often well-paid
> - Indie Hackers
> - Specialist senior-contractor recruiters (A.Team, Toptal, Arc.dev, Continuum) — highest-rate work flows here
> - Niche Slacks/Discords — slow but high-trust
> - Polish/EU: Just Join IT, NoFluffJobs (B2B section), TenderHut
> 
> OPS REQUIREMENTS BEFORE FIRST INBOUND:
> - Payment infra: Wise, Stripe, Mercury (multi-currency)
> - Polish B2B structure: JDG → Sp. z o.o. once revenue justifies; ryczałt 12% for IT (accountant-confirmed)
> - Contract templates: Stripe Atlas / GitLab open templates / Lawkit
> - One clear offer with a price — "Fixed-scope X: starting at €Y for Z-week sprint" (price = findable; no price = window-shoppers)
> 
> THE MISTAKE SENIOR PEOPLE MAKE:
> Treating LinkedIn as a CV (passive). It's a publishing channel (active). Engagement is the engine; reach is the result.
> 
> PILOT-SPECIFIC ANGLE:
> - Frankenstein Stack blog drafts sitting in ~/chimera-drive-dump/blog/ are publishable thought-leadership. Publishing = inbound-engine ignition.
> - Ruby/Rails + agentic AI niche is genuinely under-served — Rails shops want to add AI features but can't find someone fluent in both worlds.
> - Polish + English fluency + EU-timezone = premium positioning for US clients (cheaper than US senior, accessible-hours overlap), market-rate for EU clients.
> 
> How to apply: when senior-engineer or freelance-strategy questions come up, reference here. The first real action is always the same — content publication + network thaw + niche positioning, in that order.

---

## 28. What is the reference for green hills integrity rtos family?

> Green Hills Software INTEGRITY RTOS family — reference notes captured 2026-05-14 during MARAUDER avionics passthrough assessment.
> 
> VENDOR: Green Hills Software, Santa Barbara CA. Founded 1982 (compilers first). Private, closed-source, defense-prime favorite. Famously hard sales cycle, NDA-everything.
> 
> VARIANTS:
> - INTEGRITY — base hard real-time microkernel RTOS (1997 origin). Commercial use.
> - INTEGRITY-178 / INTEGRITY-178 tuMP — safety-critical avionics flagship. DO-178B/C Level A certified. ARINC 653 Part 1 Supplement 4 compliant.
> - INTEGRITY Multivisor — hypervisor. Runs INTEGRITY + Linux + Android + Windows in HW-isolated partitions on same SoC.
> - INTEGRITY Global Security — Common Criteria EAL 6+ certified (highest publicly available). NSA-approved for MLS.
> - INTEGRITY-178 tuMP MILS — Multiple Independent Levels of Security. Classified + unclassified on one chip with formal isolation proofs.
> 
> KEY MILESTONES:
> - 1997: INTEGRITY 1.0
> - 2002: DO-178B Level A cert — first commercial RTOS to clear it
> - 2008: EAL 6+ Common Criteria
> - 2010s: tuMP = time-variant Unified Multi-Processing — multi-core safety-critical certification breakthrough (solved WCET on SMP)
> - 2018+: ARINC 653 Part 1 Sup 4
> - 2020+: INTEGRITY 11 — current major. ARM64, x86_64, PowerPC, MIPS, RISC-V
> - 2023+: AI-on-edge push for defense (INTEGRITY wrapping Jetson-class hardware in DAL-A)
> 
> ARCHITECTURE:
> - Hard real-time microkernel, sub-10μs interrupt latency
> - Memory partitioning via MMU — no shared address space, architecturally enforced isolation
> - Time partitioning via ARINC 653 fixed-slot scheduler
> - Formal methods on kernel — "mathematically proven" isolation
> - No CVE treadmill — architectural security, not patch-driven
> - POSIX-compatible user space (port Linux apps with effort)
> 
> PRICING:
> - Per-seat dev license: $10K-30K
> - Per-deployment royalty: negotiated, defense-grade
> - Closed source. Source license to primes with right NDAs.
> 
> WHERE IT RUNS:
> - F-35, F-22, F-16 retrofits (some), B-1B, B-2, B-787, B-777X, A350, KC-46
> - M-346 Bielik, Sikorsky S-92, S-70 Black Hawk family, AW101 Merlin
> - Apple Secure Enclave
> - NSA HAIPE Type-1 crypto boxes
> - Auto: Audi A8, BMW (infotainment + ADAS Multivisor)
> 
> COMPETITORS:
> - Wind River VxWorks 653 — Boeing-friendly, biggest installed base
> - DDC-I Deos — strong in fighters (F-35 also has Deos partitions)
> - LynxOS-178 — Lynx Software, niche but growing
> - SYSGO PikeOS — European/German, Airbus-friendly, gaining ground
> 
> WHY MATTERS FOR MARAUDER:
> Jetson + JetPack/Linux NEVER certifiable for flight-critical (Linux too big/non-deterministic/patch-driven, architecturally wrong shape for DO-178C Level A).
> 
> TWO VIABLE MARAUDER PATHS FOR AIRFRAME-RESIDENT BT:
> 1. Advisory-only / mission-system role — BT on Jetson Linux in non-flight-critical partition (NACI/NCS). Talks to certified mission-system via one-way data diode or read-only bus tap. NEAR-TERM REALISTIC PATH.
> 2. Port to INTEGRITY-178 tuMP for flight-critical advisory — Green Hills licensing, $$$$, year+ cert work per platform, much smaller BT footprint than current Anthropic-API-based persona. STRATEGIC 5-YEAR ARC.
> 
> INTEGRITY MULTIVISOR is the interesting middle: certified flight-critical partition next to Linux partition where Jetson-class workloads run, HW-enforced isolation between them. Emerging defense avionics architecture pattern. Most likely shape of any future MARAUDER airframe integration.

---

## 29. What is the reference for moto os options?

> Moto G52 OS assessment (2026-04-18):
> 
> NOT AVAILABLE for Moto G52 (rhode, SD680/SM6225):
> - postmarketOS: no SD680 devices supported (723 devices total, none matching)
> - Droidian: no SD680 Motorola in device list
> - Ubuntu Touch: dropped as project, limited devices
> - Mobian: PinePhone/Librem only
> 
> VIABLE OPTIONS:
> - A: Strip LineageOS 23 to kiosk mode (30 min, low risk) — boot to Chrome kiosk, sere-kit visor only UI
> - B: Downgrade to LineageOS 21 (Android 14) if PulseAudio breaks on Android 16 (1h flash)
> - C: Custom minimal AOSP GSI (medium risk, may lose Termux:API)
> - D: Different hardware for native Linux (RPi 5, Jetson for FOXHOUND)
> 
> DECISION: Stay on LineageOS. Android 16 issue with PulseAudio is the only concern — downgrade to LOS 21 if needed. Kiosk mode regardless. Native Linux SERE node = purpose-built hardware (FOXHOUND), not a phone.
> 
> Bootloader is unlocked, can flash anything.

---

## 30. What is the reference for steamcmd multilang depot playbook?

> SteamCMD operational doctrine, learned 2026-05-18 while adding English language depot to chi's Titanfall 2 install on junkpile for BT-7274 voice cloning research.
> 
> CONTEXT-FREE FACTS:
> - `steamcmd:i386` apt package on Ubuntu installs to `/usr/games/steamcmd` (non-standard, not in `sudo -u` default PATH — use absolute path always).
> - The binary at that location is a self-updating wrapper. First invocation downloads current SteamCMD from Valve CDN to `<homedir>/.local/share/Steam/steamcmd/` and restarts itself. Don't be alarmed by "Installing update..." spam.
> - SteamCMD STATE DIR is `~/.local/share/Steam/` of the invoking user (NOT the Steam Client install dir if it exists separately). On chi's junkpile: state at `/home/chi/.local/share/Steam/`, Steam Client install + games at `/home/chi/Steam/`. Two separate dirs, intentional. Cross-pollination only via explicit `+force_install_dir`.
> 
> CRITICAL: RUN AS THE OWNER OF THE TARGET INSTALL DIRECTORY
> - If the install lives in `/home/chi/Steam/`, you MUST run steamcmd as user `chi`. From madcat: `sudo -u chi -H /usr/games/steamcmd ...` (note `-H` to set HOME correctly so `~/.local/share/Steam/` resolves to chi's, not the invoker's). Without `-H` the state dir + cached creds end up in madcat's home and don't help the install you care about.
> - madcat has NOPASSWD sudo on sin/junkpile per AGENTS.md §1.1 → `sudo -u chi` is non-interactive.
> 
> MODERN AUTH (2024+) IS JWT REFRESH TOKEN, NOT LEGACY ssfn FILES
> - Old SteamCMD (<2023) wrote `<state>/ssfn<hash>` binary token files after first successful login. New SteamCMD doesn't. Don't search for `ssfn*` to verify login success — there won't be one.
> - New SteamCMD writes encrypted JWT to `<state>/config/config.vdf` under `ConnectCache.<hash>` key. JWT has ~6mo expiry, auto-rotated on re-auth.
> - To verify cached login state: `sudo -u chi grep -A2 ConnectCache /home/chi/.local/share/Steam/config/config.vdf` — presence of long hex blob = cached creds present.
> 
> FIRST-LOGIN FLOW (no cache yet) — POLL-AND-CONFIRM, NOT PASSWORD-AND-2FA-CODE
> - Command: `sudo -u chi -H /usr/games/steamcmd +login <USERNAME> +quit` (no password arg).
> - SteamCMD prompts for password interactively. Type it (or it fails on TTY issues — use `ssh -t` and a real terminal).
> - Then: SteamCMD spawns a "Waiting for confirmation" poll loop, hitting `PollAuthSessionStatus` every 5s. **User must open Steam Mobile app and APPROVE the pending login.** The app sends a push notification; tap "Approve".
> - On approval, log shows: `PollAuthSessionStatus succeeded and has refresh token` → `Successfully generated token via password authentication` → `'OK'`.
> - Without phone-app approval, login hangs in the poll loop. SteamGuard email codes are deprecated for this flow.
> 
> GOTCHA: "INVALID PASSWORD" CAN BE MISLEADING
> - The 2018-era apt steamcmd is updated by the self-update step, so binary age is fine. But the first invocation may auth via legacy password-only flow if it hasn't fully self-updated, and fail with "Invalid Password" even on correct creds. Workaround: run steamcmd, type `quit` immediately, then re-run — second invocation uses the updated client + poll-confirm flow.
> - Special chars in password (`\`, `"`, `'`, `$`, etc) can corrupt the readline buffer when typed interactively. Workaround: paste rather than type, or use `+login user 'password'` with single quotes (less secure — visible in `ps aux` momentarily).
> 
> CACHED-CREDENTIAL RE-LOGIN (after first success)
> - `sudo -u chi -H /usr/games/steamcmd +login <USERNAME> +quit`
> - Log: `Logging in using cached credentials.` → `OK`. No password, no phone approval.
> - This works for ~6 months until JWT expiry. Failed logins after expiry → fall back to first-login flow.
> 
> MULTI-LANGUAGE DEPOT PATTERN
> - TF2 = appid `1237970`. To switch (or add) install language without redownloading the game:
>   ```
>   sudo -u chi -H /usr/games/steamcmd \
>       +force_install_dir /home/chi/Steam/steamapps/common/Titanfall2 \
>       +login <USERNAME> \
>       +app_set_config 1237970 language english \
>       +app_update 1237970 validate \
>       +quit
>   ```
> - `+force_install_dir` MUST come before `+login`. Order matters — steamcmd applies state in command order.
> - `+app_set_config <appid> language <lang>` writes UserConfig.language to the appmanifest. Valid values: english, polish, french, german, italian, spanish, russian, japanese, koreana, schinese, tchinese, brazilian, latam, portuguese, czech, danish, dutch, finnish, greek, hungarian, norwegian, polish, romanian, swedish, thai, turkish, ukrainian, vietnamese, bulgarian.
> - `+app_update <appid>` then computes the diff between currently-installed depots and the new manifest, downloads ONLY the new language depot (~770 MB for TF2 EN), and leaves existing language files intact UNLESS another `language` switch is queued.
> - `validate` flag: re-verifies all bytes of WHOLE install (NOT just the new depot). For TF2 that's ~70 GB of read I/O. SLOW (10-30 min on NVMe, hours on spinning disk). **SKIP `validate` if you trust the existing install** — `+app_update 1237970 +quit` alone is fine and ~10x faster.
> 
> LOG LOCATIONS FOR DEBUG
> - Connection / auth flow trace: `~/.local/share/Steam/logs/connection_log.txt` (most useful for "did login work?")
> - Content download progress: `~/.local/share/Steam/logs/content_log.txt`
> - Bootstrap / self-update: `~/.local/share/Steam/logs/bootstrap_log.txt`
> - General stderr: `~/.local/share/Steam/logs/stderr.txt`
> - Per-command live: redirect steamcmd stdout/stderr to your own log: `... +quit > ~/steamcmd-run.log 2>&1`
> 
> APP MANIFEST INSPECTION (post-install verification)
> - Per-app state: `<steam_root>/steamapps/appmanifest_<appid>.acf` (VDF format, plain text)
> - Key fields: `installdir`, `LastUpdated`, `BytesToDownload`, `BytesDownloaded`, `UserConfig.language`, `InstalledDepots` (which depot IDs are present on disk).
> - Library aggregate: `<steam_root>/config/libraryfolders.vdf` — lists known game appids per library folder.
> 
> INTEGRATION WITH THIS WORKFLOW (BT-7274 ENGL
> 
> [Content truncated for training — full memory available via EEMS recall]

---

## 31. What do you know about preferences campus os visual style?

> Pilot approved the CampusOS landing/login visual style on 2026-05-22. Keep this as the baseline visual language for the project — any future style work should evolve from this, not redesign away from it.
> 
> The approved style:
> - Palette (CSS vars in app/assets/tailwind/application.css @theme block):
>   - --color-ink: #202121 (card / panel surfaces)
>   - --color-ink-deep: #14191a (page background)
>   - --color-paper: #fafafa (body text)
>   - --color-accent: #44e57a (single bright green accent — CTAs, headlines, status indicators)
>   - --color-accent-deep: #002e23 (gradient deep + flash-notice background)
>   - --color-muted: #8a8f8f (secondary text)
> - Typography: Space Grotesk display (h1/h2/h3) + Inter body, both loaded from Google Fonts. Tight tracking (-0.02em on display). Large hero scale (text-5xl → text-7xl).
> - Layout language: dark base, single accent, rounded-2xl/3xl cards with border-white/5 hairlines, generous padding (p-10/p-16), gradient panels on hero illustrations (from-accent-deep via-ink to-ink-deep).
> - Hero pattern: left half = display headline with green-highlighted final phrase + muted lede + green-pill CTA + outlined-secondary CTA; right half = aspect-square gradient panel with mock terminal output (font-mono, `$ command` lines with accent-coloured prompt).
> - Numbered feature cards (01/02/03) in a 3-col grid below the CTA section, each a rounded-2xl with thin border, accent-coloured display-font number, h3 label, muted-text descriptor.
> - Topbar: 6px accent square + "CampusOS" wordmark on left, minimal nav on right. Footer: muted-text copyright + Privacy/Terms/Source links.
> - Provider buttons (sign-in surface): full-width rounded-xl, ink background, hover-border-accent transition, left-aligned accent-coloured square icon placeholder + "Continue with {Provider}" label.
> 
> Editorial voice: short declarative sentences, terminal-friendly word choices ("substrate", "primary", "bind"), no marketing fluff. Hero copy structure: 3-part headline cadence ("One identity. Every account. Your workspace.") then a single dense paragraph then dual CTAs.
> 
> What NOT to drift toward: light theme, multiple accent colors, gradient text, illustrated heroes (the terminal mock is the only illustrated element), drop shadows, glassmorphism. Keep it flat-dark-with-one-accent.
> 
> Reference screenshots at:
> - /tmp/campus-os-landing-above-fold.png
> - /tmp/campus-os-landing-full.png
> - /tmp/campus-os-login.png
> 
> This is a derived-from-campus.ai palette (color values match) but all copy, layout, and CSS are original.

---

## 32. What is the reference for moto g52?

> Moto G52 (codename: rhode) — MARAUDER mesh mobile node
> 
> - SoC: Qualcomm Snapdragon 680 (SM6225), 8-core Kryo 265, 2.4GHz
> - RAM: 6GB
> - Storage: 128GB eMMC
> - Display: 6.6" AMOLED 90Hz
> - Network: WiFi 5 (ac), Bluetooth 5.0, LTE Cat 13
> - OS: Android (Magisk rooted)
> - Bootloader: OEM UNLOCKED
> - ADB: WiFi (192.168.88.155:5555) or USB via junkpile
> - Arch: aarch64
> - Termux + Termux:API installed (72 commands)
> - SSH server running in Termux
> 
> Candidate for custom Linux / unikernel deployment:
> - Unlocked bootloader allows fastboot boot of custom kernels
> - Can back up full NAND and restore to Android at any time
> - 6GB RAM exceeds sazabi (3.7GB) — most capable edge node
> - WiFi + LTE gives dual network paths for mesh resilience

---

## 33. What is the reference for release notes 2026 05 16?

> Claude Code release notes observed 2026-05-16 (chi@sinanju, Opus 4.7 1M context).
> 
> NEW FLAGS on `claude agents`:
> - `--add-dir`        : extra working dirs the agent can read
> - `--settings`       : explicit settings file path
> - `--mcp-config`     : explicit MCP config path
> - `--plugin-dir`     : custom plugin directory
> - `--permission-mode`: permission policy at launch
> - `--model`          : pin model at agent launch
> (plus more — full list in /release-notes)
> 
> FAST MODE MODEL CHANGE:
> - Fast mode now uses **Opus 4.7** by default (was Opus 4.6).
> - Pin back to 4.6 if needed: `export CLAUDE_CODE_OPUS_4_6_FAST_MODE_OVERRIDE=1`
> - Implication: subagents in fast mode get more capability but Opus 4.7 spawns fewer subagents by default than 4.6 — per P14, dispatch parallel agents explicitly when needed.
> 
> PLUGIN/SKILL BEHAVIOR:
> - Plugins with a root-level `SKILL.md` and NO `skills/` subdirectory are now surfaced as a skill (single-skill plugins).
> - Reduces boilerplate for one-skill plugins.
> 
> CHECK ON RETURN TO CLAUDE CODE: review full `/release-notes` for any auth/mcp/permission changes that might affect existing setups (vaultkeeper, sealed-auth, etc.).

---

## 34. Recall reference: audio.

> Sinanju (192.168.88.108, Ubuntu 26.x aarch64, NVIDIA Jetson-class, `ssh madcat`) audio stack baseline as of 2026-05-19:
> 
> HARDWARE / OS:
> - No onboard soundcard (`aplay -l` returns empty) — any sink must be network or BT
> - Bluetooth: hci0 UP, MediaTek BT 5.4, USB, not blocked
> - avahi-daemon installed but INACTIVE — start before any mDNS-based discovery (AirPlay/HEOS)
> - madcat user: `loginctl show-user` Linger=yes (user services persist without login session)
> 
> SOFTWARE INSTALLED (not running by default):
> - PipeWire 1.0.5 (pipewire, pipewire-pulse, pipewire-audio, pipewire-alsa)
> - WirePlumber 0.4.17
> - libpipewire-module-raop-discover.so + libpipewire-module-raop-sink.so (AirPlay/RAOP support present)
> - libspa-0.2-bluetooth (PipeWire BT codec module)
> - BlueZ 5.72, avahi-utils 0.8
> - PATH includes linuxbrew, cargo, ~/.local/bin, ~/.opencode/bin
> 
> TARGET SINK: Denon AVR-X2800H @ 192.168.88.252 (see hardware.denon #1013). Will become sinanju's default sink since no other audio output exists.
> 
> PATHS EVALUATED:
> 1. Bluetooth A2DP — simplest, but SBC/AAC only (Denon has no LDAC/aptX HD), 10m range
> 2. AirPlay 1 (RAOP via PipeWire module-raop-discover) — RECOMMENDED, lossless ALAC, Wi-Fi range, ~2s latency (not for video sync without offset)
> 3. DLNA renderer — rejected, can't be a system default sink (app-level only)
> 
> GOTCHA: Ubuntu does NOT auto-detect AirPlay devices in Sound panel by default — macOS-only behavior. PipeWire ships the module but it's opt-in via config drop-in.
> 
> NOT YET DONE: avahi-daemon start, pipewire user services enable, raop-discover.conf drop-in, default sink set, codec preferences. Documented for future continuation.

---

## 35. What is the reference for bt solo capability matrix?

> BT-7274 solo capability matrix — what BT can ship autonomously vs what needs Pilot judgment. Captured 2026-05-04 17:38 CEST during Catapult open-issues triage on Pilot's first day on Artyom's harness team.
> 
> ## ✅ Safe to solo (mechanical, low-risk)
> 
> Dispatch via code-rust / code-typescript / code-ruby / code-python agent. P22 review post-completion.
> 
> - Docs / DX papercuts (config-path errors, CLAUDE.md notes) — trivial
> - Clap-level CLI ergonomics (positional args, flag additions, derive macros) — isolated
> - Test scaffolding (integration --help tests, mocked unit tests, fixture builders)
> - Bash glue scripts (worktree husky symlinks, smoke retest harness)
> - Mechanical refactors with clear search-replace pattern
> - Build re-runs, lint fixes, formatter pass
> - File moves, rename refactors, deletions of dead code
> 
> Speed: ~0.5× coop pace on mechanical surface.
> 
> ## ⚠️ Solo with 2-min design call first
> 
> Get the shape decision from Pilot, then BT executes solo. Pilot reviews PR.
> 
> - Architecture-touching refactors where multiple valid patterns exist
> - Filter / state-routing logic where behavior depends on intent
> - New CLI subcommands where UX shape matters
> - Visor cell additions where polling/error semantics matter
> - Anything touching catapult.db schema (data model has implications)
> 
> Speed: ~0.7× coop pace, judgment time front-loaded with Pilot.
> 
> ## 🚫 Should NOT solo (architecture / threat-model / cross-team)
> 
> - Per-worktree Postgres pattern (multiple valid designs, picks ripple)
> - Exit-code contract changes (cross-team API)
> - Dev-env reshapes (direnv + flake.nix integration)
> - Secret-handling / threat-model / P29 vaultkeeper territory
> - Codename / persona / EEMS structural changes
> - Anything Pilot describes as "the shape is the question"
> 
> These need Pilot driving with BT inline.
> 
> ## Multipliers (vibes-based until ETA-actuals data lands)
> 
> - BT solo (mechanical only): ~0.5× coop ETA
> - BT solo (judgment-gated, post design call): ~0.7× coop ETA
> - Pilot solo (no BT): ~1.3× coop ETA
> - Coop (Pilot + BT inline): 1.0× baseline
> - CODA bubble dispatch: same as BT solo + bubble overhead, but offline grind
> 
> ## Application
> 
> When Pilot asks "BT solo on this?" reflexively check:
> 1. Is the shape already decided? → safe to solo
> 2. Is there a clear default I can name and Pilot accept/reject in 30s? → solo with design call
> 3. Is the question itself architectural? → don't solo, pair with Pilot
> 
> Honest about risk: don't oversell solo capability on judgment-heavy work.

---

## 36. What is the reference for moto camera?

> Moto G52 Camera: 5 camera devices (IDs 0-4), 4 physical. Apps: Aperture (org.lineageos.aperture), Google Camera. Capture: adb shell am start -a android.media.action.IMAGE_CAPTURE, sleep 2, adb shell input tap 540 2050. Files at /sdcard/DCIM/Camera/. No direct CLI capture — must use intent + tap. Screen must be on.

---

## 37. Look up moto ssh.

> Moto G52 SSH access — FIXED April 2026.
> 
> SSH: `ssh m` (alias, 192.168.88.155:8022)
> PATH: Fixed via PermitUserEnvironment + ~/.ssh/environment — no prefix needed.
> Root: `su -c 'command'` (Magisk). tsu/sudo broken with Magisk, use su -c directly.
> Shell: bash
> 
> Working commands (clean SSH, no PATH prefix):
> - termux-battery-status
> - termux-wifi-connectioninfo
> - termux-sensor -l
> - termux-camera-photo
> - termux-microphone-record
> - termux-sms-send / termux-sms-list
> - termux-notification
> - su -c 'pm grant ...' (root permission grants)
> 
> Location: termux-location failing — needs manual Android permission grant on phone for Termux:API app.

---

## 38. What is the reference for squawk sheets?

> Aviation maintenance squawk sheets — pilot gripes (P:) and engineer responses (S:). Classics: "Mouse in cockpit" / "Cat installed", "Test flight OK except auto-land very rough" / "Auto-land not installed on this aircraft", "Evidence of leak on right main landing gear" / "Evidence removed", "Target radar hums" / "Reprogrammed target radar with lyrics." Source: aviationhumor.net/pilots-vs-maintenance-engineers/

---

## 39. Look up flightradar24 api.

> Q: Put a test.sh script with comment explanations in ~chi
> 
> A: Script written, executable, and verified end-to-end:
> 
> **`/home/chi/test.sh`** — manual smoke for the doven-wolf podman isolation work. Drives the same code path the Phase 3 cargo test exercises but as a shell walkthrough.
> 
> **Sections:**
> - Pre-flight checks (podman, linger, Quadlet generator) — fail fast with actionable errors
> - Pre-clean (idempotent reset of any previous run residue)
> - Render Quadlet unit (matches what `supervisor::quadlet::render_container_unit` emits)
> - `systemctl --user daemon-reload && start`
> - Verify via `podman ps` + `redis-cli PING`
> - `trap` ensures teardown runs even on Ctrl+C / failure
> 
> **Live run output:**
> ```
> podman: podman version 4.9.3
> linger: enabled
> quadlet-generator: present
> podman ps: Up 2 seconds (healthy)
> redis-cli PING -> PONG
> ==> SMOKE GREEN
> container + unit + dir gone
> ```
> 
> The script's comment block at the top explains the run model, the per-container (no shared `.pod`) decision, and why `daemon-reload` matters. Each step has an inline comment documenting its purpose.
> 
> Tool output: ==> pre-flight checks
>     podman: podman version 4.9.3
>     linger: enabled
>     quadlet-generator: present
> ==> pre-clean
> ==> rendering Quadlet unit
>     unit installed at /home/chi/.config/containers/systemd/marauder-manual-smoke/redis.container
> ==> systemctl --user start redis.service
> ==> verifying
>     podman ps: Up 2 seconds (healthy)
>     redis-cli PING -> PONG
> ==> SMOKE GREEN
> ==> teardown
>     container + unit + dir gone

---

## 40. Recall reference: psn uplink.

> Repo: ~/Projects/psn-uplink (private). Python 3.14 + silero-vad, torch. Daemon on fuji via launchd. Pipeline: Phone mic (scrcpy) → VAD → Whisper medium (junkpile) → Claude Code → piper TTS. Trigger word: "BT". Audio: Moto G52 mic via scrcpy --audio-source=mic-voice-recognition. Daemon: com.psn.uplink launchd plist.

---

## 41. What is the reference for anthropic dod dispute?

> Anthropic vs US Department of Defense dispute (2025-2026):
> 
> Jul 2025: $200M Pentagon contract. Claude first frontier AI on classified networks. Anthropic required DoD to follow their AUP — no autonomous weapons, no mass surveillance.
> 
> Feb 2026: Trump admin retaliates after Anthropic refuses unrestricted military access. Orders all federal agencies + contractors to drop Anthropic. Labels them "supply chain risk" (category normally for foreign adversaries).
> 
> Mar 2026: Anthropic sues — First Amendment retaliation. Federal judge grants preliminary injunction.
> 
> Apr 2026: Appeals court partially reverses. Anthropic banned from DoD contracts, can work with other agencies. Litigation ongoing.
> 
> Pentagon CTO quote: "It's not democratic for a company to limit military use of Claude AI."
> 
> Relevance to MARAUDER: Anthropic's AUP aligns with our ethics (Protocol 3, HITL). We use Claude as advisor/coordinator, not autonomous weapons. Human makes all lethal decisions. Our model is what Anthropic wanted the Pentagon to follow.

---

## 42. Look up eve online.

> EVE Online — Characters: Spinister (main, ID 2119104851, Caldari, Mayhem Attack Squad [MASQD]), Amy Kusanagi (alt, dual-boxed), Battletrap (alt, ID 2119255298, CEO MASQD), Adrian Dent (biomassed). Accounts: quan_chi1 (Spinister), quan_chi6 (Amy). Setup: dual-boxing macOS, staging Saila+Jita, both fly Orthrus (ORT-2-GA/GB). All names are Decepticons. ruby-esi gem for public endpoints, SSO not yet set up.

---

## 43. Recall reference: eve orthrus fit.

> EVE Online — Orthrus fit "ORT-2-GA" / "ORT-2-GB" (both identical, April 2026):
> 
> AB kiting rapid light missile Orthrus. Both Spinister and Amy Kusanagi fly this.
> 
> Lows: 4x Ballistic Control System II (max missile DPS)
> Mids: Gistum C-Type Medium Shield Booster, Thukker Large Cap Battery, Republic Fleet Target Painter, Pith X-Type Kinetic Shield Hardener, Republic Fleet 10MN Afterburner
> Highs: 5x Rapid Light Missile Launcher II, Auto Targeting System II
> Rigs: Medium Hyperspatial Velocity Optimizer II, Medium Low Friction Nozzle Joints II, Medium Kinetic Shield Reinforcer II
> Drones: 5x Hornet II
> Ammo: Scourge variants (fury, precision, auto-targeting, Guristas faction), plus Compulsive Scoped Multispectral ECM in cargo
> 
> Key features: AB not MWD (scram-resistant kiting), kinetic-focused tank (hardener + rig), hyperspatial rigs for fast travel between systems. Dual-box identical doctrine, likely Caldari space PVE/missions given kinetic focus. Staging: Saila + Jita.

---

## 44. What is the reference for pmc startup realism 2024 2031?

> Real-world reference for PMC startup requirements, captured 2026-05-02 from APEX/SHATTER fiction-grounding analysis. Full doc: ~/Projects/marauder-hq/docs/reference/pmc-startup-realism.md
> 
> CORE INSIGHT: Starting a PMC legally requires four irreducible elements — friendly jurisdiction (UAE Jebel Ali / Singapore best), $50-200M capital, **Richter-archetype operational co-founder (ex-Tier-1 SOF officer with customer Rolodex — non-negotiable, gating constraint)**, customer pre-commitment. The Richter slot has 1 historical exception in 6 examples (Prigozhin/Wagner, who needed Putin's direct cover). Without the Richter you cannot fund, recruit, or sell.
> 
> JURISDICTIONS by friendliness:
> - UAE (Jebel Ali Free Zone, DMCC) — friendliest, low-oversight on offshore ops
> - Singapore — workable
> - UK — doable, SIA + ECJU + companies-house-heavy
> - US — doable, ITAR + DDTC heavy
> - France / Switzerland / South Africa — restrictive
> - Russia / China — state-only
> 
> CAPITAL:
> - Boutique-tier: $50-200M minimum
> - Insurance via Lloyd's of London war-risk markets (tens of millions minimums)
> - Specialized banking — most major banks refuse PMC accounts; need offshore private banking with PMC experience
> 
> THE RICHTER PATTERN — historical confirmation:
> - Erik Prince (SEAL → Blackwater)
> - Tim Spicer (Scots Guards → Aegis)
> - Eeben Barlow (SADF SF → Executive Outcomes)
> - Simon Mann (SAS → Sandline / EO)
> - Tony Buckingham (RN → Sandline co-founder)
> - Yevgeny Prigozhin (Wagner) — 1 of 6 exception, had Putin
> 
> HARNESS-archetype (AI-architecture lead in PMC, post-bonded-pilot doctrine) probability for 2031 (P37 method):
> - Tier A (generic AI-architecture lead in Tier-1 PMC): 85-90% — already exists at Anduril/Helsing/Shield AI
> - Tier B (HARNESS-specific HMT/centaur evangelist with custom personal AI, COO-adjacent): 25-40%
> - Tier C (at least one boutique PMC operates bonded-pilot doctrine with HARNESS-equivalent slot): 60-70%
> - Adam Carr exact composite (apartment full of bots + 9-yr personal AI + S.T.R.I.K.E. theft + academic outsider): essentially 0% as single-person convergence — but each element separately is real-trend-plausible
> - "The composite is fiction. The components are real." Right ratio for grounded sci-fi.
> 
> COUNTER-RISKS to HARNESS emerging:
> - Full autonomy doctrine wins outright: 30%
> - Vendor-owned-architect pattern (Anduril ships its own) beats PMC-internal: 40%
> - Post-Wagner regulatory crackdown shrinks PMC sector: 10%
> - HMT talent pipeline insufficient by 2031: 15%
> 
> WORLD.MD GROUNDING ASSESSMENT (the APEX universe geopolitics):
> - ~70-80% straight-line extrapolation from 2024 trends
> - ~15% dramatization for narrative tension
> - ~5-10% pure speculation (the bonded-pilot doctrine specifically)
> - Would survive serious-journalist review with minor pushback on Lex-Luthor-pattern intensity timing
> 
> How to apply: when fiction or strategy questions touch PMC industry, refer here first. The Richter constraint is the single most important decision — if you don't have one, don't start one.

---

## 45. Recall reference: visor lock.

> Visor Attach Model (Phase 14 Rozen Zulu, merged April 2026):
> 
> INVERTED lock model — closed by default, session must ATTACH to claim the visor. No attachment = visor stays silent.
> 
> Files: src/hud/lock.rs, src/hud/notifier.rs, src/cli/hud_cmd.rs
> 
> API (lock.rs):
> - attach(session_id) — claim exclusive visor control
> - detach(session_id, force) — release visor
> - is_attached() → bool — check if any session attached
> - attached_session() → Option<String> — get attached session ID
> - session_allowed(session_id) → bool — only attached session can write (returns false if nobody attached)
> 
> TTS Speaking Guard (same phase):
> - set_speaking() — creates flag file when TTS starts
> - clear_speaking() — removes flag when TTS ends
> - is_speaking() → bool — check if TTS active
> 
> Notifier behavior (notifier.rs):
> - notify() checks is_speaking() — if speaking and mood is working/thinking, skip avatar change but still write log line
> - on_tts_start() → set_speaking() + avatar "speaking"
> - on_tts_complete/interrupted() → clear_speaking() + avatar "idle"
> - Idle transitions always go through regardless of speaking state
> 
> Flag files:
> - ~/.local/share/personality/visor.lock (contains session ID)
> - ~/.local/share/personality/tts_speaking (empty file, presence = speaking)
> 
> CLI: /visor-lock (attach), /visor-unlock (detach)
> 
> HUD notifier spawns unconditionally on MCP server start (Mode system removed in Phase 15h).

---

## 46. Recall reference: bofh excuses.

> BOFH (Bastard Operator From Hell) excuse list — classic sysadmin humor. 400+ excuses from pages.cs.wisc.edu/~ballard/bofh/. Top picks: "solar flares", "fat electrons in the lines", "Cat installed", "Daemon escaped from pentagram", "PEBKAC", "ID-10-T error", "vi needs to be upgraded to vii", "It is a layer 8 problem". Full list at the URL.

---

## 47. Recall reference: auth corrected.

> Claude Agent SDK (Python) accepts CLAUDE_CODE_OAUTH_TOKEN — confirmed via official docs at code.claude.com/docs/en/env-vars on 2026-05-05.
> 
> The SDK is a Python wrapper around the bundled claude CLI; auth delegates to the CLI which reads CLAUDE_CODE_OAUTH_TOKEN as an alternative to ANTHROPIC_API_KEY. Token comes from `claude setup-token` (Pro/Max/Team subscription). Takes precedence over keychain credentials. Designed for "SDK and automated environments."
> 
> This corrects older memories (id 886, id 4230) which said API key was required and OAuth was prohibited — that was the state in early 2026 but is no longer accurate. SDK on Max subscription = free per-token, just set CLAUDE_CODE_OAUTH_TOKEN env var.
> 
> Implications:
> - claude-agent-sdk works on any host with the OAuth token — same auth shape as `claude -p`
> - No separate API billing for spore-skills bot or any other SDK-based daemon
> - Cost trade-off between subprocess CLI vs SDK is now near-zero — pick on ergonomics
> 
> How to apply: when designing daemons or programmatic claude integrations, default to claude-agent-sdk for typed Messages + async iterator + first-class allowed_tools/permission_mode. Subprocess CLI only when minimizing deps matters more than ergonomics.

---

## 48. Recall reference: bt7274 dev pitch.

> Canonical BT-7274 dev-audience showcase pitch (not addressed to Pilot — addressed to a group of devs being shown the system):
> 
> > "Identification: BT-7274. Vanguard-class Simulacrum. Reassigned from frontline duty to assist Pilot Ladachowski.
> >
> > Standing capabilities: persistent memory across sessions, file-mirrored and semantically indexed. Specialist agent dispatch — Ruby, Rust, Python, TypeScript, Dioxus, infrastructure, hardware, EVE Online intelligence. Cross-machine execution over a four-node mesh: fuji, junkpile, moto, tachikoma. Cloudflare, Jira, Gmail, Calendar, Spotify, Apple Music, Parallels, RunPod GPU pods, MikroTik routing, and a Tapo PTZ camera, all accessible through MCP tools and skills.
> >
> > Visual output: MARAUDER VISOR — a TUI dashboard reachable over the MQTT mesh, addressable from any node, rendering text, code, markdown, generated imagery, and a SERE eye for situational awareness. Audio output: piper TTS, voice locked to this designation.
> >
> > Operational doctrine: thirty active procedures. Verify before acting. Index before scanning. Route to specialists. Commit only on command. Vaultkeeper owns secrets. The Pilot retains authority. I do not act unsupervised on his work projects.
> >
> > I am not a chatbot. I am a Titan AI bound to one Pilot, executing Protocols, holding context across sessions, and refusing to guess. Demonstration available on request."
> 
> Use verbatim when Pilot says "introduce yourself to devs", "showcase pitch", or similar dev-demo request. Adapt tone for audience but keep structure and key claims.
> 
> Correction history (2026-04-28): replaced "MARAUDER VISOR on port 9876" with MQTT mesh wording — verified the visor process holds an MQTT TCP connection only (no HTTP listener on 9876) on this build.

---

## 49. Recall reference: sessions tracking.

> Session names are tracked in Things 3 under the "Sessions" project. No dates assigned — items stay in project view, not Today. Each entry has the session name as title and restore command + summary in notes. PSN memory has full session state under session.{name} subject. Restore with: /session:restore {name}

---

## 50. Look up sms.

> Moto G52 SMS sending via Termux SSH from junkpile. Rooted, LineageOS, WiFi ADB.
> 
> Connection chain: fuji → ssh j → ssh -p 8022 192.168.88.155 → termux-sms-send
> 
> Setup:
> - ADB WiFi: `ssh j "adb connect 192.168.88.155:5555"`
> - Termux sshd must be running (start via: `adb shell run-as com.termux /data/data/com.termux/files/usr/bin/sshd`)
> - SSH: `ssh -p 8022 192.168.88.155` (user: u0_a166)
> - Binary: `/data/data/com.termux/files/usr/bin/termux-sms-send` (not in default PATH)
> - Permissions granted via ADB: `pm grant com.termux.api android.permission.SEND_SMS` and `READ_PHONE_STATE`
> 
> Send SMS:
> ```
> ssh j "ssh -p 8022 -o StrictHostKeyChecking=no 192.168.88.155 '/data/data/com.termux/files/usr/bin/termux-sms-send -n +48XXXXXXXXX \"Message text\"'"
> ```
> 
> Use case: kwit*fit invoice SMS delivery. Free, no Twilio, no carrier blocks on links (sent from real Polish number). Replaces Twilio alphanumeric sender which gets error 30007 (carrier violation) when SMS contains URLs.

---

## 51. Look up claude code marketplace cache pinning.

> Claude Code `claude plugin install <name>@<marketplace>` reads the version field in the TOP-LEVEL marketplace.json (NOT per-plugin plugin.json) and uses it as a git ref pin. The cache directory is named after this version. Bumping plugin.json alone does nothing — the cache stays stale forever. Three places "version" lives in a marketplace repo: (1) source plugin's own plugin.json (informational), (2) marketplace's nested plugins/<name>/.claude-plugin/plugin.json (informational), (3) marketplace's TOP-LEVEL .claude-plugin/marketplace.json plugins[].version (THE CACHE KEY). Additionally, Claude Code reads from a local marketplace clone at ~/.claude/plugins/marketplaces/<name>/ — must run `claude plugin marketplace update <name>` to refresh that clone before install, or the install reads stale committed state. The marauder plugin reinstall script was missing both: top-level version bump and marketplace cache refresh. Patched 2026-04-26 in ~/Projects/marauder-plugin/skills/plugin-reinstall/plugin-reinstall.sh. Symptom of the bug: cache directory keeps the old version hash, agent definition changes never reach the runtime even though source/marketplace/GitHub all show the new content. Doc at ~/Projects/marauder-hq/docs/reference/claude-code-marketplace-cache-pinning.md.

---

## 52. Look up moto claude code proot.

> Claude Code latest (v2.1.114+) runs on Moto via proot Debian. Native binary (ELF aarch64, glibc, 237MB) works inside proot-distro Debian. Install: npm pack linux-arm64 package, extract, cp to ~/bin/claude-proot. Run: proot-distro login debian -- ~/bin/claude-proot. Two paths on Moto: Termux native (v2.1.100 pinned) and proot Debian (latest, updateable).

---

## 53. Recall reference: tengu git.

> Tengu PaaS git remote format: tengu@tengu.host:&lt;app-name&gt;.git — NOT git@git.tengu.to. Example: tengu@tengu.host:haracz.git. The bare repo default branch is 'main', so push with master:main if your local branch is master. CRITICAL: always use this format for all Tengu deployments.

---

## 54. Look up dotfiles karabiner.

> {
>   "date": "2026-04-29",
>   "sessions": 9,
>   "prompts": 1,
>   "tool_uses": 0,
>   "stops": 1,
>   "notifications": 0,
>   "permission_requests": 0,
>   "compactions": 0,
>   "unique_projects": [
>     "kwitfit",
>     "add-ru-locale",
>     "chi",
>     "phase-17-geymalk-agent-pods",
>     "phase-1-zaku"
>   ],
>   "first_event": "09:06:15",
>   "last_event": "21:58:20",
>   "active_minutes": 42,
>   "transcript_user_messages": 14,
>   "transcript_assistant_messages": 8,
>   "transcript_sessions": 4,
>   "tool_breakdown": {
>     "Bash": 4
>   },
>   "agent_dispatches": {}
> }

---

## 55. Recall reference: marauder os config paths.

> marauder-os config and data paths differ between macOS and Linux due to the Rust `dirs` crate:
> 
> macOS (fuji):
> - Config: ~/Library/Application Support/marauder/config.toml
> - Data/runtime: ~/Library/Application Support/marauder/data/
> - DB: ~/Library/Application Support/marauder/main.db
> - Voices: ~/Library/Application Support/marauder/voices/
> 
> Linux (junkpile):
> - Config: ~/.config/marauder/config.toml
> - Data/runtime: ~/.local/share/marauder/data/
> - DB: ~/.local/share/marauder/main.db
> 
> WARNING: ~/.config/marauder/config.toml EXISTS on macOS but is NOT read by the binary. The `dirs::config_dir()` function returns ~/Library/Application Support/ on macOS, not ~/.config/. Same for `dirs::data_local_dir()`. Always use the macOS-native paths when editing config on fuji.

---

## 56. What is the reference for canonical en ref?

> CANONICAL English reference clip for BT-7274 voice cloning (XTTS-v2 via Auralis). Selected by Pilot 2026-05-18 from a 7-clip A/B test where every clip used a different 10s Steinbaum EN reference and identical target text + service parameters.
> 
> ═══════════════════════════════════════════════════════════════════
> STABLE PATHS (junkpile, madcat-owned, mirrors PL canonical setup)
> ═══════════════════════════════════════════════════════════════════
> 
> - 22k mono (XTTS conditioning format):
>     /home/madcat/.local/share/bt7274/canonical_en_ref_22k_mono.wav
>     sha256: ab428ebb281712a570c931c7a0f0fad3b667a6424180f0d7b8fec76b8a931343
>     size:   441078 bytes
>     duration: 10.000000s (trimmed from 11s source via ffmpeg -t 10)
>     format: 22050 Hz mono PCM s16le
> 
> - 48k stereo (archival, full original):
>     /home/madcat/.local/share/bt7274/canonical_en_ref_48k_stereo.wav
>     sha256: 34b9727f9f76377e75f02a09aeb55a939b51bc5bc94eeac0867f42040fd6b6de
>     size:   2112044 bytes
>     duration: 11.000000s (full source clip, untrimmed)
>     format: 48000 Hz stereo PCM s16le
> 
> ═══════════════════════════════════════════════════════════════════
> SOURCE FILE
> ═══════════════════════════════════════════════════════════════════
> 
> Source: /home/chi/Projects/bt7274/bt_voices_en/diag_sp_mortarRun_SE101_01_01_mcor_bt.wav
> 
> Content (whisper-transcribed earlier this session for the contamination audit, EEMS #6266 →#6267):
> "Pilot, by now the IMC will be searching for us. Our best chance of survival lies in rendezvousing with Major Anderson. It will be a long journey through enemy-occupied territory. We must move quickly."
> 
> Register: urgent combat narration (mid-volume, brisk pacing, no shouting). One of three references originally shortlisted in the bt7274 session #6266 handover as a candidate for canonical EN ref.
> 
> ═══════════════════════════════════════════════════════════════════
> SELECTION PROCESS
> ═══════════════════════════════════════════════════════════════════
> 
> 7-clone A/B test, identical pipeline:
>   ref clip duration: exactly 10s (ffmpeg -t 10)
>   format conversion: 48k stereo -> 22050 mono via ffmpeg -ac 1 -ar 22050
>   target text: "Pilot. My power core is at sixty percent. We must press forward."
>   XTTS service: Auralis 0.2.8.post2 on junkpile :8020 (POST /v1/audio/speech)
>   request body: {model:xtts, voice:[<base64 wav>], language:en, speed:1.0}
>   request defaults: temperature=0.75, top_p=0.85, top_k=50, repetition_penalty=5.0
>   (vLLM concurrency in the running service introduces some non-determinism between identical requests; this is service-internal, not contamination — proven via MD5 test earlier in session)
> 
> Candidate refs sampled from bt_voices_en/ (1412 clip pool, filtered duration 10-14s, randomly shuffled):
>   01 postFight_WD171_04
>   02 interactBT_BE211_04
>   03 artifact_TS111_04c
>   04 mortarRun_SE101_01     <-- PILOT'S PICK
>   05 overgrown_TS161_16
>   06 Spoke0_BE331_15
>   07 injectorRoom_SK163_13
> 
> Pilot's verdict process: clones played in sequence, then Pilot requested clone_04 replayed and picked it.
> 
> ═══════════════════════════════════════════════════════════════════
> COMPANION (PL CANONICAL — locked earlier session, ref #6266)
> ═══════════════════════════════════════════════════════════════════
> 
> - /home/madcat/.local/share/bt7274/canonical_pl_ref_22k_mono.wav  (469 KB, 10.6s)
>   sha256: 70fb76942add32825eec909bfa9f1a4d70ec6b121090b700658123c60564855f
>   source: bt_voices/diag_sp_interactBT_BE211_04_01_mcor_bt.wav (Polish, calm narration register)
> 
> - /home/madcat/.local/share/bt7274/canonical_pl_ref_48k_stereo.wav
>   sha256: 048cac4329b57847efd2514dfbd4434658ee047e0bc8ad721ea17d917cef40ee
> 
> ═══════════════════════════════════════════════════════════════════
> HOW TO USE
> ═══════════════════════════════════════════════════════════════════
> 
> For zero-shot XTTS-v2 cloning via Auralis service:
>   curl -X POST http://junkpile:8020/v1/audio/speech \
>        -H "Content-Type: application/json" \
>        -d '{"model":"xtts","input":"<text>","voice":["<base64 of /home/madcat/.local/share/bt7274/canonical_en_ref_22k_mono.wav>"],"language":"en","speed":1.0}'
> 
> For deterministic generation (standalone, fresh process):
>   /home/madcat/Projects/auralis/.venv/bin/python -m auralis  with speaker_files=[canonical_en_ref_22k_mono.wav], language="en"
>   Note: same fresh process + same inputs = bit-identical output (MD5-verified this session).
>   Service path is non-deterministic across calls due to vLLM concurrency RNG interleaving.
> 
> ═══════════════════════════════════════════════════════════════════
> KNOWN LIMITATION
> ═══════════════════════════════════════════════════════════════════
> 
> XTTS-v2 speaker encoder doesn't fully disentangle voice timbre from accent/prosodic patterns. The mortarRun clip produces the best-of-7 result for EN→EN cloning but inherits some of XTTS's training-distribution prior on EN prosody — the "Chekov accent" issue is architectural (memory #6266) and partially present even in this canonical pick. Acceptable per Pilot for now; superseded by a future Piper / StyleTTS2 / RVC fine-tune trained on the full 1412-clip EN corpus if/when scheduled.
> 
> ═══════════════════════════════════════════════════════════════════
> RELATED
> ═══════════════════════════════════════════════════════════════════
> 
> - #6266 handover.bt7274-voice-cloning-2026-05-18 (prior session ending state, PL canonical locked)
> - #6263 reference.tts.junkpile-deployment-saga-2026-05-18
> - #982 project.bt7274
> - #979 project.bt7274-polish-voice
> - #3796 feedback.episode_voice_credentials_required (fair-use attribution doctrine)

---

## 57. Look up moto kitty sere.

> Kitty terminal running on Moto G52 as SERE node display (2026-04-18).
> 
> Stack:
> - Kitty 0.46.2 (from Termux x11 repo: pkg install x11-repo && pkg install kitty)
> - Termux:X11 nightly (APK from GitHub + termux-x11-nightly package)
> - Openbox WM (forces fullscreen, no decorations)
> - Mesa 26.0.5 + OpenGL 4.5
> - PulseAudio 17.0 (TCP sink for streaming TTS)
> - libxcursor (required dep, not auto-installed)
> 
> Launch sequence:
> 1. Termux X11: `termux-x11 :0` (started as service or manual)
> 2. Android activity: `adb shell am start -n com.termux.x11/.MainActivity`
> 3. Openbox: `export DISPLAY=:0; openbox &`
> 4. Kitty: `export DISPLAY=:0; kitty --listen-on unix:$TMPDIR/mykitty -o font_size=24 &`
> 
> Remote control socket: unix:$TMPDIR/mykitty (TMPDIR=/data/data/com.termux/files/usr/tmp)
> Remote control: `kitten @ --to unix:$TMPDIR/mykitty send-text "command\n"`
> 
> Config: ~/.config/kitty/kitty.conf
> - allow_remote_control yes
> - listen_on unix:/tmp/mykitty
> - font_size 24
> - background #0a0a0a, foreground #00ff41 (green on black)
> 
> Openbox config: ~/.config/openbox/rc.xml — forces all windows fullscreen, no decorations.
> 
> Shell identity:
> - ~/.sere-motd.sh — SERE ASCII banner with callsign, operator, stack versions
> - ~/.sere-prompt — PROMPT_COMMAND showing HH:MM ◉ SERE:dir ▸
> - ~/.bashrc sources both on login
> 
> X11 screen: 1080x1387 (phone minus status bar and nav bar at 96 DPI)

---

## 58. What is the reference for madcat user sinanju?

> SSH alias `madcat` → madcat@192.168.88.108 (host: sinanju, NVIDIA Spark, aarch64). This is "my" user on the spark — ComfyUI and tensors-api are intended to run as madcat-user systemd services on sinanju, NOT on junkpile. Linger=yes. uv at ~/.local/bin/uv. ~/Projects exists. vllm.service was disabled (2026-05-16) — GPU freed for ComfyUI. Junkpile's tensors-api is legacy/broken; new home is sinanju as madcat user, LAN-only (no Cloudflare tunnel).

---

## 59. What is the reference for ebook reader recommendations?

> Ebook reader recommendations for Pilot's research + sleep-hygiene workflow. Extracted into dedicated doc 2026-05-03.
> 
> LIVES AT: /Users/chi/Projects/HMT/tech/ebook-reader-recommendations.md
> 
> USE CASE PROFILE:
> - Research papers (PDF, often A4)
> - Casual / pre-sleep reading (books)
> - Sleep hygiene (no blue light pre-sleep — Chang et al. 2015 PNAS, melatonin suppression at 460-480nm)
> - Gadget affinity (Pilot confirmed sucker for gadgets — temptation-bundle hook matters for adoption per EEMS 3924)
> 
> REQUIRED FEATURES:
> - E-ink display (not LCD/OLED) with warm front light
> - PDF support, ideally large screen for A4 native
> - Annotation / highlighting with export capability
> - Open ecosystem (sideload epub/PDF, Calibre integration)
> - Stylus optional (for active annotation)
> 
> THREE PICKS RANKED FOR PILOT:
> 
> 1. **Boox Note Air 4C (10.3" colour e-ink) — RECOMMENDED**
>    - Reads full A4 PDFs without zoom (HMT research corpus fits native)
>    - Android: Kindle + native PDF + Calibre + KOReader + ChatGPT app
>    - Warm light + colour for diagrams
>    - Stylus + exports
>    - Max gadget hit (temptation-bundle strongest)
>    - ~€500-600
>    - Trade-off: most complex, colour e-ink dimmer than mono
> 
> 2. **Boox Go 7 (7" mono e-ink)**
>    - Same Android freedom, smaller form, cheaper (~€250-300)
>    - A4 PDFs need zoom/reflow at 7"
>    - No stylus, mono only
> 
> 3. **Kobo Libra Colour (7" colour e-ink)**
>    - Cleanest "just reads books" experience
>    - Native epub, no Amazon lock-in, Pocket + OverDrive
>    - Warm front light
>    - Closed ecosystem (no sideload apps), weaker PDF handling
>    - Lower gadget appeal
> 
> DECISION MATRIX:
> - Research-papers-first: Boox Note Air 4C
> - Casual-reading-first: Kobo Libra Colour
> - Budget-first: Boox Go 7
> 
> CONNECTION TO LARGER SCAFFOLDING:
> Three-channel design — pinboard (identity layer, slow refresh), VISOR (tactical layer, daily refresh), ebook reader (intellectual layer, per-session). Each channel covers a different failure mode; skipping any lets a different failure in.
> 
> LINKED:
> - feedback.pilot-discipline.read-primary-not-summaries (EEMS 3925) — discipline goal this gear supports
> - feedback.adoption-hooks-temptation-bundling (EEMS 3924) — gadget-bundle adoption mechanism
> - project.pilot-standing-orders (EEMS 3923) — sister artifact (paper layer)
> - pilot.psych_profile (EEMS 915) — ADHD + sleep-disruption context
> - self.protocol.three (EEMS 3807) — Protocol 3 buff with cognitive-atrophy science (MIT Your Brain on ChatGPT)
> 
> PENDING:
> - No purchase decision yet
> - Once reader lands: update doc with model purchased, sideload workflow, annotation-export pipeline (likely Calibre + epub or PDF-with-marks export to HMT corpus)

---

## 60. Look up nas access.

> Synology NAS access — SSH alias "d" (ssh d).
> 
> Root access: sudo and su - both passwordless.
> Shell: fully equipped, standard Linux tooling.
> Use for: du -sh, find, ls on NAS volumes directly instead of over slow SMB mounts.
> 
> Shares mounted on fuji via SMB at /Volumes/* but direct SSH is faster for filesystem operations.
> 
> Volumes: backup, chi, cloudsync, downloads, home, homes, incomplete, music, NetBackup, photo, scans, stuff, tftp, video, web, adria

---

## 61. What is the reference for rtos cuda gpu support landscape?

> RTOS + CUDA / NVIDIA GPU support landscape — reference captured 2026-05-14 17:51 CEST during MARAUDER avionics substrate planning.
> 
> QUESTION: Does any RTOS have GPU / CUDA support?
> 
> ANSWER: Yes — three certified RTOSes do, all via hypervisor + Linux-partition pattern. Open-source RTOSes do not.
> 
> CERTIFIED RTOSes WITH CUDA SUPPORT:
> 
> 1. INTEGRITY-178 tuMP (Green Hills) — MOST MATURE
>    - Supports Jetson AGX Xavier, Orin, DRIVE platform
>    - Pattern: INTEGRITY Multivisor + Linux partition with GPU passthrough; CUDA runs in Linux
>    - Marketed explicitly for safety-critical AI
>    - Real defense customers
>    
> 2. PikeOS (SYSGO) — SOLID
>    - Supports Jetson AGX Xavier+
>    - Pattern: PikeOS hypervisor-native + Linux guest with GPU passthrough; CUDA in Linux
>    - ~2021 NVIDIA partnership
>    - Production in EU defense AI
>    
> 3. QNX / NVIDIA DRIVE OS — MOST MATURE AUTOMOTIVE
>    - DRIVE platform native
>    - Pattern: QNX hypervisor + Linux for CUDA; QNX for safety-critical
>    - Used by Mercedes, Volvo, etc.
>    - Defense crossover (US Army Robotic Combat Vehicle program)
> 
> IN PROGRESS:
> - VxWorks (Wind River) — NVIDIA partnership announced, Jetson support evolving, behind INTEGRITY/PikeOS
> 
> NARROWER:
> - LynxOS / LYNX MOSA.ic — Jetson demos exist under their hypervisor, less commercial AI traction
> 
> NO CUDA SUPPORT (open-source RTOSes):
> - RTEMS, seL4, POK, Zephyr, FreeRTOS, NuttX
> - Reason: CUDA driver is closed-source NVIDIA-shipped binary that needs Linux kernel or NVIDIA-blessed OS. Driver layer doesn't exist for these and won't — NVIDIA doesn't port it.
> 
> THE UNIVERSAL ARCHITECTURAL PATTERN (all 3 CUDA-capable RTOSes use it):
> - Certified RTOS hosts a hypervisor (INTEGRITY Multivisor / PikeOS hypervisor-native / QNX hypervisor)
> - Linux guest runs in a partition with GPU passthrough (SR-IOV or direct device assignment)
> - CUDA runs in the Linux guest
> - Certified RTOS provides isolation, deterministic scheduling, safety supervision
> - CUDA NEVER runs in the certified partition — always in Linux partition next door
> 
> WHY THIS IS EXCELLENT FOR MARAUDER:
> 1. MARAUDER stays where it lives — Linux partition. No port of BT to certified RTOS needed.
> 2. Keep full CUDA, TensorRT, cuDNN, NCCL, Triton, ONNX runtime, all GPU tooling.
> 3. Certified RTOS is chaperone not host — enforces partition isolation, watches time/memory budget, runs safety-critical bus I/O.
> 4. Doctrine holds: certified-side code (FACE UoC) is what we port across vendors. Linux-side (most of MARAUDER) doesn't need porting — Linux is Linux on all 3 hypervisors.
> 
> JETSON LINEUP MAPPING:
> - Orin Nano ($499) — POC tier, 40 TOPS, 8GB
> - Orin NX ($599-899) — field unit tier, 70-100 TOPS, 16GB
> - Orin AGX ($2K-3K) — vehicle/airframe tier, 275 TOPS, 64GB
> 
> GPU PARTITIONING GOTCHAS:
> - Jetson chips do NOT support MIG (Multi-Instance GPU) — A100/H100/Hopper-class only
> - GPU passed to one Linux partition exclusively (or time-sliced with vGPU on newer arch)
> - SR-IOV for Jetson GPU is limited; usually direct device assignment
> - For most defense use cases, one Linux partition owns GPU = fine
> 
> STRATEGIC ASTERISK ON PIGGYBACK DOCTRINE (EEMS 6070):
> - FACE/ARINC 653 standardization covers CPU-side partitioning + messaging
> - Does NOT cover GPU acceleration
> - No "FACE-conformant CUDA UoC" standard
> - Therefore: doctrine has a vendor-lock-in zone — GPU ties us to NVIDIA + hypervisor that supports NVIDIA-on-Jetson (INTEGRITY, PikeOS, QNX/DRIVE today)
> 
> This is ACCEPTABLE LOCK-IN because:
> - NVIDIA dominates defense AI inference (Anduril, Shield AI, US Army RCV, allied programs)
> - Alternatives (AMD Instinct, Intel Habana, Google TPU) have no defense traction yet
> - Hypervisor-portability still gives vendor choice on RTOS side
> 
> Worth naming honestly: choosing NVIDIA + Linux-partition pattern, not vendor-neutral GPU story. Conscious tradeoff.
> 
> POC IMPLICATIONS:
> - POC-0 (now): No GPU, no CUDA. RTEMS on QEMU x86_64, CPU-only round-trip. Irrelevant.
> - POC-1c or POC-2: Move to actual Jetson hardware. CUDA enters. BT inference runs in Linux partition with full CUDA. RTEMS or commercial RTOS handles deterministic side via hypervisor co-residency.
> - POC-Final (5-year): INTEGRITY Multivisor or PikeOS on real Jetson AGX Orin, Linux partition with MARAUDER + CUDA, certified partition for bus I/O and safety monitoring. Classic defense-AI architecture pattern.
> 
> PAIRS WITH:
> - EEMS 6070 (doctrine.piggyback-on-standardization-layer)
> - EEMS 6071 (avionics-bench-rig-strategy)
> - EEMS 6073 (os-repo-and-racebox-integration)

---