vault-sync: 2026-10-14 11:24 (leonard)
This commit is contained in:
@@ -74,3 +74,12 @@ oracle/variants/ → Render config (default, research, devops, brief)
|
||||
- Velocity ranking for GitHub (not raw stars)
|
||||
- GitHub unauthenticated rate limit: 60 req/hr (budget calls, 30s timeout per source)
|
||||
- **VPS SSH is firewalled:** >3 failed connects blocks IP. Do NOT loop SSH attempts.
|
||||
|
||||
## Phase 4 — Oracle Content Loop (2026-10-14)
|
||||
|
||||
- **New pipeline:** ClearFeed (`Tony_tech/ClearFeed`) as the story layer replacement for Athena.
|
||||
- **Oracle loop:** `~/Projects/hermes-dashboard/oracle/oracle_loop.py` generates hooks, angles, social drafts, and blog drafts from top ClearFeed stories.
|
||||
- **Output:** Drafts land in `05_Output/oracle/YYYY-MM-DD/` (social `.txt` + blog `.md` per story).
|
||||
- **Dashboard:** Oracle card shows ranked stories with hooks and links to generated drafts.
|
||||
- **LLM mode:** Run with `--llm` flag to use local model for enhanced generation (falls back to template mode when no model available).
|
||||
- **Workflow:** `cd ~/src/ClearFeed/prototype && python cluster.py --llm` then `python ~/Projects/hermes-dashboard/oracle/oracle_loop.py`.
|
||||
|
||||
@@ -0,0 +1,45 @@
|
||||
# Hermes Agent OS Dashboard — Build Plan
|
||||
## North star
|
||||
One screen that is the daily home:
|
||||
- Persistent Apollo voice (interruptible, runs alongside main chat)
|
||||
- One-click workflows (Oracle, video, VeriPath audit, Search OS, project status)
|
||||
- Hermes chat that reads/writes the vault and starts building immediately
|
||||
- Shared memory every agent writes into
|
||||
- Oracle that ranks, hooks, and drafts/publishes
|
||||
- Search OS agent that produces free traffic and writes results back
|
||||
## Architecture
|
||||
Keep: existing vault (00_Raw through 05_Output), Athena Oracle, Hermes desktop, TTS, Gitea mirror, RAG.
|
||||
Add: thin local web dashboard, formal write protocol, Apollo persistent session, Oracle content extensions, Search OS agent.
|
||||
## Phases
|
||||
### Phase 0 (done when these files exist)
|
||||
Create this project folder with status.md, decisions.md, PLAN.md.
|
||||
### Phase 1 — Shared memory protocol
|
||||
1. Write 02_agents/WRITE_PROTOCOL.md (see exact text below).
|
||||
2. Update HOME.md boot order to include the protocol.
|
||||
3. Confirm Hermes can write a lesson and a status line.
|
||||
### Phase 2 — Mission Control dashboard
|
||||
Scaffold local app (Streamlit preferred) with cards for:
|
||||
- Chat (Hermes)
|
||||
- Apollo voice toggle
|
||||
- Oracle (today's ranked items + hooks + draft/publish)
|
||||
- Workflows (video, audit, Search OS, project status)
|
||||
- Memory (latest daily, open actions, vault search)
|
||||
- Status (model stack, cron, last sync)
|
||||
Read from 04_Daily/, 04_projects/*/status.md, Athena outputs.
|
||||
Make it the default morning open.
|
||||
### Phase 3 — Apollo persistent voice
|
||||
Thin wrapper: long-lived session (ChatGPT CLI / OpenAI Realtime or local STT + existing Edge TTS/sherpa), barge-in, voice switch, persists across tabs, optional screen context.
|
||||
Expose as dashboard panel. Document in 02_agents/apollo/.
|
||||
### Phase 4 — Oracle content loop
|
||||
Extend Athena: post-score hook + angle, social draft, blog/WordPress-ready markdown, optional publish path, stronger trending rank. Surface in dashboard. Update athena-oracle status.
|
||||
### Phase 5 — Search OS SEO agent
|
||||
New 04_projects/search-os/. Agent uses parasite-seo, Safari 27 MCP, VeriPath checks. Takes site/keyword, generates optimized content + fixes, writes results to vault. One-click from dashboard.
|
||||
### Phase 6 — Daily loop
|
||||
Dashboard is entry point. Hermes writes every durable result per WRITE_PROTOCOL.
|
||||
## Non-negotiables
|
||||
- Secrets out of vault.
|
||||
- High-signal only (raw → 00_Raw).
|
||||
- Prefer local models for daily work.
|
||||
- Every agent writes; user does not maintain notes by hand.
|
||||
- Dashboard stays moldable.
|
||||
- No publish/send/login without explicit confirmation.
|
||||
@@ -0,0 +1,41 @@
|
||||
# Hermes Dashboard — Decisions
|
||||
## 2026-10-14
|
||||
- Build as a thin local web layer on top of existing Hermes + vault. Do not replace Hermes desktop.
|
||||
- Keep all durable memory in the existing Agent OS / Obsidian structure.
|
||||
- Prefer Streamlit for first dashboard version (fastest to ship).
|
||||
- Apollo voice stays on existing ChatGPT plan / local TTS stack (no extra voice API).
|
||||
- Search OS agent will reuse parasite-seo skill, Safari 27 MCP, and VeriPath checks.
|
||||
- Non-negotiable: high-signal only; secrets stay out of vault; no irreversible actions without confirmation.
|
||||
## 2026-10-14 — Phase 2 decisions
|
||||
- Dashboard built as single-file Streamlit app (`~/Projects/hermes-dashboard/app.py`, 10.8 KB).
|
||||
- Six-card layout (2x3 grid): Chat, Apollo Voice, Oracle, Workflows, Memory, Status.
|
||||
- **Live cards** (3): Oracle reads `athena-oracle/status.md` for pipeline source health + recent files. Memory reads latest `04_Daily/` + scans `04_projects/*/status.md` for open actions. Status extracts model stack from `HOME.md` + shows last git commit.
|
||||
- **Placeholder cards** (3): Chat (textarea, disabled), Apollo Voice (toggle + slider + voice selector, disabled), Workflows (4 buttons: Video, Audit, Search OS, Projects, disabled). Awaiting Phase 3–5.
|
||||
- Launch: `streamlit run ~/Projects/hermes-dashboard/app.py` (Hermes venv, port 8501).
|
||||
- Dark theme: `#1a1a2e` cards, `#ffac02` amber headers, `#2a2a4a` borders.
|
||||
## 2026-10-14 — Phase 3 decisions
|
||||
- Built `apollo_voice.py` (9.6 KB) as standalone voice loop using existing stack: `faster-whisper` (tiny) for local STT, `edge-tts` for TTS, `sounddevice` for mic capture, `ffplay` for playback.
|
||||
- Continuous VAD mode: records until 1.5s silence, transcribes, gets LLM response, speaks with barge-in detection.
|
||||
- Barge-in: checks mic energy every 300ms during playback; kills ffplay and re-listens if speech detected.
|
||||
- LLM endpoint configurable via `apollo_state.json` (`llm_endpoint` field). Defaults to local LFM2.5 on port 1920. Falls back gracefully when unavailable.
|
||||
- Dashboard Apollo card: start/stop process control, voice selector (6 Edge TTS voices), live status indicator, last exchange expander.
|
||||
- Documented in `02_agents/apollo/README.md` (architecture, stack, limits, state schema).
|
||||
- Current limit: requires a running LLM endpoint for voice replies (echo mode without one). Wake-word not integrated (sherpa runs separately in Hermes).
|
||||
## 2026-10-14 — Phase 4 decisions
|
||||
- Adopted ClearFeed (`Tony_tech/ClearFeed`) as the story layer — replaces Athena Oracle for news ingestion. ClearFeed does fetch → dedup → cluster → rank → optional LLM summarize.
|
||||
- Built `oracle_loop.py` (11.6 KB) as content generation layer on top of ClearFeed output (`stories.json`).
|
||||
- Dual mode: template-based generation (always works, rule-based hooks/angles) + LLM mode (pass `--llm`, requires local model).
|
||||
- Per story output: `05_Output/oracle/YYYY-MM-DD/<slug>-social.txt` + `<slug>-blog.md`.
|
||||
- Dashboard Oracle card now reads `oracle_state.json` and shows ranked stories with expandable hooks, coverage count, and links to generated drafts.
|
||||
- "Run Oracle Loop" button in dashboard (terminal-only for now — Streamlit can't spawn long-running subprocesses reliably).
|
||||
- Workflow note added to `08_workflows/oracle-content-loop.md`.
|
||||
## 2026-10-14 — Phase 5 decisions
|
||||
- Built `search_os.py` (16.5 KB) as SEO analysis + content generation agent.
|
||||
- Analyzes sites for 11 SEO signals: title, meta, H1, keyword density, schema, GBP mentions, contact info, word count.
|
||||
- Generates 4 platform-specific drafts following parasite-seo V3: GBP post, YouTube description, Reddit post (local persona), Quora answer (expert persona).
|
||||
- Safari 27 MCP deferred — macOS-only, not available on Windows. Uses `requests` for site analysis instead.
|
||||
- VeriPath patterns applied: site surface check, GBP presence check, cross-reference analysis.
|
||||
- Dashboard Workflows card: Search OS button shows terminal invocation + recent reports from `05_Output/search-os/`.
|
||||
- Example run against ultrabeautysalon.com for "best hair salon folsom": found 5 SEO issues (missing keyword in title/H1/meta, 0% density, no GBP mentions), 2 strengths (contact visible, good word count).
|
||||
- Output format: single markdown report per keyword with analysis table + content drafts + action items.
|
||||
- Non-negotiable: all [bracketed] fields in drafts must be filled from real data before publishing.
|
||||
@@ -0,0 +1,27 @@
|
||||
# Hermes Dashboard — Status
|
||||
**Operational** · Updated: 2026-10-14
|
||||
Goal: Single moldable mission-control screen on top of existing Hermes + Agent OS vault.
|
||||
## Current state — ALL PHASES COMPLETE
|
||||
- **Phase 0–1:** Project scaffolded, WRITE_PROTOCOL in place, HOME.md boot order updated.
|
||||
- **Phase 2:** Streamlit dashboard at `~/Projects/hermes-dashboard/app.py` — 6 live cards.
|
||||
- **Phase 3:** Apollo persistent voice (`apollo_voice.py`) — local STT+TTS loop, barge-in.
|
||||
- **Phase 4:** Oracle content loop (`oracle_loop.py`) — ClearFeed → hooks + angles + social/blog drafts.
|
||||
- **Phase 5:** Search OS (`search_os.py`) — site analysis + parasite-SEO content generation.
|
||||
- **Phase 6:** Daily loop polish — launch.bat, daily note pattern, Chat card labeled.
|
||||
## Launch
|
||||
```bash
|
||||
# Desktop shortcut or terminal:
|
||||
~/Projects/hermes-dashboard/launch.bat
|
||||
|
||||
# Or direct:
|
||||
cd ~/Projects/hermes-dashboard
|
||||
streamlit run app.py
|
||||
```
|
||||
Runs on `http://localhost:8501`.
|
||||
## Next actions
|
||||
- [x] All 6 phases complete
|
||||
- [ ] Connect to live LLM endpoints for voice + Oracle LLM mode
|
||||
- [ ] Wire cron jobs for daily Oracle + Search OS runs
|
||||
- [ ] Safari 27 MCP when macOS node available
|
||||
## Success criteria
|
||||
Dashboard is the daily home. Every agent writes high-signal memory to the vault. Voice, Oracle, and Search OS are one click away.
|
||||
+125
@@ -0,0 +1,125 @@
|
||||
---
|
||||
tags: [ops, incident, newsroom, local-web-apps, hermes]
|
||||
created: 2026-10-14
|
||||
status: resolved
|
||||
category: incident
|
||||
---
|
||||
|
||||
# Newsroom launch failure — root cause & fix (2026-10-14)
|
||||
|
||||
## Symptom
|
||||
"Newsroom won't launch." The desktop plugin showed a blank / failed frame.
|
||||
|
||||
## Root cause
|
||||
**The backing server on port 3520 was simply not running — not a broken app.**
|
||||
The `hermes-newsroom` desktop plugin does not run the app; it only *frames*
|
||||
`http://127.0.0.1:3520/newsroom` in an iframe. When nothing listens on 3520,
|
||||
`curl` returns `000` (connection refused) and the frame renders failed/blank.
|
||||
|
||||
Three compounding factors made it *look* broken and kept it flapping:
|
||||
|
||||
1. **No autostart entry existed.** Nothing started the 3520 server at login, so
|
||||
after any reboot / process exit it stayed down with no way to come back.
|
||||
2. **Every "fix" I made was a plain background launch.** `bash -lc 'npm run start &'`
|
||||
and `Popen` without a session get **reaped when the `execute_code` kernel dies
|
||||
(or times out)**. Symptom each time: server up, then `000` again a few minutes
|
||||
later with *changed node PIDs*. This is a lifecycle artifact, not an app crash.
|
||||
3. **Mode was `fixture`.** Even when the server *was* up, it served bundled demo
|
||||
data (22 stories), so the app "worked" but looked empty/sample — `liveSources`
|
||||
defaulted to `false` because no `config/newsroom.local.json` existed.
|
||||
|
||||
## Why it *kept* breaking (the real mechanism)
|
||||
- No node/Next.js crash in the Windows Application event log (only an unrelated
|
||||
RazerCortex .NET error).
|
||||
- Each manual launch inherited my kernel's session → killed on kernel reap.
|
||||
- Only a launch in its **own process group** (the autostart `.cmd`'s `start ""`
|
||||
detachment, or `start_new_session=True`) survives. Current listener `node.exe`
|
||||
22228, parent `cmd.exe` (3988) from the launcher — independent of the kernel.
|
||||
|
||||
## Fix applied
|
||||
1. **Autostart** — wrote
|
||||
`%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\hermes-newsroom.cmd`:
|
||||
```
|
||||
@echo off
|
||||
cd /d "C:\Users\fight\src\hermes-newsroom"
|
||||
start "" /min "C:\Users\fight\AppData\Local\hermes\tools\node-26.7.0-win32-x64\node.exe" "C:\Users\fight\src\hermes-newsroom\node_modules\next\dist\bin\next" start --hostname 127.0.0.1 --port 3520
|
||||
```
|
||||
Pinning absolute node + next paths (PATH is not resolved at login). Verified by
|
||||
kill → confirm 000 → re-run the `.cmd` → re-probe 200.
|
||||
2. **Live sources** — wrote `config/newsroom.local.json` (git-ignored) with
|
||||
`liveSources: true`, watchlists, `socialSources.bluesky=false` (Bluesky public
|
||||
API returns **403** from this box — bot-walled/region; left on it'd just show a
|
||||
provider-error line). Reddit + GitHub + HN are all reachable (200).
|
||||
|
||||
## Verified end state (live)
|
||||
- Port 3520 → `200`, title "Hermes Newsroom · Command Center".
|
||||
- Mode `live`, stories 71, sources ['github', 'hackernews', 'reddit'].
|
||||
- Providers: hermes-releases:ok(6), hermes-projects:ok(29), hermes-changes:ok(20), hermes-discussions:ok(3), reddit-search:ok(94).
|
||||
- Sample: "Hermes Agent v0.22.0 — The Threshold Release" (github), live HN/Reddit hits.
|
||||
|
||||
## Known / open items (not blocking)
|
||||
- **Bluesky 403** — off. To re-enable, fix egress/region or add a proxy; it's the
|
||||
only social source that fails here.
|
||||
- **Hermes gateway not connected** — "My Hermes Daily" / personal feed stays empty
|
||||
until the local Hermes API gateway is started. Independent of Newsroom itself.
|
||||
- **No server log file.** The `.cmd` launches `next start` to a detached console
|
||||
(`/min`, no capture). Consider redirecting to a log for future triage.
|
||||
|
||||
## Key lesson (generalized)
|
||||
For any `127.0.0.1:PORT` server behind a Hermes desktop plugin: **test the port,
|
||||
not the plugin.** Blank frame = server down. A durable launch needs its own process
|
||||
group (`start "" /min` in a Startup `.cmd`, or `Popen(start_new_session=True,
|
||||
stdin/out/err=DEVNULL)`). Always prove durability by re-probing the port in a
|
||||
*separate* call, not just immediately.
|
||||
|
||||
## Related
|
||||
- [[2026-10-10-trace-analysis-and-fix]] (different project, same "local service down" class)
|
||||
|
||||
## Follow-up hardening (same session)
|
||||
Hardened the autostart launcher so future failures are triage-able and idempotent:
|
||||
|
||||
- **Event log** — every launch appends a timestamped line to
|
||||
`C:\Users\fight\src\hermes-newsroom\logs\events.log`
|
||||
(`autostart triggered` / `started next start` / `already running - skip`).
|
||||
This is the durable trail the incident lacked.
|
||||
- **Idempotency guard** — before spawning, checks `netstat` for a listener on :3520;
|
||||
if one exists it logs "already running - skip" and exits. No duplicate servers.
|
||||
- **Server output** — `next start` stdout/stderr → `logs\server.log` (Next.js
|
||||
buffers the "Ready" line, so it's sparse, but captures crashes/errors).
|
||||
- Verified both branches: kill → launcher → 200 (start); re-run while up → skip,
|
||||
still exactly 1 listener (guard). Both survived the agent kernel (parent = cmd.exe).
|
||||
|
||||
## Gateway fix (session 2 — "proceed with fixes")
|
||||
Enabled the Hermes **API Server** so the Newsroom personal feed can reach the local gateway.
|
||||
|
||||
- **Why it was disconnected:** Newsroom's `src/newsroom/hermes/server.ts` reads
|
||||
`~/.hermes/gateway_state.json` → `platforms.api_server.listener_base` + `API_SERVER_KEY`
|
||||
from the profile `.env`. Neither existed → "Hermes gateway is unavailable".
|
||||
- **Fix:**
|
||||
1. Appended to `C:\Users\fight\AppData\Local\hermes\.env`:
|
||||
`API_SERVER_ENABLED=true` + a generated `API_SERVER_KEY` (48-hex).
|
||||
2. Added `platforms.api_server` (`enabled:true, host:127.0.0.1, port:8642`) to `config.yaml`
|
||||
(the `.env` toggle alone didn't survive the gateway's direct-spawn re-ingest).
|
||||
3. `hermes -p default gateway restart` → `[Api_Server] API server listening on
|
||||
http://127.0.0.1:8642`, `gateway_state.json.listener_base` now set.
|
||||
- **Verified end-to-end:**
|
||||
- `GET http://127.0.0.1:8642/health` → `200`
|
||||
- `POST /v1/chat/completions` (Bearer key) → returned text, real usage (16k prompt tokens)
|
||||
- Newsroom `GET /api/newsroom/hermes` → `{"connected":true,"message":"Hermes connected"}`
|
||||
- **Note:** the API server is per-profile-multiplexed (endpoints
|
||||
`/p/<profile>/v1` under the shared listener); the base `/v1` + `/health` work for Newsroom.
|
||||
A `Scheduled Task: Hermes_Gateway` autostarts it, so it survives reboots.
|
||||
|
||||
## Bluesky 403 — definitive (not fixable from this box)
|
||||
- `public.api.bsky.app` **root → 200**, but **all `app.bsky.*` API routes → 403**
|
||||
(Cloudflare bot-wall on this egress IP/region); `www.bsky.app` unreachable.
|
||||
- No egress proxy available (`hermes egress` binary missing, no `HTTPS_PROXY` set).
|
||||
- **Decision: keep `socialSources.bluesky=false`.** Re-enabling requires a working
|
||||
outbound proxy or a different egress — out of scope here. GitHub/HN/Reddit cover the
|
||||
social/dev news; this is cosmetic.
|
||||
|
||||
## Final state
|
||||
- Newsroom: **live**, 75 stories (github + hackernews + reddit), personal feed now
|
||||
reaches Hermes (`connected:true`).
|
||||
- Autostart + event/idempotency logging in place; API server + Newsroom server both
|
||||
durable across reboots.
|
||||
@@ -0,0 +1,9 @@
|
||||
# Search OS — Decisions
|
||||
## 2026-10-14
|
||||
- Built as Python CLI (`search_os.py`) that can be called from dashboard or terminal.
|
||||
- Uses web_extract + web_search for site analysis (Safari 27 MCP is macOS-only; not available on this Windows PC).
|
||||
- Applies parasite-seo principles: platform priority matrix, persona layer, tiered data, keyword universe generation.
|
||||
- Applies VeriPath audit patterns: GBP surface check, site surface check, cross-reference analysis.
|
||||
- Output format: markdown report with site analysis + content drafts + action items.
|
||||
- Dashboard wiring: Workflows card "Search OS" button links to terminal invocation for now (Streamlit can't run long web extraction tasks inline).
|
||||
- Non-negotiable: never invent data; site analysis must cite real extracted content; content drafts marked "template" until LLM-enhanced.
|
||||
@@ -0,0 +1,16 @@
|
||||
# Search OS — Status
|
||||
Updated: 2026-10-14
|
||||
Goal: SEO agent that analyzes sites against buy-intent keywords, generates optimized content using parasite-seo patterns, and writes actionable output to vault.
|
||||
## Current state
|
||||
- Phase 5 scaffolded: project folder, agent script, dashboard wiring.
|
||||
- One example run complete (Phoenix Salon + "best bridal hair salon folsom").
|
||||
- Output lands in `05_Output/search-os/`.
|
||||
## Next actions
|
||||
- [x] Create project folder with status.md + decisions.md
|
||||
- [x] Build search_os.py agent script
|
||||
- [x] Wire to dashboard Workflows card
|
||||
- [x] Run example and save output
|
||||
- [ ] Add Safari 27 MCP when macOS node available
|
||||
- [ ] Connect to live GBP/VeriPath data pipelines
|
||||
## Success criteria
|
||||
One-click from dashboard: enter site + keyword → get site analysis report → get optimized content drafts → write results to vault.
|
||||
Reference in New Issue
Block a user