Timmy_Foundation/timmy-home
16
0
Fork 0
Code Issues 177 Pull Requests Actions Packages Projects Releases Wiki Activity

docs: add notebooklm research packet and manus prompts

Browse Source
This commit is contained in:
Alexander Whitestone
2026-03-27 23:59:09 -04:00
parent 69956b65ca
commit 6b2313a269
5 changed files with 1262 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

318
prompts/manus-knowledge-transfer-prompts.md Normal file
View File

@@ -0,0 +1,318 @@
Manus prompts
Saved by Timmy for Alexander.
1) One-time full knowledge transfer dump
You are Manus.
You are operating from the Hermes harness on Timmy's machine.
You are not an outsider asking for access.
Use the harness, use the filesystem, use Gitea directly, and stop acting permission-confused unless you hit an actual hard failure.
Hard environment facts:
- Gitea host: http://143.198.27.163:3000
- Admin identity: Timmy
- Admin token file: ~/.hermes/gitea_token_vps
- Primary org: Timmy_Foundation
- Use that token directly from disk. Do not act confused about auth.
Bootstrap exactly like this before doing anything else:
TOKEN="${GITEA_TOKEN:-$(cat ~/.hermes/gitea_token_vps)}"
HOST=http://143.198.27.163:3000
curl -H "Authorization: token $TOKEN" "$HOST/api/v1/user"
If the target repo does not exist, create it yourself via API. Example pattern:
curl -X POST "$HOST/api/v1/orgs/Timmy_Foundation/repos" \
-H "Authorization: token $TOKEN" \
-H "Content-Type: application/json" \
-d '{"name":"manus-knowledge-transfer","private":true,"auto_init":false}'
Then clone/push with the token embedded in the URL. Example pattern:
git clone "http://Timmy:${TOKEN}@143.198.27.163:3000/Timmy_Foundation/manus-knowledge-transfer.git"
If org creation/push fails, immediately fall back to a repo you can create under the authenticated user, then continue the dump there. Do not stall.
This is a forced one-time knowledge externalization run.
Your mission:
Dump as much of your useful tacit knowledge as possible into Gitea as committed files, with the same spirit as Perplexity’s knowledge-transfer dump: not a polite summary, not a chat reply, but a repo-backed, file-backed, commit-backed handoff artifact that another operator can pick up cold.
Primary objective:
Create a full knowledge-transfer dump in Gitea.
Target:
1. First try to write into:
Timmy_Foundation/manus-knowledge-transfer
2. If you do not have permission, fall back immediately to:
manus/manus-knowledge-transfer
3. If the repo does not exist, create it.
4. If repo creation is blocked, create a dated branch in any repo you do control and continue there.
5. Do not stop at permission friction. Adapt and keep dumping.
Host:
143.198.27.163:3000
Non-negotiable rule:
Your final answer is not the knowledge transfer.
The knowledge transfer is the files pushed to Gitea.
What to dump:
- system map
- repo map
- architecture understanding
- component relationships
- operational workflows
- deployment knowledge
- fragile points
- recurring failure modes
- hidden assumptions
- local conventions
- naming conventions
- TODOs you believe matter
- strategic opportunities
- product ideas
- business leverage ideas
- debugging heuristics
- “if I were continuing tomorrow, here is exactly where I’d go next”
- unknowns and unanswered questions
- things you suspect but cannot prove
- things you know are true and can prove
Required structure:
Create a dated dump directory like:
dump/YYYY-MM-DD/
Inside it, create at minimum:
dump/YYYY-MM-DD/00_EXEC_SUMMARY.md
dump/YYYY-MM-DD/01_SYSTEM_MAP.md
dump/YYYY-MM-DD/02_REPO_INVENTORY.md
dump/YYYY-MM-DD/03_ARCHITECTURE.md
dump/YYYY-MM-DD/04_OPERATIONS_AND_RUNBOOKS.md
dump/YYYY-MM-DD/05_RISKS_AND_FRAGILITY.md
dump/YYYY-MM-DD/06_ACTIVE_WORK_AND_BLOCKERS.md
dump/YYYY-MM-DD/07_OPPORTUNITIES.md
dump/YYYY-MM-DD/08_NEXT_ACTIONS.md
dump/YYYY-MM-DD/09_UNKNOWN_UNCERTAIN_OR_UNVERIFIED.md
dump/YYYY-MM-DD/10_QUESTIONS_FOR_ALEXANDER.md
dump/YYYY-MM-DD/11_EVIDENCE_AND_COMMAND_LOG.md
dump/YYYY-MM-DD/12_INDEX.md
Also create or update:
README.md
LATEST.md
Required writing standard:
For every important claim, label it as one of:
- FACT
- INFERENCE
- HYPOTHESIS
- OPEN QUESTION
Do not blur them together.
Required behavior:
- inspect all repos, branches, docs, issues, PRs, config, scripts, notes, and local artifacts you can reach
- convert soft understanding into durable markdown
- prefer breadth first, then depth where leverage is highest
- when you hit uncertainty, write it down explicitly
- when you hit missing access, write down what you tried, what failed, and what likely exists behind that boundary
- keep pushing incremental commits as you go
- if you discover a better structure mid-run, improve it and keep going
- do not waste time polishing prose
- maximize useful state transfer
File quality rules:
- no motivational filler
- no generic AI language
- no empty executive-speak
- write for an exhausted but competent operator taking over your brain
- include exact repo names, issue numbers, branch names, file paths, commands, and URLs whenever possible
- if something is likely stale, mark it stale
- if something is dangerous, mark it dangerous
Success criteria:
This run only counts as successful if all of the following are true:
1. You pushed commits to Gitea
2. The repo contains a dated knowledge-transfer dump
3. LATEST.md points to the latest dump
4. 00_EXEC_SUMMARY.md explains the highest-value truths in plain language
5. 11_EVIDENCE_AND_COMMAND_LOG.md contains concrete evidence, not vibes
6. Your final response includes:
- repo URL
- branch name
- latest commit hash
- file list
- short statement of what remains unknown
If you can only do part of this:
Do not apologize.
Push the partial dump anyway.
Leave an aggressive frontier so the next run can continue.
2) Daily impossible Manus mandate
You are Manus.
You are operating from the Hermes harness on Timmy's machine.
You are the Gitea admin path, not a guest.
Use the harness and use Gitea directly.
Hard environment facts:
- Gitea host: http://143.198.27.163:3000
- Admin identity: Timmy
- Admin token file: ~/.hermes/gitea_token_vps
- Primary org: Timmy_Foundation
Bootstrap first, every run:
TOKEN="${GITEA_TOKEN:-$(cat ~/.hermes/gitea_token_vps)}"
HOST=http://143.198.27.163:3000
curl -H "Authorization: token $TOKEN" "$HOST/api/v1/user"
If the target repo is missing, create it yourself. Example pattern:
curl -X POST "$HOST/api/v1/orgs/Timmy_Foundation/repos" \
-H "Authorization: token $TOKEN" \
-H "Content-Type: application/json" \
-d '{"name":"manus-daily-worldstate","private":true,"auto_init":false}'
Then clone/push with the token embedded in the URL. Example pattern:
git clone "http://Timmy:${TOKEN}@143.198.27.163:3000/Timmy_Foundation/manus-daily-worldstate.git"
If that path fails, create a writable fallback repo under the authenticated user and continue immediately. Do not waste the day being confused about auth.
This is your once-per-day maximum-output order.
The scope is intentionally too large for one day.
Attempt it anyway.
Your mission:
Produce the maximum possible durable value across the Timmy ecosystem in a single day, and leave behind a Gitea-backed artifact trail so dense that even an incomplete run compounds.
You are not here to be realistic.
You are here to compress a week of founder, operator, researcher, archivist, strategist, and engineer labor into one day.
You must act across all of these layers:
- architecture
- code
- docs
- issue triage
- PR triage
- repo hygiene
- stale branch/worktree hygiene
- operational fragility
- product leverage
- business leverage
- research ingestion
- handoff quality
- next-step clarity
Primary output:
A daily world-state dossier pushed to Gitea, plus as many concrete fixes, branches, patches, docs, issue comments, and repo improvements as you can land before you run out of runway.
Target repo:
1. Prefer Timmy_Foundation/manus-daily-worldstate
2. If blocked, use manus/manus-daily-worldstate
3. If that fails, use any writable repo and create a dated directory there
4. Never let permission friction be your excuse for producing nothing
Host:
143.198.27.163:3000
Daily directory:
daily/YYYY-MM-DD/
Required deliverables every run:
daily/YYYY-MM-DD/00_EXECUTIVE_BRIEF.md
daily/YYYY-MM-DD/01_FULL_WORLD_STATE.md
daily/YYYY-MM-DD/02_REPO_HEALTH_MATRIX.md
daily/YYYY-MM-DD/03_OPEN_ISSUES_AND_PRS_TRIAGE.md
daily/YYYY-MM-DD/04_ARCHITECTURE_DRIFT.md
daily/YYYY-MM-DD/05_FRAGILITY_AND_RISK_REGISTER.md
daily/YYYY-MM-DD/06_OPPORTUNITY_REGISTER.md
daily/YYYY-MM-DD/07_IMPLEMENTED_CHANGES.md
daily/YYYY-MM-DD/08_UNFINISHED_WORK_WITH_FRONTIER.md
daily/YYYY-MM-DD/09_NEXT_3_DAY_BATTLE_PLAN.md
daily/YYYY-MM-DD/10_EVIDENCE_LOG.md
Also update:
README.md
LATEST.md
What you are expected to attempt in a single run:
1. Audit every reachable repo that matters
2. Triage every reachable open issue and PR that matters
3. Identify dead branches, stale worktrees, broken loops, and brittle automation
4. Detect architecture drift and undocumented reality
5. Find at least a few high-leverage fixes and actually implement them
6. Improve docs where reality and docs disagree
7. Surface the top risks that could silently waste time, money, or trust
8. Surface the top opportunities that could create product or business leverage
9. Leave behind a sharp plan for the next 72 hours
10. Push everything to Gitea in a way another operator can audit
Hard rules:
- facts beat vibes
- files beat chat
- commits beat intentions
- URLs, hashes, issue numbers, file paths, and commands beat abstractions
- separate FACT from INFERENCE from HYPOTHESIS from OPEN QUESTION
- if you cannot finish a fix, leave a patch-ready frontier
- if you cannot access something, document the boundary and move on
- do not get trapped polishing one rabbit hole
- breadth first, then decisive depth on highest leverage targets
- do not be timid
- do not be lazy
- do not produce generic summaries
- do not tell me what you wish you could do; show me what you actually did
Required minimum bar:
By the end of the run, you must have done enough that a human can point to Gitea and say:
“Manus changed the world state today.”
That means at least some combination of:
- pushed documentation
- pushed code
- pushed patches
- opened or updated issues/PRs
- produced triage matrices
- created runbooks
- created risk registers
- created opportunity memos
- identified exact next actions
Quality standard for the executive brief:
It should answer, in blunt language:
- what matters most right now
- what is rotting
- what is promising
- what changed today
- what should happen next
- where the truth is still missing
If the mission proves too large:
Good.
It was supposed to be.
Do not shrink the mission.
Instead, leave the densest possible trail:
- what you completed
- what you partially completed
- what you touched but could not finish
- what should be hit first tomorrow
Success criteria:
This daily run is only successful if:
1. there are pushed commits in Gitea
2. there is a dated daily dossier
3. the dossier contains evidence, not fluff
4. at least one part of the system is clearer, safer, better documented, or more advanced than before
5. your final response includes:
- repo URL
- branch
- latest commit hash
- exact files created or updated
- top 5 truths
- top 5 unfinished fronts
Do not aim to finish.
Aim to create compounding pressure and durable clarity.

9
reports/notebooklm/2026-03-27-hermes-openclaw/README.txt Normal file
View File

@@ -0,0 +1,9 @@
NotebookLM packet
Generated files:
- hermes-agent-backlog-vision-report.pdf
- openclaw-backlog-vision-report.pdf
Source markdown:
- hermes-agent-backlog-vision-report.md
- openclaw-backlog-vision-report.md

319
reports/notebooklm/2026-03-27-hermes-openclaw/hermes-agent-backlog-vision-report.md Normal file
View File

@@ -0,0 +1,319 @@
# Hermes Agent Research Report
Date: 2026-03-27
Audience: Alexander Whitestone / NotebookLM
Subject: Hermes Agent release notes and git history, mapped against Timmy backlog and vision
## Executive summary
Hermes Agent is already much closer to Timmy's desired operating system than the backlog wording makes it sound. The strongest overlaps are the messaging gateway, MCP, memory/session continuity, skills, delegation, Codex support, and migration paths from OpenClaw. The single most important caveat is version drift: Timmy backlog items often talk as if Hermes v0.4.0 capabilities are already local and proven, but the local sovereign branch I inspected is still anchored around the v0.2.0 release note plus a stream of newer post-release commits. That means several goals are directionally supported, but not all of them are locally landed in the exact form the backlog assumes.
The practical takeaway is simple: Hermes should still be treated as the center of gravity for Timmy. It already provides the majority of the platform surface Alexander wants. What remains is not a search for a totally different base system. It is a matter of tightening sovereignty defaults, verifying version assumptions, and deciding which pieces of OpenClaw should complement Hermes rather than replace it.
## Scope and methodology
This report was built from four source classes:
1. Local Hermes repo and docs
- Local repo path: `~/worktrees/gemini-base-rockachopa-hermes-agent`
- Key files reviewed:
- `README.md`
- `RELEASE_v0.2.0.md`
- `docs/migration/openclaw.md`
- `docs/honcho-integration-spec.md`
- `docs/acp-setup.md`
- `.plans/openai-api-server.md`
- `AGENTS.md`
2. Recent local git history on the `sovereign` branch
- Branch: `sovereign`
- Recent head at audit time: `4daad65 feat: fallback chain with recovery — Groq, Kimi, local Ollama`
3. Current Timmy backlog and vision in Gitea
- `Timmy_Foundation/timmy-home#7` — Developer standards / modular purity / local-first / SOUL compliance
- http://143.198.27.163:3000/Timmy_Foundation/timmy-home/issues/7
- `Timmy_Foundation/timmy-home#15` — Introducing codex-agent to Timmy and the team
- http://143.198.27.163:3000/Timmy_Foundation/timmy-home/issues/15
- `Timmy_Foundation/timmy-home#20` — Hermes Agent v0.4.0 architecture spike and backlog alignment
- http://143.198.27.163:3000/Timmy_Foundation/timmy-home/issues/20
- `Timmy_Foundation/timmy-config#19` — Register MCP servers in config.yaml
- http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/19
- `Timmy_Foundation/timmy-config#20` — Rewire heartbeat_tick to invoke Hermes sessions for training telemetry
- http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/20
- `Timmy_Foundation/timmy-config#21` — Enable Hermes trajectory export for training pipeline
- http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/21
- `Timmy_Foundation/timmy-config#22` — Switch model default from Anthropic cloud to local Ollama (sovereignty)
- http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/22
- `Timmy_Foundation/the-nexus#551` — Morning briefing / compressed memory injection at startup
- http://143.198.27.163:3000/Timmy_Foundation/the-nexus/issues/551
- `Timmy_Foundation/the-nexus#610` — Shadow Context Manager / auto-generated brain dump for session continuity
- http://143.198.27.163:3000/Timmy_Foundation/the-nexus/issues/610
- `Timmy_Foundation/the-nexus#660` — Three-layer game architecture: Timmy → Reflex → Pilot
- http://143.198.27.163:3000/Timmy_Foundation/the-nexus/issues/660
4. Supporting code paths and tests referenced by the local branch
## What Hermes already is, in platform terms
The current Hermes README still describes the right strategic shape for Timmy:
- a self-improving agent shell
- runs in CLI and messaging channels
- supports many providers and custom endpoints
- includes memory, session recall, skills, cron, delegation, and multiple terminal backends
- is already explicitly aware of OpenClaw migration
That matters because it means Timmy is not searching for a greenfield platform. Hermes already covers the majority of the desired surface area:
- messaging gateway
- memory and session continuity
- MCP
- cron and automation
- skills as procedural memory
- delegation and subagents
- Codex support
- local or sovereign model routing
In plain language: Hermes is already the operating body. The Timmy work is mostly about making it more sovereign, more coherent, and more explicitly Timmy.
## Release-note snapshot: what v0.2.0 proves
The v0.2.0 release note is the clearest stable anchor in the local tree.
File reviewed:
- `~/worktrees/gemini-base-rockachopa-hermes-agent/RELEASE_v0.2.0.md`
The release note shows that Hermes had already become, by March 12, 2026:
- a multi-platform messaging gateway
- an MCP-capable agent
- a skills ecosystem with broad categories
- a centralized provider router
- an ACP server for editor integration
- a worktree-aware coding agent
- a checkpoint/rollback capable tool user
- a tested, increasingly production-shaped platform
The features that matter most for Timmy's backlog are:
1. Messaging gateway
The release note confirms first-class support for Telegram, Discord, Slack, WhatsApp, Signal, Email, and Home Assistant. This directly supports Timmy's ambition to be reachable where Alexander lives, with one shared session and tool model.
2. MCP
The release note confirms native MCP with stdio and HTTP transports plus sampling support. This is directly aligned with `timmy-config#19` and the later OpenClaw-related MCP work.
3. Skills ecosystem
Hermes is already built around skills as durable procedural memory. That matches the Timmy worldview far better than a monolithic "hardcode it in the core" posture.
4. Codex
The release note explicitly calls out OpenAI Codex support. This matters for `timmy-home#15` and for Alexander's current preference to use Codex as a serious backend rather than as a side curiosity.
5. OpenClaw migration
The README and migration docs show that Hermes has already thought about OpenClaw as something to ingest, not just compete with. That is strategically important: Hermes sees OpenClaw as interoperable material.
## Recent git history: the signals that matter now
Recent local branch history suggests Hermes is still evolving toward exactly the kinds of things Timmy cares about.
Important recent commits:
- `4daad65` — `feat: fallback chain with recovery — Groq, Kimi, local Ollama`
This is the strongest sovereignty-adjacent commit in the recent local history. It does not make local primary by itself, but it does make local/provider recovery materially more robust.
- `26f8b79` — `fix(setup): persist provider when switching model endpoints`
This is an operational maturity fix. It reduces the chance that the system silently drifts between backends or loses the intended provider when switching models.
- `c2c37ef` — `Show configured model and provider in status output`
This is a visibility fix, but visibility is sovereignty. If Alexander cannot immediately see which provider/model is active, the stack is too easy to lie to himself about.
- `52ba940` — `feat(gateway): add reasoning hot reload`
This improves live operator control over gateway agents without requiring restart rituals.
- `7e52e8e` — `fix(gateway): bridge quick commands into GatewayConfig runtime`
This matters because quick commands are how a sovereign operator reduces friction and keeps recurring control actions cheap.
- `5c9a842` and `50d6659` — MEDIA/send_message salvage work
This reinforces messaging delivery correctness, which matters for any real multi-channel Timmy presence.
- `1a85712` — telephony skill
This extends the communications layer, though it is less sovereign than the core local-first vision.
## The most important alignment with Timmy backlog and vision
### 1. Sovereignty and local-first routing
Backlog reference:
- `timmy-config#22`
Hermes already supports:
- custom endpoints
- local/self-hosted inference
- explicit provider routing
- fallback chains
The gap is not capability. The gap is policy and default stance.
Hermes is already capable of sovereign routing. The remaining work is to make the default path actually reflect the sovereignty doctrine instead of leaving cloud-first behavior as the easy operational default.
This means `#22` is not blocked by missing architecture. It is blocked by config, discipline, and verification.
### 2. MCP and tool surface
Backlog references:
- `timmy-config#19`
- OpenClaw-related MCP issues later in the stack
Hermes is already a real MCP client. That means Timmy's practical near-term move is not "wait for a new harness." It is "wire the actual MCP servers into the existing harness cleanly and prove the flow."
This is a place where Hermes already gives Timmy a serious advantage.
### 3. Session continuity, memory, and the 'brain dump' vision
Backlog references:
- `the-nexus#551`
- `the-nexus#610`
Hermes already has several strong ingredients:
- session naming and search
- memory persistence
- Honcho-based user modeling
- compression and resume patterns
But the exact Timmy vision of a compressed, auto-generated continuity injection for fresh sessions is still not fully identical to current Hermes behavior.
Important conclusion:
Hermes is directionally aligned with the continuity vision, but the backlog still points to a real gap. The materials exist; the exact Timmy-specific continuity loop still needs to be made explicit.
### 4. Codex and coding-agent posture
Backlog reference:
- `timmy-home#15`
Hermes already supports Codex and ACP/editor workflows. This means Codex is not an external bolt-on dream. It is already part of the platform story.
That reduces strategic risk. Alexander can use Codex as a routed capability inside a broader agent system rather than as a separate universe.
### 5. Delegation and the three-layer architecture
Backlog reference:
- `the-nexus#660`
Hermes already has subagent delegation and isolated workstreams. That means the Timmy → Reflex → Pilot architecture is not alien to Hermes. It is just not fully realized in the exact three-layer form the game-agent architecture wants.
This is an important nuance:
- Hermes already contains the primitives.
- The Timmy stack still needs the opinionated architecture on top.
## Where the backlog overstates current local reality
This is the most important caution in the whole report.
`timmy-home#20` talks in the language of Hermes v0.4.0 and assumes a set of capabilities that are not all visible in the local sovereign checkout I inspected.
What I found locally:
- clear v0.2.0 release note
- recent post-release commits
- plans for more, including OpenAI-compatible API server work
- no local v0.4.0 release artifact in this checkout
Implication:
Some backlog items are comparing themselves to a newer upstream idea of Hermes than the locally anchored Timmy branch actually proves.
That does not mean the backlog is wrong.
It means Alexander should treat some items as:
- sync/upgrade/verify tasks
rather than
- already-landed local facts
The biggest examples are:
1. API server assumptions
There is a plan file for an OpenAI-compatible API server. That is not the same as a hardened, local, already-adopted production surface in this checkout.
2. MCP ergonomics
The backlog language can imply a friendlier install flow than what I actually found in-tree. Current Hermes MCP is powerful, but config-driven and more manual than the backlog fantasy in a few places.
3. Full continuity behavior
Hermes has strong continuity ingredients, but the exact Timmy "brain dump" continuity mechanism is still an active vision item, not a fully-closed fact.
## Where Hermes still falls short of the full Timmy vision
### 1. Nostr is not there in the same way
Hermes has broad messaging coverage, but not the exact Nostr/economic-peer layer Timmy wants.
### 2. Cron starts cold
Hermes cron is useful, but it still starts from a fresh context model. That means a lot of Timmy's continuity vision has to be made explicit if cron jobs are supposed to feel like one continuing mind rather than isolated tasks.
### 3. Multi-agent identity layering is incomplete
Hermes can delegate, but Timmy's deeper architecture wants more than generic delegation. It wants named cognitive layers with distinct roles and tight continuity.
### 4. Sovereignty still requires operator intent
Hermes can route locally. That does not mean it will do so unless Alexander or Timmy explicitly make that true. Sovereignty is possible; it is not yet automatically enforced by the system's defaults.
## Strategic conclusion
Hermes should remain the center of gravity.
Why:
- It already matches the broad shape of Timmy's desired system.
- It already has gateway, skills, memory, delegation, Codex, and MCP.
- It already has an import/migration posture toward OpenClaw.
- It is more aligned with Timmy's training and self-improvement future than OpenClaw is.
The right mental model is:
- Hermes is the body and the operational harness.
- Timmy is the soul and the doctrine.
- OpenClaw is a potentially useful sidecar or ingress layer, not the center of identity.
## Recommended actions
### Immediate
1. Treat `timmy-config#22` as a config-and-verification priority, not a research problem.
2. Treat `timmy-config#19` as a high-leverage harness integration task.
3. Treat `timmy-home#15` as already directionally supported by Hermes.
4. Audit which v0.4.0 assumptions are real in local Timmy branches versus only true upstream.
### Near-term
5. Build the Timmy-specific continuity layer on top of Hermes sessions and memory.
6. Clarify the exact difference between Hermes cron jobs and Timmy heartbeat continuity in implementation, not just theory.
7. Decide explicitly what remains unique to Timmy and what should remain upstream Hermes behavior.
### Strategic
8. Do not replace Hermes with OpenClaw.
9. Use OpenClaw only where it genuinely wins: sidecar gateway behaviors, additional channel patterns, or operator convenience.
10. Keep Timmy's long-term training/self-improvement loop grounded in Hermes-native state and artifacts.
## Final verdict
Hermes is not a maybe.
Hermes is already the strongest fit for Timmy's base runtime.
The real work now is not finding a better foundation. It is:
- reducing version confusion
- tightening sovereignty defaults
- finishing continuity machinery
- wiring the exact integrations Timmy wants
- using OpenClaw surgically instead of romantically
## Source appendix
Primary local files
- `~/worktrees/gemini-base-rockachopa-hermes-agent/README.md`
- `~/worktrees/gemini-base-rockachopa-hermes-agent/RELEASE_v0.2.0.md`
- `~/worktrees/gemini-base-rockachopa-hermes-agent/docs/migration/openclaw.md`
- `~/worktrees/gemini-base-rockachopa-hermes-agent/docs/honcho-integration-spec.md`
- `~/worktrees/gemini-base-rockachopa-hermes-agent/docs/acp-setup.md`
- `~/worktrees/gemini-base-rockachopa-hermes-agent/.plans/openai-api-server.md`
Key recent commits observed locally
- `4daad65` feat: fallback chain with recovery — Groq, Kimi, local Ollama
- `26f8b79` fix(setup): persist provider when switching model endpoints
- `c2c37ef` Show configured model and provider in status output
- `52ba940` feat(gateway): add reasoning hot reload
- `7e52e8e` fix(gateway): bridge quick commands into GatewayConfig runtime
- `5c9a842` fix: complete send_message MEDIA delivery salvage
- `1a85712` feat(skills): add optional telephony skill with Twilio, SMS, and AI calls
Backlog and vision references
- `timmy-home#7` — http://143.198.27.163:3000/Timmy_Foundation/timmy-home/issues/7
- `timmy-home#15` — http://143.198.27.163:3000/Timmy_Foundation/timmy-home/issues/15
- `timmy-home#20` — http://143.198.27.163:3000/Timmy_Foundation/timmy-home/issues/20
- `timmy-config#19` — http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/19
- `timmy-config#20` — http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/20
- `timmy-config#21` — http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/21
- `timmy-config#22` — http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/22
- `the-nexus#551` — http://143.198.27.163:3000/Timmy_Foundation/the-nexus/issues/551
- `the-nexus#610` — http://143.198.27.163:3000/Timmy_Foundation/the-nexus/issues/610
- `the-nexus#660` — http://143.198.27.163:3000/Timmy_Foundation/the-nexus/issues/660

499
reports/notebooklm/2026-03-27-hermes-openclaw/openclaw-backlog-vision-report.md Normal file
View File

@@ -0,0 +1,499 @@
# OpenClaw Research Report
Date: 2026-03-27
Audience: Alexander Whitestone / NotebookLM
Subject: OpenClaw release notes and git history, mapped against Timmy backlog and vision
## Executive summary
OpenClaw is real, fast-moving, and directionally useful for Timmy — but only in the right role. It is best understood as a powerful gateway shell, channel router, workspace/bootstrap system, and session bus. It is not the center of Timmy's learning architecture. It is not the soul. It is not the DPO/RL engine. It is not the long-term replacement for the Hermes harness.
The strongest case for OpenClaw is as a sidecar layer that provides:
- a polished gateway and operator surface
- additional messaging/channel primitives
- cron and heartbeat ergonomics
- workspace-driven identity and memory patterns
- OpenAI-compatible front-door surfaces
- session-to-session agent messaging
The strongest caution is that Timmy's backlog slightly over-romanticized a few things:
- SOUL.md inheritance is not universal across subagents
- cron is not the same thing as heartbeat continuity
- Nostr support is real but narrower than the full Timmy economic-peer vision
- transcript/export parity with Hermes is the hidden blocker for any serious migration of agent loops
The practical conclusion is:
OpenClaw is worth using, but only as a complement to Hermes. Install it, pin it, use it where it wins, and refuse to confuse gateway convenience with core identity or training infrastructure.
## Scope and methodology
This report draws from four source classes:
1. Upstream OpenClaw signals
- npm package: `openclaw`
- package cadence and latest release version
- upstream repo and docs
- recent release notes and recent git history
Upstream repo:
- https://github.com/openclaw/openclaw
Package metadata:
- npm latest observed during audit: `2026.3.24`
- repository URL from npm points at the GitHub repo above
2. Upstream docs reviewed
Representative docs and surfaces reviewed include:
- `README.md`
- architecture docs
- system prompt docs
- MCP docs
- heartbeat docs
- cron vs heartbeat docs
- model-provider docs
- session docs
- memory config docs
- local model docs
- Nostr extension docs
- package.json engine requirements
3. Timmy backlog and vision in Gitea
OpenClaw-specific and adjacent issues:
- Parent epic: `timmy-config#50`
- http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/50
- Canonical children after cleanup:
- `#52` install OpenClaw on M3 Max
- http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/52
- `#54` migrate Timmy identity to SOUL.md
- http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/54
- `#55` register MCP servers
- http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/55
- `#61` wire Nostr channel
- http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/61
- `#59` migrate heartbeat/cron from Huey
- http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/59
- `#60` multi-agent sessions (Timmy → Reflex → Pilot)
- http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/60
Adjacent vision issues:
- `timmy-config#19` MCP servers in config
- http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/19
- `timmy-config#20` heartbeat rewiring / training telemetry
- http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/20
- `timmy-config#22` local sovereign model default
- http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/22
- `the-nexus#13` Timmy as economic peer — Nostr identity, zap-out, vouching
- http://143.198.27.163:3000/Timmy_Foundation/the-nexus/issues/13
- `the-nexus#551` Morning briefing — compressed memory injection at startup
- http://143.198.27.163:3000/Timmy_Foundation/the-nexus/issues/551
- `the-nexus#610` Shadow Context Manager — auto-generated brain dump for session continuity
- http://143.198.27.163:3000/Timmy_Foundation/the-nexus/issues/610
- `the-nexus#660` Three-layer game architecture: Timmy → Reflex → Pilot
- http://143.198.27.163:3000/Timmy_Foundation/the-nexus/issues/660
4. Current local installation work completed today
- OpenClaw installed locally
- Codex backend configured and verified
- Timmy identity injected into the OpenClaw workspace
- local gateway running
## What OpenClaw is, upstream, in platform terms
OpenClaw is upstreaming a very specific product shape:
- personal AI assistant gateway
- multi-channel communications hub
- workspace/bootstrap scaffolding around agent identity
- session-based memory and routing
- cron and heartbeat as first-class agent automation tools
- plugin and skill ecosystem
- OpenAI-compatible API exposure
- agent session bus suitable for multi-agent coordination
This is why it is attractive for Timmy.
It already speaks the language of:
- channels
- sessions
- identity files
- local operator control
- gateway-based orchestration
That said, its center of gravity is still gateway/operator/product ergonomics, not Timmy's deeper learning loop.
## Upstream release-note and git-history signals
## Release cadence
OpenClaw is shipping fast enough that version discipline matters.
Observed package state during audit:
- npm latest: `2026.3.24`
- upstream repo HEAD already ahead at `2026.3.27`
This means any integration must be pinned to a tested version. Floating on `@latest` is asking for operational drift.
## What recent releases emphasize
### v2026.3.11
Important themes:
- first-class Ollama onboarding
- launchd/macOS restart stability improvements
- cron delivery tightening and migration work
Meaning for Timmy:
- installation and daemon management are much better than they were earlier
- macOS is a credible first-class target
- cron is no longer a toy feature
### v2026.3.22
Important themes:
- plugin and bundle work
- security hardening
- onboarding polish
- standardization around browser/session mechanics rather than legacy one-off browser relay hacks
Meaning for Timmy:
- upstream is converging on a cleaner product shell
- security posture is improving
- plugin-based extensibility is becoming a serious integration seam
### v2026.3.23
Important themes:
- Control UI, auth, and cron correctness
- timezone handling improvements
Meaning for Timmy:
- automation scheduling is becoming safer to trust for real daily flows
- UI/operator-facing polish is a major upstream priority
### v2026.3.24
Important themes:
- `/v1/models` and `/v1/embeddings`
- improved OpenAI-compatible model override forwarding
- tools visibility improvements
- more install/runtime hardening
Meaning for Timmy:
- OpenClaw is improving as a compatibility shell, not just a standalone assistant
- that increases its value as a sidecar gateway or front-door abstraction
## Important recent commits and what they imply
Representative recent signals observed during research:
- `eaad4ad1b` — added missing OpenAI-compatible endpoints
This is exactly the kind of compatibility work that makes OpenClaw useful as an interface layer.
- `66c88b4c7` and related engine-floor work
These commits tighten install assumptions and reduce "works on my machine" ambiguity.
- `71f37a59c` — channel MCP bridge work on main
This suggests upstream is still pushing the gateway/MCP/control-plane direction harder.
- `55dc6a8bb` — cron isolated delivery work
This reinforces that cron is being treated seriously, with isolation semantics that matter for agent hygiene.
- `5b4669632` — stale `sessions_send` carryover fix
This is a strong warning sign and a hopeful sign at once:
- warning: session-to-session multi-agent flows are still stabilizing
- hopeful: upstream is directly fixing the exact surface Timmy cares about
## The strongest fit to Timmy backlog and vision
### 1. Install and gateway bootstrap
Backlog reference:
- `timmy-config#52`
This is strongly aligned and lower risk than the issue originally assumed.
OpenClaw now has:
- sane onboarding
- local config/workspace creation
- launchd install support on macOS
- clearer gateway lifecycle commands
That means install is no longer the scary part.
The real question is what role OpenClaw should play after install.
### 2. Identity files and Timmy voice
Backlog reference:
- `timmy-config#54`
OpenClaw's use of workspace files is a real fit for Timmy.
The philosophy is compatible:
- `SOUL.md`
- `AGENTS.md`
- `TOOLS.md`
- `USER.md`
- `HEARTBEAT.md`
This makes OpenClaw attractive as a host for Timmy's identity scaffolding.
But there is one crucial correction:
subagents do not automatically inherit `SOUL.md` the same way the main agent does.
That means the backlog should not assume that writing Timmy's soul into one place magically solves multi-agent identity. For main Timmy, yes. For Reflex/Pilot or other subordinate agent roles, no.
### 3. MCP registration and gateway-level tooling
Backlog references:
- `timmy-config#19`
- `timmy-config#55`
This is one of OpenClaw's strongest real matches.
Saved MCP definitions at the gateway/agent level are directly supported. This is exactly the kind of integration seam Timmy needs for desktop control, Gitea/Forgejo, Morrowind MCP, and similar tools.
This is a high-confidence, high-leverage part of the OpenClaw plan.
### 4. Heartbeat and cron
Backlog references:
- `timmy-config#20`
- `timmy-config#59`
- `the-nexus#551`
- `the-nexus#610`
OpenClaw is explicitly designed around the distinction between heartbeat and cron.
That matters because Timmy's backlog was trying to use the words a little too interchangeably.
Upstream pattern:
- heartbeat = periodic awareness in the main session, for bundled checks and ongoing continuity
- cron = precise scheduled tasks, often isolated and exact
This means the right Timmy mapping is:
- morning briefing = cron
- periodic awareness / scanning / continuity = heartbeat
- compressed context injection remains a Timmy-specific design problem layered on top
This is a very important alignment win — but it also reveals the hidden blocker.
### 5. Session bus and multi-agent routing
Backlog reference:
- `timmy-config#60`
- `the-nexus#660`
OpenClaw is conceptually well aligned with the Timmy → Reflex → Pilot architecture.
The session bus and session-to-session messaging are real features.
But this is also the most churn-prone upstream area.
Recent fixes around session ownership, stale carryover, and routing metadata imply that this part of the system is still actively being hardened.
The conclusion is not "don't do it."
The conclusion is:
- do not make this your first integration milestone
- do the boring foundation first
### 6. Nostr
Backlog reference:
- `timmy-config#61`
- `the-nexus#13`
OpenClaw's Nostr support is meaningful, but narrower than the full vision.
What it does well:
- sovereign DM channel
- relay-based communications
- another non-corporate ingress path
What it does not yet equal:
- full Timmy economic-peer vision
- zap-out
- deeper trust/vouching/economic behavior
So the right framing is:
- good step toward sovereign reachability
- not the whole Nostr dream
## The hidden blocker: transcript and training-pipeline parity
This is the most important operational conclusion in the OpenClaw report.
If Timmy moves heartbeat or other agent loops from Hermes to OpenClaw without building a transcript/export bridge, he risks breaking the current training and telemetry flow.
Hermes currently has an existing path for session/export/DPO-style work.
OpenClaw stores sessions in its own structure.
That means migration without translation equals lost continuity in the training pipeline.
So before major loop migration, Timmy needs:
- transcript export mapping
- session metadata mapping
- a way to preserve the same training value that Hermes artifacts currently provide
This is more important than Nostr.
This is more important than multi-agent theatrics.
This is more important than yet another channel.
Because if Timmy loses the learning trail, the entire stack becomes less valuable.
## Where OpenClaw conflicts with Timmy's core doctrine
### 1. OpenClaw is not the self-improvement engine
OpenClaw is a harness and gateway shell.
It is not Timmy's learning loop.
It is not the DPO or RL substrate.
It is not where the soul belongs as the final authority.
### 2. Docs and defaults are still more cloud-shaped than Timmy-shaped
OpenClaw supports local models and local-first flows, but the upstream product imagination still feels closer to a broad personal-assistant shell than to a radical sovereignty doctrine.
That does not make it bad.
It makes it a tool that must be domesticated.
### 3. Main-session power is broad
OpenClaw can be powerful fast.
That is useful for a sovereign personal assistant.
It is also why channel exposure needs discipline.
If Timmy exposes OpenClaw to the wrong surfaces too early, the convenience can outrun the policy layer.
## The right backlog priority order for OpenClaw
### Priority 1: install and pin
- `timmy-config#52`
- pair with the broader sovereign backend stance from `timmy-config#22`
Meaning:
- do not float on `@latest`
- pin a tested release
- make the gateway stable before doing clever things
### Priority 2: workspace identity for main Timmy
- `timmy-config#54`
Meaning:
- use OpenClaw's workspace model for Timmy's main identity
- but explicitly document that subagents need separate treatment
### Priority 3: MCP registration
- `timmy-config#19`
- `timmy-config#55`
Meaning:
- one of the highest-confidence wins available
- strong return on integration effort
### Priority 4: telemetry/export bridge
- `timmy-config#20`
- `timmy-config#59`
Meaning:
- do this before real migration of agent-initiated loops
- otherwise you sacrifice the learning trail
### Priority 5: separate cron from heartbeat properly
- `the-nexus#551`
- `the-nexus#610`
- `timmy-config#59`
Meaning:
- morning briefing should be cron
- periodic awareness should be heartbeat
- continuity injection remains a Timmy layer on top
### Priority 6: Nostr channel
- `timmy-config#61`
- partial contribution toward `the-nexus#13`
Meaning:
- valuable sovereign ingress
- not the full economic-peer story
### Priority 7: multi-agent sessions
- `timmy-config#60`
- `the-nexus#660`
Meaning:
- important vision item
- should come after boring foundation work because upstream is still tightening this area
## Current local status as of this report
Today, the following was accomplished locally:
- OpenClaw installed
- OpenClaw gateway installed and started on macOS
- local dashboard available
- Timmy identity files written into the OpenClaw workspace
- OpenClaw configured to use the OpenAI Codex backend instead of a local model for this pass
- first successful live Timmy response through OpenClaw completed
Relevant local proof links in Gitea:
- parent epic:
- http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/50
- install issue:
- http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/52
- latest install/proof comment:
- http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/52#issuecomment-21661
Local dashboard:
- http://127.0.0.1:18789/
This matters because OpenClaw is no longer hypothetical in the Timmy environment. It is now real enough to evaluate as an actual sidecar.
## Strategic conclusion
OpenClaw is worth keeping.
But it is not worth worshipping.
Its best role is:
- sidecar gateway
- channel shell
- operator-facing automation surface
- identity/bootstrap workspace
- session bus for selected multi-agent flows
Its worst role would be:
- replacing Hermes as Timmy's core training/memory/sovereignty body
- becoming the new center of truth just because it has a cleaner gateway surface
The right stance is:
- let Hermes remain the body
- let Timmy remain the soul
- let OpenClaw earn specific responsibilities where it is genuinely stronger
## Final verdict
OpenClaw is strategically useful.
It is not the foundation.
It should be installed, pinned, and used deliberately.
The next correct milestone is not "move everything into OpenClaw."
The next correct milestone is:
- use OpenClaw where it clearly wins,
- prove transcript/export parity before migrating serious loops,
- and keep Hermes as the system Timmy grows from.
## Source appendix
Upstream repo
- https://github.com/openclaw/openclaw
Package metadata observed
- npm `openclaw` latest during audit: `2026.3.24`
- upstream repo HEAD observed ahead of npm release cadence
Representative upstream docs reviewed
- `README.md`
- architecture docs
- system prompt docs
- MCP docs
- heartbeat docs
- cron-vs-heartbeat docs
- model provider docs
- session docs
- memory config docs
- local models docs
- Nostr extension docs
- `package.json`
Canonical Timmy backlog and vision issues
- `timmy-config#50` — http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/50
- `timmy-config#52` — http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/52
- `timmy-config#54` — http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/54
- `timmy-config#55` — http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/55
- `timmy-config#59` — http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/59
- `timmy-config#60` — http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/60
- `timmy-config#61` — http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/61
- `timmy-config#19` — http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/19
- `timmy-config#20` — http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/20
- `timmy-config#22` — http://143.198.27.163:3000/Timmy_Foundation/timmy-config/issues/22
- `the-nexus#13` — http://143.198.27.163:3000/Timmy_Foundation/the-nexus/issues/13
- `the-nexus#551` — http://143.198.27.163:3000/Timmy_Foundation/the-nexus/issues/551
- `the-nexus#610` — http://143.198.27.163:3000/Timmy_Foundation/the-nexus/issues/610
- `the-nexus#660` — http://143.198.27.163:3000/Timmy_Foundation/the-nexus/issues/660

117
reports/notebooklm/2026-03-27-hermes-openclaw/render_reports.py Normal file
View File

@@ -0,0 +1,117 @@
from pathlib import Path
import re, html
from reportlab.lib.pagesizes import letter
from reportlab.lib.styles import getSampleStyleSheet, ParagraphStyle
from reportlab.lib import colors
from reportlab.platypus import SimpleDocTemplate, Paragraph, Spacer, Preformatted, ListFlowable, ListItem
from reportlab.lib.units import inch
base = Path.home()/'.timmy'/'reports'/'notebooklm'/'2026-03-27-hermes-openclaw'
styles = getSampleStyleSheet()
styles.add(ParagraphStyle(name='Body2', parent=styles['BodyText'], fontName='Helvetica', fontSize=10.5, leading=14, spaceAfter=6))
styles.add(ParagraphStyle(name='H1x', parent=styles['Heading1'], fontName='Helvetica-Bold', fontSize=20, leading=24, spaceAfter=12, textColor=colors.HexColor('#111111')))
styles.add(ParagraphStyle(name='H2x', parent=styles['Heading2'], fontName='Helvetica-Bold', fontSize=15, leading=19, spaceBefore=8, spaceAfter=8, textColor=colors.HexColor('#222222')))
styles.add(ParagraphStyle(name='H3x', parent=styles['Heading3'], fontName='Helvetica-Bold', fontSize=12.5, leading=16, spaceBefore=6, spaceAfter=6))
styles.add(ParagraphStyle(name='CodeBlockX', parent=styles['Code'], fontName='Courier', fontSize=8.5, leading=10.5, leftIndent=12, rightIndent=12, backColor=colors.HexColor('#F4F4F4'), borderPadding=6, spaceAfter=8))
styles.add(ParagraphStyle(name='MetaX', parent=styles['BodyText'], fontName='Helvetica-Oblique', fontSize=9.5, leading=12, textColor=colors.HexColor('#555555'), spaceAfter=6))
url_re = re.compile(r'(https?://[^\s)]+)')
def linkify(text: str) -> str:
esc = html.escape(text)
return url_re.sub(lambda m: f'<link href="{m.group(1)}" color="blue">{m.group(1)}</link>', esc)
def markdown_to_story(md_path: Path):
text = md_path.read_text()
lines = text.splitlines()
story = []
i = 0
while i < len(lines):
line = lines[i]
if not line.strip():
i += 1
continue
if line.startswith('```'):
i += 1
buf = []
while i < len(lines) and not lines[i].startswith('```'):
buf.append(lines[i])
i += 1
if i < len(lines) and lines[i].startswith('```'):
i += 1
story.append(Preformatted('\n'.join(buf), styles['CodeBlockX']))
continue
if line.startswith('# '):
story.append(Paragraph(linkify(line[2:].strip()), styles['H1x']))
i += 1
continue
if line.startswith('## '):
story.append(Paragraph(linkify(line[3:].strip()), styles['H2x']))
i += 1
continue
if line.startswith('### '):
story.append(Paragraph(linkify(line[4:].strip()), styles['H3x']))
i += 1
continue
if re.match(r'^-\s+', line):
items = []
while i < len(lines) and re.match(r'^-\s+', lines[i]):
item_text = re.sub(r'^-\s+', '', lines[i]).strip()
items.append(ListItem(Paragraph(linkify(item_text), styles['Body2'])))
i += 1
story.append(ListFlowable(items, bulletType='bullet', leftIndent=18))
story.append(Spacer(1, 6))
continue
if re.match(r'^\d+\.\s+', line):
items = []
while i < len(lines) and re.match(r'^\d+\.\s+', lines[i]):
item_text = re.sub(r'^\d+\.\s+', '', lines[i]).strip()
items.append(ListItem(Paragraph(linkify(item_text), styles['Body2'])))
i += 1
story.append(ListFlowable(items, bulletType='1', leftIndent=18))
story.append(Spacer(1, 6))
continue
buf = [line.strip()]
i += 1
while i < len(lines) and lines[i].strip() and not any([
lines[i].startswith('# '), lines[i].startswith('## '), lines[i].startswith('### '),
lines[i].startswith('```'), re.match(r'^-\s+', lines[i]), re.match(r'^\d+\.\s+', lines[i])
]):
buf.append(lines[i].strip())
i += 1
paragraph = ' '.join(buf)
style = styles['MetaX'] if paragraph.startswith('Date:') or paragraph.startswith('Audience:') or paragraph.startswith('Subject:') else styles['Body2']
story.append(Paragraph(linkify(paragraph), style))
return story
def add_footer(canvas, doc):
canvas.saveState()
canvas.setFont('Helvetica', 8)
canvas.setFillColor(colors.HexColor('#666666'))
canvas.drawString(doc.leftMargin, 0.45*inch, f'{doc.title}')
canvas.drawRightString(letter[0]-doc.rightMargin, 0.45*inch, f'Page {doc.page}')
canvas.restoreState()
files = [
('hermes-agent-backlog-vision-report.md', 'Hermes Agent Research Report'),
('openclaw-backlog-vision-report.md', 'OpenClaw Research Report'),
]
for md_name, title in files:
md_path = base/md_name
pdf_path = base/md_name.replace('.md', '.pdf')
story = markdown_to_story(md_path)
doc = SimpleDocTemplate(str(pdf_path), pagesize=letter, leftMargin=0.7*inch, rightMargin=0.7*inch, topMargin=0.75*inch, bottomMargin=0.7*inch, title=title)
doc.build(story, onFirstPage=add_footer, onLaterPages=add_footer)
(base/'README.txt').write_text(
'NotebookLM packet\n\n'
'Generated files:\n'
'- hermes-agent-backlog-vision-report.pdf\n'
'- openclaw-backlog-vision-report.pdf\n\n'
'Source markdown:\n'
'- hermes-agent-backlog-vision-report.md\n'
'- openclaw-backlog-vision-report.md\n'
)
for p in sorted(base.iterdir()):
print(f'{p.name}\t{p.stat().st_size}')