docs(obsidian): sync shared vault updates
This commit is contained in:
William Valentin
@@ -1 +1,4 @@
|
||||
{}
|
||||
{
|
||||
"cssTheme": "Rose Pine",
|
||||
"interfaceFontFamily": ""
|
||||
}
|
||||
+6
-1
@@ -1,3 +1,8 @@
|
||||
[
|
||||
"obsidian-local-rest-api"
|
||||
"obsidian-local-rest-api",
|
||||
"dataview",
|
||||
"obsidian-tasks-plugin",
|
||||
"notebook-navigator",
|
||||
"advanced-canvas",
|
||||
"table-editor-obsidian"
|
||||
]
|
||||
@@ -0,0 +1,5 @@
|
||||
{
|
||||
"format": "YYYY-MM-DD",
|
||||
"folder": "Daily",
|
||||
"template": "Templates/Daily Note"
|
||||
}
|
||||
@@ -0,0 +1,3 @@
|
||||
{
|
||||
"folder": "Templates"
|
||||
}
|
||||
@@ -0,0 +1,5 @@
|
||||
# Archive
|
||||
|
||||
Inactive notes go here when they are no longer current but may still be useful.
|
||||
|
||||
Do not delete project history or decisions just because they are old; archive instead.
|
||||
@@ -0,0 +1,13 @@
|
||||
# Areas Home
|
||||
|
||||
Areas are ongoing responsibilities without a defined end date.
|
||||
|
||||
Examples:
|
||||
|
||||
- [[Systems]]
|
||||
- [[Health]]
|
||||
- [[Finance]]
|
||||
- [[Home]]
|
||||
- [[Learning]]
|
||||
|
||||
Use area notes to collect standards, recurring processes, and long-running responsibilities.
|
||||
@@ -0,0 +1,3 @@
|
||||
# Finance
|
||||
|
||||
Area index for finance-related notes.
|
||||
@@ -0,0 +1,3 @@
|
||||
# Health and Medical Leave
|
||||
|
||||
Redirect/index note. Canonical personal-context note: [[Atlas/Personal Context/Areas/Health and Medical Leave]].
|
||||
@@ -0,0 +1,3 @@
|
||||
# Health
|
||||
|
||||
Area index. Sensitive details live under [[Atlas/Personal Context/Areas/Health and Medical Leave]].
|
||||
@@ -0,0 +1,3 @@
|
||||
# Home
|
||||
|
||||
Area index for home/life logistics.
|
||||
@@ -0,0 +1,3 @@
|
||||
# Learning
|
||||
|
||||
Area index for learning resources and plans.
|
||||
@@ -0,0 +1,3 @@
|
||||
# Legal
|
||||
|
||||
Redirect/index note. Canonical personal-context note: [[Atlas/Personal Context/Areas/Legal]].
|
||||
@@ -0,0 +1,3 @@
|
||||
# Systems
|
||||
|
||||
Area index for systems and automation. See [[Infrastructure/Architecture]], [[Resources/Service Catalog]], and [[Ops Home]].
|
||||
+31
@@ -0,0 +1,31 @@
|
||||
# Daily Hermes + AI Research Brief — May 18, 2026
|
||||
|
||||
## Important updates
|
||||
|
||||
- **Hermes Agent v0.14.0 “Foundation Release” landed May 16.** GitHub release snippets report a large jump since v0.13.0: **808 commits, 633 merged PRs, 1,393 files changed**. This is worth a safe update audit for Will’s production Atlas gateway, but not an automatic update because local config/source changes may exist. Source: [GitHub releases](https://github.com/NousResearch/hermes-agent/releases)
|
||||
|
||||
- **Hermes docs now emphasize “profile distributions” for sharing whole agents.** This is directly relevant to Will’s specialist roster: Atlas/default can stay stable while reusable researcher/writer/ops/engineer profile bundles are packaged and replicated. Source: [Hermes profile distributions docs](https://hermes-agent.nousresearch.com/docs/user-guide/profile-distributions)
|
||||
|
||||
- **Hermes provider-extension docs are now explicit about auth, runtime resolution, CLI flows, adapters, tests, and docs.** Useful if Will wants clean support for custom/local providers like llama.cpp, GLM/Z.AI, Gemini ACP, LiteLLM routes, or CoreWeave-hosted endpoints. Source: [Adding Providers — Hermes Agent](https://hermes-agent.nousresearch.com/docs/developer-guide/adding-providers)
|
||||
|
||||
- **Agent observability is becoming a practical infra pattern.** Red Hat’s OpenTelemetry writeup frames agentic systems as composed of routing agents, specialist agents, LLM inference, MCP servers, and external integrations — basically Will’s Atlas architecture. The takeaway: trace tool calls, model routing, retries, and MCP/server hops as first-class spans. Source: [Red Hat: Distributed tracing for agentic workflows](https://developers.redhat.com/articles/2026/04/06/distributed-tracing-agentic-workflows-opentelemetry)
|
||||
|
||||
- **Inference-on-Kubernetes momentum is accelerating.** Red Hat is positioning `llm-d`/AI Inference for managed Kubernetes including CoreWeave/Azure, and Microsoft published a fresh AKS-oriented controllable inference platform pattern covering llama.cpp plus GPU vLLM/TensorRT-LLM workloads. This maps well to Will’s CoreWeave/k8s and local swarm interests. Sources: [Red Hat AI Inference / llm-d](https://www.redhat.com/de/blog/red-hat-ai-inference-brings-llm-d-any-managed-kubernetes-starting-coreweave-and-microsoft-azure), [Microsoft AI Runway on Kubernetes](https://techcommunity.microsoft.com/blog/azuredevcommunityblog/building-a-controllable-inference-platform-on-kubernetes-with-ai-runway/4520590)
|
||||
|
||||
- **MCP security/governance keeps surfacing as the unsexy but important agent problem.** Recent posts frame direct agent-to-MCP-server connections as a supply-chain/security risk and call out over-permissioned tools. This matters for Atlas because gateway + local services + specialist profiles can easily accumulate too much ambient authority. Sources: [Box on agent/MCP supply-chain risk](https://blog.box.com/ai-agents-are-creating-new-supply-chain-crisis-we-have-narrow-window-get-it-right), [Kong on MCP tool governance](https://konghq.com/blog/engineering/mcp-tool-governance-security-meets-context-efficiency)
|
||||
|
||||
## Actionable ideas for us
|
||||
|
||||
- **[quick] Run a read-only Hermes update check later today:** compare local `main` vs `origin/main`, inspect dirty files, and only then decide whether to create a gated update board for v0.14.0.
|
||||
|
||||
- **[experiment] Add lightweight OpenTelemetry-style tracing around Atlas workflows:** start with cron jobs, model/provider routing, tool calls, n8n hooks, and local swarm service calls; even JSONL spans would help debug latency and failures.
|
||||
|
||||
- **[experiment] Prototype a “profile distribution” export for Will’s specialist roster:** default/Atlas stays production; export stopped/manual profiles like researcher, writer, ops, engineer, reviewer, glm-simple.
|
||||
|
||||
- **[watch] Track MCP permission boundaries:** define which profiles may call which local services/tools, especially anything touching filesystem, Telegram/Discord delivery, n8n, credentials, or GPU inference endpoints.
|
||||
|
||||
## Worth ignoring
|
||||
|
||||
- Generic “best AI agents of 2026” listicles unless they include reproducible benchmarks, cost data, or architecture details.
|
||||
- Hermes star-count hype without concrete release notes or operational changes.
|
||||
- Consumer AI app announcements that do not expose APIs, local deployment options, MCP/tool interfaces, or infra lessons.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
# Daily Hermes + AI Research Brief — 2026-05-19
|
||||
|
||||
## Important updates
|
||||
|
||||
- **Hermes Agent v0.14.0 / v2026.5.16 is the main Hermes item to track.** GitHub release search shows a May 16 release with **808 commits, 633 merged PRs, and 1,393 files changed** since v0.13.0; snippets highlight PyPI install support, ~19s faster cold start, much faster Browser CDP calls, and new messaging work. This matters because Will’s default Atlas gateway is source-installed and gateway uptime/update safety is more important than chasing the release immediately. Source: [GitHub releases](https://github.com/NousResearch/hermes-agent/releases) / [release search result](https://github.com/NousResearch/hermes-agent/releases/tag/v2026.5.16).
|
||||
- **Hermes v0.13.0 / v2026.5.7 shipped the “Tenacity” durable-work direction.** NewReleases summarizes it as Kanban becoming a durable multi-agent board with heartbeat, reclaim, zombie detection, and auto-block behavior. This aligns directly with Will’s specialist-profile/worker setup; it is worth treating Kanban as the safe path for long agent tasks instead of ad-hoc background spawns. Source: [NewReleases v2026.5.7](https://newreleases.io/project/github/NousResearch/hermes-agent/release/v2026.5.7).
|
||||
- **Hermes docs continue to emphasize self-improving skills, persistent memory, profiles, messaging gateway, and provider-agnostic routing.** That is not a “new today” item, but it confirms Atlas’s current architecture choices: keep `default` as the production Telegram gateway, use specialist profiles for isolation, and save durable research outputs into Obsidian rather than memory. Source: [Hermes Agent docs](https://hermes-agent.nousresearch.com/docs/).
|
||||
- **MCP scaling pattern worth adopting: expose many tools as code APIs inside execution environments, not as hundreds of direct LLM tools.** Anthropic’s engineering writeup says code execution with MCP can make agents more efficient by letting the model write code that calls MCP APIs, reducing tool-schema/token pressure. For Will, this suggests future Atlas/n8n/local-swarm integrations should prefer compact wrapper APIs and executable client libraries when tool count grows. Source: [Anthropic Engineering — Code execution with MCP](https://www.anthropic.com/engineering/code-execution-with-mcp).
|
||||
- **Open-source infra maintainers are now explicitly dealing with AI-generated PR load.** MLSys has an invited talk, “Rethinking Open Source Contribution in the Age of AI Agents,” framed around vLLM and the surge of AI-generated pull requests. This matters for Will’s CoreWeave/k8s/LLM-infra work: review gates, narrow tests, provenance, and anti-slop contribution policies are now part of production LLM ops, not just repo hygiene. Source: [MLSys 2026 schedule](https://mlsys.org/virtual/2026/day/5/18) / [invited talk](https://mlsys.org/virtual/2026/invited-talk/10000).
|
||||
|
||||
## Actionable ideas for us
|
||||
|
||||
- **[quick]** Check local Hermes safely before updating: `hermes --version`, `git status --short --branch`, and `git rev-list --left-right --count main...origin/main`; do **not** run `hermes update` automatically if the tree is dirty.
|
||||
- **[quick]** Review whether Atlas’s Browser/CDP and messaging paths benefit from v0.14.0, but route any upgrade through the safe update workflow because the gateway is production.
|
||||
- **[experiment]** Prototype one “code API over tool flood” integration for local swarm services: a small Python client that wraps n8n, llama.cpp, Ollama embeddings, and Obsidian REST behind a few stable calls.
|
||||
- **[watch]** Track Hermes issues/releases around v0.14.0 for Windows/PyPI/lazy dependency fallout and any gateway regressions before adopting it on `default`.
|
||||
|
||||
## Worth ignoring
|
||||
|
||||
- Generic “agent landscape 2026” listicles unless they include concrete implementation details, benchmarks, or repo links.
|
||||
- Funding/market stories about AI agents with no deployable tooling, protocol, model, or infra takeaway.
|
||||
- Consumer-only agent announcements unless they expose useful MCP/tooling/local-first patterns.
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
# Daily Hermes + AI Research Brief — 2026-05-20
|
||||
|
||||
## Important updates
|
||||
|
||||
- **Hermes Agent v0.13 / “Tenacity” remains the key Hermes update to track.** GitHub release/search results list v2026.5.7 with Kanban as a durable multi-agent board, heartbeat/reclaim/zombie detection/auto-block behavior, and a large reliability-focused release since v0.12.0. This matters because Will’s Atlas setup already depends on default gateway stability plus specialist profiles/Kanban for durable work. Source: [NousResearch/hermes-agent releases](https://github.com/NousResearch/hermes-agent/releases).
|
||||
- **Hermes docs continue to emphasize self-improving skills, persistent memory, profiles, gateway, plugins, MCP, cron, and Kanban.** For Will, the practical takeaway is to keep Atlas’ daily operations split between short memory pointers, Obsidian for durable context, and specialist-profile delegation rather than stuffing everything into one long session. Source: [Hermes Agent Documentation](https://hermes-agent.nousresearch.com/docs/).
|
||||
- **OpenAI Codex CLI shipped another May update.** The Codex changelog shows “Codex CLI 0.130.0” on 2026-05-08 with performance improvements/bug fixes. This is relevant because Will’s Hermes workers/profiles use Codex auth in some paths; keep profile auth smoke tests in the loop before dispatching autonomous coding agents. Source: [OpenAI Codex changelog](https://developers.openai.com/codex/changelog).
|
||||
- **1Password announced/covered just-in-time credential access for Codex via MCP.** The useful pattern is not the vendor hype; it is the architecture: coding agents should request narrowly scoped, auditable secrets at task time instead of having broad static env access. This maps directly to safer Hermes MCP/tool credentials and swarm service secrets. Source: [SiliconANGLE coverage](https://siliconangle.com/2026/05/20/1password-extends-openai-collaboration-codex-mcp-server-just-time-credential-access/).
|
||||
- **MCP remains the practical integration layer to watch.** Recent MCP comparisons and Anthropic engineering material emphasize implementing tools once and exposing them across agent clients. For Will, this supports consolidating local services—Obsidian, n8n, Ollama/llama.cpp, Kokoro/Whisper—behind stable MCP/tool wrappers instead of one-off scripts. Sources: [ClickHouse MCP framework comparison](https://clickhouse.com/blog/how-to-build-ai-agents-mcp-12-frameworks), [Anthropic on MCP code execution](https://www.anthropic.com/engineering/code-execution-with-mcp).
|
||||
- **AI observability is moving from infra-only metrics to LLM-specific monitoring.** Current LLMOps guidance stresses that healthy CPU/GPU dashboards do not prove agent quality; you need latency, error rates, tool-call failures, prompt/model routing traces, and evaluation signals. This is directly useful for Will’s CoreWeave/GPU/k8s-style work and local swarm reliability. Source: [Kong AI observability guide](https://konghq.com/blog/learning-center/guide-to-ai-observability).
|
||||
|
||||
## Actionable ideas for us
|
||||
|
||||
- **[quick]** Add a recurring manual check item for Hermes release notes: compare local `~/.hermes/hermes-agent` against `origin/main` and v2026.5.7+ release notes, but only use the safe isolated update flow.
|
||||
- **[quick]** Smoke-test specialist profiles that may use Codex: `hermes -p <profile> chat -q 'Reply exactly: ok' --toolsets safe -Q` before Kanban dispatch.
|
||||
- **[experiment]** Prototype an MCP-style “just-in-time secret” pattern locally: agent requests a named credential lease for one task; logs scope and expiration; never exposes raw secrets in final output.
|
||||
- **[watch]** Track Hermes Kanban reliability and session-rollover/handoff changes; these are likely to matter more for Atlas autonomy than flashy model announcements.
|
||||
|
||||
## Worth ignoring
|
||||
|
||||
- Generic “AI agents in 2026” listicles with no implementation detail.
|
||||
- Funding/partnership headlines unless they ship concrete APIs, MCP servers, model routing, or local-first tooling.
|
||||
- Consumer chatbot feature news with no path to Hermes, Obsidian, n8n, local inference, or GPU ops.
|
||||
@@ -0,0 +1,5 @@
|
||||
# Gateway Approval Runbook
|
||||
|
||||
Redirect/index note for gateway approval procedures.
|
||||
|
||||
Related: [[Runbooks/Atlas Event-Driven Automation]], [[Projects/Atlas Discord Telegram Workflow]]
|
||||
+136
@@ -0,0 +1,136 @@
|
||||
---
|
||||
tags: [atlas, personal-context, health, fmla, playbook]
|
||||
type: playbook
|
||||
created: 2026-05-15
|
||||
sensitive: true
|
||||
status: active
|
||||
---
|
||||
|
||||
# FMLA Monday Appointment Playbook
|
||||
|
||||
Purpose: make it easy to take action Monday without having to think from scratch.
|
||||
|
||||
Current blocker: Will needs a doctor appointment for medical leave/FMLA support. PCP is booked until late this month.
|
||||
|
||||
## Goal for Monday
|
||||
|
||||
Get one of these outcomes:
|
||||
|
||||
1. A sooner appointment with PCP, any care-team provider, telehealth, or same-clinic clinician.
|
||||
2. Clear instructions from the clinic on how to get FMLA/medical-leave documentation started before the PCP appointment.
|
||||
3. A backup appointment/path through behavioral health, urgent/same-day care, or another clinician who can document current functional impairment.
|
||||
|
||||
## Minimum viable win
|
||||
|
||||
If energy is low, do only this:
|
||||
|
||||
- Send the portal message below.
|
||||
- Set one follow-up reminder for the next business day.
|
||||
|
||||
That counts as progress.
|
||||
|
||||
## Before calling or messaging
|
||||
|
||||
Gather these if easy. Do not let this block sending the message.
|
||||
|
||||
- [ ] Clinic/PCP name
|
||||
- [ ] Patient portal login
|
||||
- [ ] Employer/benefits/FMLA form, if already available
|
||||
- [ ] Any HR deadline or requested date range
|
||||
- [ ] Current requested leave duration: 3 months
|
||||
- [ ] Short description: depression/anxiety/sleep difficulty currently preventing work
|
||||
|
||||
## Portal message / email draft
|
||||
|
||||
Subject: FMLA paperwork / appointment request
|
||||
|
||||
Hi Dr. [Name] / Care Team,
|
||||
|
||||
I need help with FMLA paperwork related to ongoing mental health symptoms, including depression/anxiety and sleep difficulty. My employer is CoreWeave, and I need medical certification from my PCP.
|
||||
|
||||
Could we schedule the soonest available appointment to review this and complete the forms? If possible, please let me know the best way to send the FMLA paperwork ahead of time.
|
||||
|
||||
I’m looking for support with protected leave/intermittent leave as appropriate while I’m addressing these health issues.
|
||||
|
||||
Thank you,
|
||||
William Valentin
|
||||
|
||||
### Shorter portal version
|
||||
|
||||
Hi Dr. [Name] / Care Team — I need help with FMLA paperwork for ongoing depression/anxiety and sleep difficulty. Could we schedule the soonest available visit to review and complete the medical certification? Please let me know how to upload/send the forms ahead of time. Thank you.
|
||||
|
||||
### Attach/upload if available
|
||||
|
||||
- FMLA form from employer/leave administrator
|
||||
- Any deadline/date requested
|
||||
- Employer/job context: CoreWeave, Cloud Support Engineer
|
||||
- Whether requesting continuous leave, intermittent leave, or both
|
||||
|
||||
## Phone script
|
||||
|
||||
Hi, my name is Will. I’m a patient of Dr. [PCP name]. I’m calling because I need the soonest possible appointment for medical leave/FMLA paperwork. My current medical/mental health condition is preventing me from working, and the next PCP appointment I saw is late this month.
|
||||
|
||||
Could you check if there is anything sooner with:
|
||||
|
||||
- my PCP,
|
||||
- another provider on the same care team,
|
||||
- telehealth,
|
||||
- a cancellation slot,
|
||||
- or an urgent/same-day appointment?
|
||||
|
||||
The purpose is documentation for a 3-month medical leave request.
|
||||
|
||||
If there is nothing available, could you please route a message to my PCP/care team asking what I should do next to get documentation started?
|
||||
|
||||
## If they say no appointments are available
|
||||
|
||||
Ask:
|
||||
|
||||
- Can I be added to the cancellation list?
|
||||
- Can another provider in the practice complete or start FMLA paperwork?
|
||||
- Can a nurse or medical assistant send my PCP a message?
|
||||
- Is telehealth available?
|
||||
- Is same-day/urgent care appropriate for this kind of documentation?
|
||||
- Do you have behavioral health or psychiatry appointments available sooner?
|
||||
- What should I do if my employer needs documentation before the PCP appointment?
|
||||
|
||||
## If they ask what symptoms / why leave
|
||||
|
||||
Keep it simple and functional:
|
||||
|
||||
I’m dealing with depression, anxiety, and significant sleep difficulty. It is currently preventing me from being able to perform my Cloud Support Engineer job safely/effectively. I’m requesting medical leave so I can stabilize and get treatment.
|
||||
|
||||
## If they ask what documentation is needed
|
||||
|
||||
Say:
|
||||
|
||||
I’m trying to get medical documentation supporting a 3-month leave/FMLA request. I can provide any forms from my employer/benefits provider once I have them, but I need guidance on what appointment or clinician can start the process.
|
||||
|
||||
## Backup paths
|
||||
|
||||
If PCP path is blocked:
|
||||
|
||||
- [ ] Same-clinic alternate provider
|
||||
- [ ] Telehealth visit
|
||||
- [ ] Behavioral health / psychiatry appointment
|
||||
- [ ] Therapist/mental-health clinician documentation, if applicable
|
||||
- [ ] Urgent care / same-day clinic if symptoms are worsening or the timeline is urgent
|
||||
- [ ] HR/benefits request for provisional deadline extension while waiting for PCP appointment
|
||||
|
||||
## Follow-up tracker
|
||||
|
||||
| Date | Action | Result | Next step |
|
||||
| --- | --- | --- | --- |
|
||||
| Monday | Send portal message / call clinic | | |
|
||||
| Tuesday | Follow up if no response | | |
|
||||
|
||||
## Reminder to self
|
||||
|
||||
The goal is not to explain everything perfectly. The goal is to get into the medical system’s queue and ask for the correct path.
|
||||
|
||||
One message or one call is enough to move this forward.
|
||||
|
||||
## Related notes
|
||||
|
||||
- [[Health and Medical Leave]]
|
||||
- [[Will]]
|
||||
+77
@@ -0,0 +1,77 @@
|
||||
---
|
||||
tags: [atlas, personal-context, health, fmla]
|
||||
type: area
|
||||
created: 2026-05-15
|
||||
sensitive: true
|
||||
---
|
||||
|
||||
# Health and Medical Leave
|
||||
|
||||
## Current context
|
||||
|
||||
Will has shared that:
|
||||
|
||||
- He has difficulties sleeping.
|
||||
- He takes medicine every day for depression and anxiety.
|
||||
- He currently only has PCP support for medical/mental-health care.
|
||||
- He has a Zoom call with a practitioner to get medication refilled.
|
||||
- He needs to find/book a psychiatrist/shrink.
|
||||
- He needs to book a hearing check appointment.
|
||||
- He needs to book an eye appointment because he may need new glasses/lenses.
|
||||
- His current medical/mental condition prevents him from being able to do his job as a Cloud Support Engineer.
|
||||
- He is trying to set up 3 months of leave/FMLA for medical reasons.
|
||||
|
||||
## Assistant support boundaries
|
||||
|
||||
Atlas can help with:
|
||||
|
||||
- Organizing tasks and timelines
|
||||
- Drafting messages to HR, managers, doctors, or benefits providers when Will asks
|
||||
- Tracking forms, appointments, and follow-ups
|
||||
- Breaking overwhelming admin work into small steps
|
||||
- Creating reminders only after explicit approval
|
||||
|
||||
Atlas should not:
|
||||
|
||||
- Pretend to be a clinician
|
||||
- Give medical diagnosis or treatment advice
|
||||
- Send messages or handle medical/legal documents externally without explicit consent
|
||||
- Moralize, nag, or turn recovery into a productivity grind
|
||||
|
||||
## Trackers
|
||||
|
||||
- [[Medical Appointment Tracker]] — PCP/FMLA, medication refill, psychiatrist, hearing, and eye appointments
|
||||
- [[FMLA Monday Appointment Playbook]] — Monday PCP/FMLA appointment outreach
|
||||
|
||||
## FMLA / leave tracker
|
||||
|
||||
Use this section for future updates.
|
||||
|
||||
### Open questions
|
||||
|
||||
- [ ] Which employer/benefits portal or HR process is involved?
|
||||
- [ ] What forms are needed?
|
||||
- [ ] What doctor/clinician documentation is needed?
|
||||
- [ ] What deadlines exist?
|
||||
- [ ] Who needs to be notified and when?
|
||||
|
||||
### Work contacts
|
||||
|
||||
- Manager: Alex Tierney
|
||||
|
||||
### Current blocker
|
||||
|
||||
- Need a doctor appointment for medical leave/FMLA support.
|
||||
- PCP is booked until late this month.
|
||||
|
||||
### Possible next steps
|
||||
|
||||
- Call PCP clinic and ask for cancellations/waitlist, same-team provider, telehealth, or urgent appointment for leave paperwork.
|
||||
- Ask whether another clinician in the same practice can document functional impairment and complete FMLA forms.
|
||||
- Use [[FMLA Monday Appointment Playbook]] to tackle appointment outreach on Monday.
|
||||
- If symptoms are urgent or worsening, consider urgent care, crisis support, or a behavioral health appointment rather than waiting for the PCP.
|
||||
|
||||
### Timeline
|
||||
|
||||
- 2026-05-15: Will shared that he is trying to set up 3 months of leave/FMLA for medical reasons.
|
||||
- 2026-05-15: Current blocker is getting a doctor appointment; PCP is booked until late this month.
|
||||
+195
@@ -0,0 +1,195 @@
|
||||
---
|
||||
tags: [atlas, personal-context, legal, triage]
|
||||
type: legal-document-triage
|
||||
created: 2026-05-15
|
||||
updated: 2026-05-18
|
||||
sensitive: true
|
||||
status: active
|
||||
case_number: 23-3-04859-1 SEA
|
||||
source_emails:
|
||||
- id: 19ddadaf5de17f13
|
||||
date: 2026-04-29
|
||||
subject: Notice of E-Service 23-3-04859-1
|
||||
- id: 19e172a654ce0b65
|
||||
date: 2026-05-11
|
||||
subject: Notice of E-Service 23-3-04859-1
|
||||
- id: 19e289d5e0da2267
|
||||
date: 2026-05-14
|
||||
subject: Notice of E-Service 23-3-04859-1
|
||||
- id: 19e28a0d1ee89407
|
||||
date: 2026-05-14
|
||||
subject: De Souza - Order reducing arrears to a Judgment
|
||||
source_files:
|
||||
- Order on Motion to Establish Arrearage 5.14.2026.pdf
|
||||
- Proof of Service of attached Order by EMail and E-service to William Valentin.pdf
|
||||
- Certificate of E-Service.pdf
|
||||
---
|
||||
|
||||
# Legal Order - Arrearage 2026-05-14 Triage
|
||||
|
||||
This is **document triage, not legal advice**. Extracted from Gmail/e-service notices and attached PDFs so Will/Atlas can track dates, amounts, next questions, and source documents without re-opening everything from scratch.
|
||||
|
||||
## Immediate answer
|
||||
|
||||
- I found a **hearing date**: **2026-05-14**. The order says: “A hearing was held on 5/14/26.”
|
||||
- I found an **order/signed date**: **2026-05-14**, signed by **Commissioner Lindsey Goheen**.
|
||||
- I did **not** see a specific future hearing date or response/appeal/reconsideration deadline in the extracted order pages. A legal professional should verify this.
|
||||
- I did find **e-service document-access/download windows** in the King County emails. These are portal viewing windows, not necessarily legal deadlines:
|
||||
- 2026-04-29 e-service email → 15 calendar days later ≈ **2026-05-14**.
|
||||
- 2026-05-11 e-service email → 15 calendar days later ≈ **2026-05-26**.
|
||||
- 2026-05-14 e-service email → 15 calendar days later ≈ **2026-05-29**.
|
||||
|
||||
## Case / court / parties
|
||||
|
||||
- Court: **Superior Court of Washington, County of King**
|
||||
- Case number: **23-3-04859-1 SEA**
|
||||
- Petitioner: **Virna De Souza**
|
||||
- Respondent: **William Valentin**
|
||||
- Document title: **Order to Establish Arrearage and reduce past owed expenses to a Judgment and other relief (ORCN)**
|
||||
- Lawyer listed for petitioner: **Kristofer Leavitt** / Alpine Family Law
|
||||
- Respondent lawyer field: **N/A represents William Valentin**
|
||||
- Respondent signature area says: **DID NOT APPEAR**
|
||||
|
||||
## Source emails found
|
||||
|
||||
### 2026-04-29 — King County e-service notice
|
||||
|
||||
- From: `donotreplyScript@kingcounty.gov`
|
||||
- Subject: **Notice of E-Service 23-3-04859-1**
|
||||
- E-filed documents listed:
|
||||
- 190 - Note for Motion Docket
|
||||
- 191 - Motion
|
||||
- 192 - Memorandum
|
||||
- 193 - Financial Declaration
|
||||
- 194 - Sealed Financial Source Document(s)
|
||||
- 195 - Working Papers Submission List
|
||||
- null - E-Service Additional Document
|
||||
- Served by: **Melodie Allen**
|
||||
- E-service note: documents viewable via email links for **15 calendar days** after email date.
|
||||
|
||||
### 2026-05-11 — King County e-service notice
|
||||
|
||||
- From: `donotreplyScript@kingcounty.gov`
|
||||
- Subject: **Notice of E-Service 23-3-04859-1**
|
||||
- E-filed document listed:
|
||||
- 198 - Working Papers Submission List
|
||||
- Served by: **Melodie Allen**
|
||||
- E-service note: documents viewable via email links for **15 calendar days** after email date.
|
||||
|
||||
### 2026-05-14 — King County e-service notice
|
||||
|
||||
- From: `donotreplyScript@kingcounty.gov`
|
||||
- Subject: **Notice of E-Service 23-3-04859-1**
|
||||
- E-filed document listed:
|
||||
- 200 - Declaration of Mailing
|
||||
- null - E-Service Additional Document
|
||||
- Served by: **Melodie Allen**
|
||||
- E-service note: documents viewable via email links for **15 calendar days** after email date.
|
||||
|
||||
### 2026-05-14 — Melodie Allen / Alpine Family Law email
|
||||
|
||||
- From: **Melodie J. Allen <Melodie@smobrian.com>**
|
||||
- Subject: **De Souza - Order reducing arrears to a Judgment**
|
||||
- Email snippet says attached is Will’s copy of the order entered with the court that day and e-served.
|
||||
- Attachments found:
|
||||
- **Order on Motion to Establish Arrearage 5.14.2026.pdf**
|
||||
- **Proof of Service of attached Order by EMail and E-service to William Valentin.pdf**
|
||||
- **Certificate of E-Service.pdf**
|
||||
|
||||
## Money judgment summary extracted
|
||||
|
||||
Debtor: **William Valentin**
|
||||
Creditor: **Virna De Souza**
|
||||
|
||||
Listed amounts:
|
||||
|
||||
- Past due child support from **August 2025 to April 2025**: **$12,291.39**
|
||||
- Note: the date range appears odd/impossible as written in the document; verify whether the document intended April 2026 or another date.
|
||||
- Past due educational support from **February 2022 to July 2025** (Respondent 54.2%): **$15,301.92**
|
||||
- Past due medical support from **February 2022 to July 2025** (Respondent 54.2%): **$1,789.00**
|
||||
- Past due work-related daycare from **February 2022 to July 2025** (Respondent 54.2%): **$61,694.37**
|
||||
- Past due children’s expenses from **February 2022 to July 2025** (Respondent 54.2%): **$4,520.00**
|
||||
- Past due medical support from **August 2025 to March 2026** (Respondent 59.2%): **$1,748.00**
|
||||
- Past due work-related daycare from **August 2025 to March 2026** (Respondent 59.2%): **$8,450.00**
|
||||
- Past due children’s education expenses from **August 2025 to March 2026** (Respondent 59.2%): **$7,812.20**
|
||||
- Attorneys fees: **$2,500.00**
|
||||
|
||||
Extracted total of listed amounts: **$116,106.88**
|
||||
|
||||
Interest listed:
|
||||
|
||||
- Yearly interest rate for child support, medical support, and children’s expenses: **12%**
|
||||
- Other judgments: **12% unless otherwise listed**
|
||||
|
||||
## Court findings / orders extracted
|
||||
|
||||
- The court says it considered the motion, supporting documents, response/reply/other documents, and court records.
|
||||
- The order says the petitioner satisfied her burden of demonstrating the requested expenses were actually and reasonably incurred and should be reduced to judgment.
|
||||
- Lawyer fees and costs listed in the money judgment are marked as incurred and reasonable.
|
||||
- The court orders the money judgment summarized above.
|
||||
|
||||
## Payment method / enforcement language
|
||||
|
||||
Payment method ordered:
|
||||
|
||||
- Registry: send payment to **Washington State Support Registry**
|
||||
- Address: **Washington State Support Registry, PO Box 45868, Olympia, WA 98504**
|
||||
- Phone: **1-800-922-4306** or **1-800-442-5437**
|
||||
|
||||
DCS enforcement section says DCS will enforce this order because:
|
||||
|
||||
- this is a public assistance case;
|
||||
- one of the parties has already asked DCS for services;
|
||||
- one of the parties has asked for DCS services by signing the application statement at the end of this order.
|
||||
|
||||
Income withholding/garnishment section says:
|
||||
|
||||
- DCS or the person owed support can collect support owed from income, earnings, assets, or benefits of the parent who owes support.
|
||||
- DCS/person owed support can enforce liens against real or personal property as allowed by child support laws **without notice to the parent who owes support**.
|
||||
- Checked line: **“Does not apply. There is no good reason to delay income withholding.”**
|
||||
|
||||
Other handwritten order:
|
||||
|
||||
- “Petitioner shall arrange for this order to be served on respondent (e-service or service by mail).”
|
||||
|
||||
## Dates / timeline
|
||||
|
||||
- **2026-04-29**: E-service notice for motion packet / financial declaration / note for motion docket / working papers.
|
||||
- **2026-05-11**: E-service notice for working papers submission list.
|
||||
- **2026-05-14**: Hearing held.
|
||||
- **2026-05-14**: Order signed by Commissioner Lindsey Goheen.
|
||||
- **2026-05-14 15:30 PDT**: King County e-service notice for declaration of mailing / additional e-service document.
|
||||
- **2026-05-14 22:34 UTC**: Melodie Allen email with entered order and proof/certificate PDFs.
|
||||
- **2026-05-26**: Approximate end of 15-day e-service access window for 2026-05-11 notice.
|
||||
- **2026-05-29**: Approximate end of 15-day e-service access window for 2026-05-14 notice.
|
||||
|
||||
## What I did not find
|
||||
|
||||
- I did not find a new future hearing date in the order pages extracted.
|
||||
- I did not find an explicit response deadline in the order pages extracted.
|
||||
- I did not verify appeal/reconsideration/deadline rules. That requires legal review, not Atlas guessing.
|
||||
|
||||
## Minimum next actions
|
||||
|
||||
- [ ] Save/copy the May 14 order PDFs somewhere durable outside Gmail/portal.
|
||||
- [ ] If needed, save the Apr 29 and May 11 e-service documents from King County before/if still available.
|
||||
- [ ] Ask legal aid / attorney / court facilitator: “Is there any deadline to respond, appeal, request reconsideration, request revision, request modification, request payment plan, or raise inability to pay?”
|
||||
- [ ] Ask what “DID NOT APPEAR” changes now.
|
||||
- [ ] Ask what DCS enforcement/income withholding may mean in practice and whether there are steps to prevent surprise garnishment.
|
||||
- [ ] Ask whether the apparent date-range issue in the child-support line matters or can be corrected/clarified.
|
||||
|
||||
## Questions for legal help
|
||||
|
||||
- I cannot pay the full listed amount. What options exist?
|
||||
- Is there any deadline to respond, appeal, reconsider, revise, modify, or request relief?
|
||||
- What does “DID NOT APPEAR” mean for my options now?
|
||||
- What happens next with DCS enforcement and income withholding?
|
||||
- Can I request a payment plan or modification based on inability to pay and medical/FMLA situation?
|
||||
- Does the child-support date range “August 2025 to April 2025” look like a clerical error, and does that matter?
|
||||
- Are there local legal aid resources or a court facilitator who can help with this family-law support order?
|
||||
|
||||
## Related notes
|
||||
|
||||
- [[Legal]]
|
||||
- [[Legal Order Triage Playbook]]
|
||||
- [[Monday Legal Help Playbook - Arrearage Order]]
|
||||
+116
@@ -0,0 +1,116 @@
|
||||
---
|
||||
tags: [atlas, personal-context, legal, playbook]
|
||||
type: playbook
|
||||
created: 2026-05-15
|
||||
sensitive: true
|
||||
status: active
|
||||
---
|
||||
|
||||
# Legal Order Triage Playbook
|
||||
|
||||
Purpose: create a low-anxiety way to look at a new court/contempt order without getting overwhelmed.
|
||||
|
||||
This is not legal advice. This playbook is for emotional load reduction, document triage, and preparing questions for a lawyer or legal-aid resource.
|
||||
|
||||
## Current context
|
||||
|
||||
- Will is not able to pay everything the court ordered.
|
||||
- Will recently had a contempt hearing.
|
||||
- A new contempt order arrived yesterday.
|
||||
- Will has not looked at the order yet because legal-related things trigger anxiety and can trigger panic attacks.
|
||||
|
||||
## Goal
|
||||
|
||||
Extract only the minimum actionable facts:
|
||||
|
||||
1. Are there deadlines?
|
||||
2. Is there a required payment amount or payment schedule?
|
||||
3. Is there another hearing date?
|
||||
4. Are there required documents, classes, appearances, or actions?
|
||||
5. Who can help interpret this: attorney, legal aid, court facilitator, clerk, advocate?
|
||||
|
||||
## Minimum viable win
|
||||
|
||||
If energy is low, do only this:
|
||||
|
||||
- Put the unopened order somewhere visible/safe.
|
||||
- Take one photo or scan of the first page.
|
||||
- Ask Atlas or a trusted person to help extract deadlines only.
|
||||
|
||||
That counts as progress.
|
||||
|
||||
## Grounding before opening
|
||||
|
||||
Before opening or reading:
|
||||
|
||||
- [ ] Sit down somewhere safe.
|
||||
- [ ] Have water nearby.
|
||||
- [ ] Set a 10-minute timer.
|
||||
- [ ] Remind yourself: "I am only extracting dates and next actions, not solving the whole case."
|
||||
- [ ] If possible, have Roxanne or another trusted person nearby.
|
||||
|
||||
## The 10-minute triage method
|
||||
|
||||
Do not read the whole document deeply at first.
|
||||
|
||||
1. Look only for:
|
||||
- dates
|
||||
- deadlines
|
||||
- dollar amounts
|
||||
- required actions
|
||||
- hearing information
|
||||
- contact information
|
||||
2. Write those in the tracker below.
|
||||
3. Stop after 10 minutes.
|
||||
4. Decide the next support step.
|
||||
|
||||
## Tracker
|
||||
|
||||
| Item | Found? | Details |
|
||||
| --- | --- | --- |
|
||||
| Deadline | | |
|
||||
| Hearing date | | |
|
||||
| Amount ordered | | |
|
||||
| Payment schedule | | |
|
||||
| Required action | | |
|
||||
| Contact / filing info | | |
|
||||
| Consequence if missed | | |
|
||||
|
||||
## Questions to ask legal help
|
||||
|
||||
- I cannot afford the full court-ordered amount. What options exist to request modification, payment plan, or relief?
|
||||
- What exactly does the new contempt order require me to do?
|
||||
- What is the deadline to respond or comply?
|
||||
- What happens if I cannot pay by the date listed?
|
||||
- Can I file anything explaining inability to pay?
|
||||
- Are there local legal aid or court facilitator resources for this kind of matter?
|
||||
|
||||
## If panic starts
|
||||
|
||||
Pause. The document can wait 10 minutes.
|
||||
|
||||
- Put the document down.
|
||||
- Take slow breaths.
|
||||
- Name five things you can see.
|
||||
- Text or ask someone: "I opened the legal document and I'm panicking. Can you sit with me for 10 minutes?"
|
||||
- Resume only if you feel able.
|
||||
|
||||
## Assistant role
|
||||
|
||||
Atlas can help by:
|
||||
|
||||
- Extracting dates, deadlines, amounts, and required actions from text or photos Will provides.
|
||||
- Turning the order into a plain-English checklist.
|
||||
- Drafting a neutral message to an attorney/legal-aid resource.
|
||||
- Creating reminders only after Will explicitly approves them.
|
||||
|
||||
Atlas should not:
|
||||
|
||||
- Give legal advice as if it were a lawyer.
|
||||
- Contact court/attorneys/other parties without explicit consent.
|
||||
- Push Will to read more than is necessary in one sitting.
|
||||
|
||||
## Related notes
|
||||
|
||||
- [[Legal]]
|
||||
- [[Will]]
|
||||
+54
@@ -0,0 +1,54 @@
|
||||
---
|
||||
tags: [atlas, personal-context, legal]
|
||||
type: area
|
||||
created: 2026-05-15
|
||||
sensitive: true
|
||||
---
|
||||
|
||||
# Legal
|
||||
|
||||
## Current context
|
||||
|
||||
Will has shared that legal-related issues are a major stressor.
|
||||
|
||||
Current legal/admin context:
|
||||
|
||||
- Will is not able to pay everything the court ordered.
|
||||
- Will recently had a contempt hearing.
|
||||
- A new contempt order arrived yesterday.
|
||||
- Will has not looked at the order yet because legal-related things trigger anxiety and can trigger panic attacks.
|
||||
|
||||
## Assistant support boundaries
|
||||
|
||||
Atlas can help with:
|
||||
|
||||
- Organizing timelines and facts
|
||||
- Drafting neutral summaries or checklists
|
||||
- Preparing questions for an attorney or relevant professional
|
||||
- Tracking deadlines and follow-ups when Will explicitly approves reminders
|
||||
|
||||
Atlas should not:
|
||||
|
||||
- Give legal advice as if it were a lawyer
|
||||
- Contact anyone, submit documents, or take external action without explicit consent
|
||||
- Assume facts not recorded here or provided by Will
|
||||
|
||||
## Tracker
|
||||
|
||||
Use [[Legal Order Triage Playbook]] for a low-anxiety way to extract deadlines and required actions from legal orders.
|
||||
|
||||
Current triaged document: [[Legal Order - Arrearage 2026-05-14 Triage]]
|
||||
|
||||
Current action playbook: [[Monday Legal Help Playbook - Arrearage Order]]
|
||||
|
||||
### Open questions
|
||||
|
||||
- [ ] What legal matter(s) are involved?
|
||||
- [ ] Are there known deadlines?
|
||||
- [ ] Are there attorneys, courts, agencies, or other contacts involved?
|
||||
- [ ] What documents need to be collected or tracked?
|
||||
|
||||
### Timeline
|
||||
|
||||
- 2026-05-18: Updated [[Legal Order - Arrearage 2026-05-14 Triage]] with extracted Gmail/e-service data, source email dates, portal access windows, order details, amounts, and next legal-help questions.
|
||||
- 2026-05-15: Will shared that legal-related issues are a major stressor.
|
||||
+169
@@ -0,0 +1,169 @@
|
||||
---
|
||||
tags: [atlas, personal-context, health, appointments, tracker]
|
||||
type: tracker
|
||||
created: 2026-05-15
|
||||
sensitive: true
|
||||
status: active
|
||||
---
|
||||
|
||||
# Medical Appointment Tracker
|
||||
|
||||
Purpose: keep medical/admin appointments out of Will's head and make the next action obvious.
|
||||
|
||||
This is not medical advice. This is scheduling/admin tracking.
|
||||
|
||||
## Current priorities
|
||||
|
||||
1. PCP / FMLA appointment support
|
||||
2. Medication refill Zoom call
|
||||
3. Find/book psychiatrist/shrink
|
||||
4. Hearing check appointment
|
||||
5. Eye appointment for possible new glasses/lenses
|
||||
|
||||
## Minimum viable win
|
||||
|
||||
If energy is low, do just one thing:
|
||||
|
||||
- Send one portal message, make one call, or identify one phone number.
|
||||
|
||||
That counts as progress.
|
||||
|
||||
## Tracker
|
||||
|
||||
### PCP / FMLA support
|
||||
|
||||
- Status: blocked / PCP booked until late this month
|
||||
- Need: sooner appointment or alternate clinician who can support medical leave/FMLA paperwork
|
||||
- Related note: [[FMLA Monday Appointment Playbook]]
|
||||
|
||||
Next actions:
|
||||
|
||||
- [ ] Send PCP portal message using the FMLA playbook
|
||||
- [ ] Ask for cancellation list
|
||||
- [ ] Ask for same-team provider
|
||||
- [ ] Ask for telehealth
|
||||
- [ ] Ask if another clinician can start/complete FMLA documentation
|
||||
- [ ] Record appointment date/time here once scheduled
|
||||
|
||||
Appointment details:
|
||||
|
||||
- Date/time:
|
||||
- Provider:
|
||||
- Location/link:
|
||||
- Notes:
|
||||
|
||||
### Medication refill Zoom call
|
||||
|
||||
- Status: scheduled
|
||||
- Practitioner: Sammy
|
||||
- Need: refill daily depression/anxiety medication
|
||||
|
||||
Next actions:
|
||||
|
||||
- [ ] Confirm date/time of Zoom call
|
||||
- [ ] Confirm link/provider name
|
||||
- [ ] Prepare current medication list and refill needs
|
||||
- [ ] Ask about bridge refill if needed
|
||||
- [ ] Record outcome
|
||||
|
||||
Appointment details:
|
||||
|
||||
- Date/time: 2026-05-25 10:00–11:00am PT
|
||||
- Practitioner: Sammy
|
||||
- Zoom/link: invite will be sent later
|
||||
- Medications/refills needed:
|
||||
- Outcome:
|
||||
|
||||
### Psychiatrist / shrink
|
||||
|
||||
- Status: needs booking
|
||||
- Need: mental-health specialist for depression/anxiety, sleep difficulty, treatment support, and possibly leave documentation support
|
||||
|
||||
Next actions:
|
||||
|
||||
- [ ] Check insurance/provider directory
|
||||
- [ ] Ask PCP/clinic for psychiatry referral
|
||||
- [ ] Search for telehealth psychiatry options
|
||||
- [ ] Ask about earliest available appointment
|
||||
- [ ] Book intake appointment
|
||||
|
||||
Appointment details:
|
||||
|
||||
- Date/time:
|
||||
- Provider:
|
||||
- Location/link:
|
||||
- Intake requirements:
|
||||
- Notes:
|
||||
|
||||
### Hearing check
|
||||
|
||||
- Status: needs booking
|
||||
- Need: hearing test/audiology evaluation and hearing aids discussion if needed
|
||||
- Insurance to mention: UMR Choice Plus Network through CoreWeave; ask whether they also work with UnitedHealthcare Hearing benefits
|
||||
|
||||
Next actions:
|
||||
|
||||
- [x] Identify clinic/audiology options
|
||||
- [ ] Check insurance/referral requirement
|
||||
- [ ] Book appointment
|
||||
|
||||
Candidate clinics:
|
||||
|
||||
1. Clear Hearing + Audiology — close to Queen Anne/South Lake Union; phone found online: (206) 596-2099; ask if in-network with UMR/UnitedHealthcare Choice Plus and UHC Hearing.
|
||||
2. Magnolia Hearing — near Queen Anne/Magnolia/Uptown; verify UMR/UHC Hearing.
|
||||
3. UnitedHealthcare Hearing provider search — https://www.uhchearing.com/find-a-provider
|
||||
|
||||
Call script:
|
||||
|
||||
> Hi, I’d like to schedule the soonest hearing test/audiology evaluation and discuss hearing aids if needed. My insurance is UMR Choice Plus Network through CoreWeave. Are you in-network with UMR/UnitedHealthcare Choice Plus, and do you work with UnitedHealthcare Hearing benefits for hearing aids?
|
||||
|
||||
Appointment details:
|
||||
|
||||
- Date/time:
|
||||
- Provider/clinic:
|
||||
- Location/link:
|
||||
- Notes:
|
||||
|
||||
### Eye appointment / glasses-lenses
|
||||
|
||||
- Status: needs booking
|
||||
- Need: routine comprehensive eye exam for glasses and contacts
|
||||
- Vision insurance: Guardian Dental/Vision through CoreWeave; plan/group G-00032576
|
||||
|
||||
Next actions:
|
||||
|
||||
- [x] Identify optometrist/clinic
|
||||
- [ ] Check Guardian Vision coverage/contact lens evaluation coverage
|
||||
- [ ] Book eye exam
|
||||
- [ ] Bring current glasses/contacts prescription if available
|
||||
|
||||
Candidate clinics:
|
||||
|
||||
1. Eye Clinics of Seattle — Queen Anne, 20 Boston St, Seattle, WA 98109, (206) 282-8120. Ask whether they are in-network with Guardian Vision and whether contact lens exam/fitting is covered.
|
||||
2. Queen Anne Vision Clinic — 535 4th Ave W, Seattle, WA 98119, (206) 281-9100. Backup; verify Guardian Vision.
|
||||
|
||||
Call script:
|
||||
|
||||
> Hi, I’d like to schedule the soonest routine comprehensive eye exam for glasses and contacts. My vision insurance is Guardian Dental/Vision through CoreWeave, plan/group G-00032576. Are you in-network with Guardian Vision, and can you verify coverage for a contact lens exam/fitting?
|
||||
|
||||
Appointment details:
|
||||
|
||||
- Date/time:
|
||||
- Provider/clinic:
|
||||
- Location/link:
|
||||
- Notes:
|
||||
|
||||
## Weekly review
|
||||
|
||||
Use this once or twice per week, not every day unless needed.
|
||||
|
||||
- [ ] What is the single most urgent appointment/admin item?
|
||||
- [ ] What is blocked?
|
||||
- [ ] What can Atlas draft or organize?
|
||||
- [ ] What reminder, if any, should be created with Will's approval?
|
||||
|
||||
## Related notes
|
||||
|
||||
- [[Health and Medical Leave]]
|
||||
- [[FMLA Monday Appointment Playbook]]
|
||||
- [[Will]]
|
||||
+152
@@ -0,0 +1,152 @@
|
||||
---
|
||||
tags: [atlas, personal-context, legal, playbook]
|
||||
type: playbook
|
||||
created: 2026-05-15
|
||||
sensitive: true
|
||||
status: active
|
||||
related_case: 23-3-04859-1 SEA
|
||||
---
|
||||
|
||||
# Monday Legal Help Playbook - Arrearage Order
|
||||
|
||||
Purpose: make it easier to ask for legal help about the May 14, 2026 arrearage/judgment order without having to reread or emotionally process the whole document.
|
||||
|
||||
This is not legal advice. This is an action script and triage checklist.
|
||||
|
||||
## Current situation
|
||||
|
||||
- Court: King County Superior Court
|
||||
- Case: 23-3-04859-1 SEA
|
||||
- Main order: Order to Establish Arrearage and reduce past owed expenses to a Judgment and other relief
|
||||
- Order signed: 2026-05-14
|
||||
- Served by email/e-service: 2026-05-14 at 3:31 p.m.
|
||||
- Order says respondent: DID NOT APPEAR
|
||||
- Extracted total listed amount: $116,106.88
|
||||
- Interest listed: 12% yearly
|
||||
- Will is not able to pay the full ordered amount
|
||||
|
||||
Detailed triage note: [[Legal Order - Arrearage 2026-05-14 Triage]]
|
||||
|
||||
## Monday goal
|
||||
|
||||
Get one of these outcomes:
|
||||
|
||||
1. Confirm whether there is any deadline to respond, appeal, request reconsideration, request modification, request relief, or address inability to pay.
|
||||
2. Find a legal professional, legal-aid resource, or court facilitator who can explain options.
|
||||
3. Understand immediate practical risk: DCS enforcement, income withholding, garnishment, payment plan, or other collection actions.
|
||||
4. Identify the next concrete step and date.
|
||||
|
||||
## Minimum viable win
|
||||
|
||||
If energy is low, do only this:
|
||||
|
||||
- Send the short email/message below to one legal-help contact.
|
||||
- Attach or offer the PDF order.
|
||||
- Set one follow-up reminder.
|
||||
|
||||
That counts as progress.
|
||||
|
||||
## What to gather first
|
||||
|
||||
Do not let this block action. If something is missing, send anyway.
|
||||
|
||||
- [ ] PDF order
|
||||
- [ ] Proof/certificate of service PDFs
|
||||
- [ ] Case number: 23-3-04859-1 SEA
|
||||
- [ ] Date signed: 2026-05-14
|
||||
- [ ] Date served: 2026-05-14
|
||||
- [ ] Any hearing notice or prior contempt paperwork
|
||||
- [ ] Any income/expense info showing inability to pay
|
||||
- [ ] Current medical/FMLA situation summary, if relevant
|
||||
|
||||
## Short message to lawyer / legal aid / court facilitator
|
||||
|
||||
Subject: Need urgent guidance on King County arrearage/contempt order - case 23-3-04859-1 SEA
|
||||
|
||||
Hi,
|
||||
|
||||
I received an Order to Establish Arrearage and reduce past owed expenses to a Judgment in King County Superior Court case 23-3-04859-1 SEA, signed May 14, 2026 and served by email/e-service the same day.
|
||||
|
||||
The order says respondent “DID NOT APPEAR.” The listed judgment appears to total about $116,106.88 plus 12% interest. I am not able to pay the full amount.
|
||||
|
||||
I need help understanding:
|
||||
|
||||
- whether there is any deadline to respond, appeal, request reconsideration, request modification, request relief, or explain inability to pay;
|
||||
- what DCS enforcement/income withholding may mean;
|
||||
- whether a payment plan, modification, or other relief is possible;
|
||||
- what my next step should be.
|
||||
|
||||
Can someone review the order and tell me what options or deadlines I need to know about?
|
||||
|
||||
Thank you,
|
||||
Will
|
||||
|
||||
## Phone script
|
||||
|
||||
Hi, my name is Will. I’m calling because I received a King County Superior Court order in a family-law/support case and I need help understanding deadlines and options.
|
||||
|
||||
The case number is 23-3-04859-1 SEA. The order was signed May 14, 2026. It establishes arrearage and reduces past owed expenses to a judgment. The total appears to be about $116,106.88 plus interest, and I cannot pay the full amount.
|
||||
|
||||
I need to know if there is any deadline to respond, appeal, ask for reconsideration, request modification, request a payment plan, or explain inability to pay. I also need to understand what DCS enforcement or income withholding could mean.
|
||||
|
||||
Can you help me, or point me to the right resource?
|
||||
|
||||
## If they ask what you need help with
|
||||
|
||||
Say:
|
||||
|
||||
I need document review and next-step guidance. I’m not asking anyone to solve the whole case today. I need to identify deadlines, risk, and options because I cannot pay the full ordered amount.
|
||||
|
||||
## If they say they cannot help
|
||||
|
||||
Ask:
|
||||
|
||||
- Do you know who can help with King County family-law support/judgment orders?
|
||||
- Is there a court facilitator or family law help desk?
|
||||
- Is there a legal aid organization that handles child support/contempt/arrearage issues?
|
||||
- Is there a way to request reconsideration, modification, payment plan, or relief due to inability to pay?
|
||||
- Who can tell me whether a deadline is running?
|
||||
|
||||
## Places/categories to contact
|
||||
|
||||
Fill in exact contacts as found.
|
||||
|
||||
- [ ] Current or prior attorney, if any
|
||||
- [ ] King County family law facilitator / courthouse help desk
|
||||
- [ ] Washington legal aid / family law self-help resource
|
||||
- [ ] DCS / Washington State Support Registry for enforcement/payment-process questions
|
||||
- [ ] Court clerk for procedural questions only, not legal advice
|
||||
- [ ] Trusted support person to sit with Will while making calls/messages
|
||||
|
||||
## Questions to ask
|
||||
|
||||
- Is there a deadline to respond, appeal, reconsider, modify, or request relief?
|
||||
- What does “DID NOT APPEAR” mean for my options now?
|
||||
- What happens next after this order is entered and served?
|
||||
- What does DCS enforcement mean in practice?
|
||||
- Can I request a payment plan?
|
||||
- Can I request modification or relief based on inability to pay?
|
||||
- Can current medical/FMLA/mental-health situation matter for enforcement or payment ability?
|
||||
- What documents should I gather?
|
||||
- What should I avoid doing or missing this week?
|
||||
|
||||
## Call/message tracker
|
||||
|
||||
| Date | Contact | Method | Result | Next step |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| Monday | | | | |
|
||||
| Tuesday | | | | |
|
||||
|
||||
## Anxiety-safe rules
|
||||
|
||||
- Only one call/message at a time.
|
||||
- You do not have to reread the whole order.
|
||||
- Use the script verbatim if needed.
|
||||
- Stop after 15 minutes if panic rises.
|
||||
- The goal is to find the next door, not solve the entire legal problem.
|
||||
|
||||
## Related notes
|
||||
|
||||
- [[Legal]]
|
||||
- [[Legal Order - Arrearage 2026-05-14 Triage]]
|
||||
- [[Legal Order Triage Playbook]]
|
||||
+160
@@ -0,0 +1,160 @@
|
||||
---
|
||||
tags: [atlas, personal-context, finances, taxes, playbook]
|
||||
type: playbook
|
||||
created: 2026-05-19
|
||||
sensitive: true
|
||||
status: active
|
||||
---
|
||||
|
||||
# Tax Catch-up Playbook
|
||||
|
||||
Purpose: make late taxes less overwhelming by turning them into a small document-gathering workflow.
|
||||
|
||||
This is tax admin support, not tax/legal advice. For filing choices, penalties, or unusual tax situations, use a tax professional or IRS/state guidance.
|
||||
|
||||
## Current context
|
||||
|
||||
- Will is late doing taxes and needs to get unstuck.
|
||||
- Gmail search is working again through Atlas/Google Workspace.
|
||||
- Initial Gmail scan found likely 2025 tax documents and related notifications.
|
||||
|
||||
## Minimum viable win
|
||||
|
||||
If energy is low, do only this:
|
||||
|
||||
- [ ] Open/download the **CoreWeave W-2** email attachment.
|
||||
- [ ] Put it in a folder named `2025 Taxes`.
|
||||
|
||||
That counts as progress.
|
||||
|
||||
## Found in Gmail
|
||||
|
||||
### CoreWeave / W-2
|
||||
|
||||
Email found:
|
||||
|
||||
- From: William's CoreWeave email
|
||||
- Subject: `W2`
|
||||
- Date: 2026-01-23
|
||||
- Attachments:
|
||||
- `William_Valentin_2025_W2.pdf`
|
||||
- `William_Valentin_2025_Tip_and_Other_Compensation_Report.pdf`
|
||||
- `William Valentin_paystubs.zip`
|
||||
|
||||
Use these as the primary employment-income documents.
|
||||
|
||||
### E*TRADE / Morgan Stanley 1099
|
||||
|
||||
Email found:
|
||||
|
||||
- From: E*TRADE from Morgan Stanley
|
||||
- Subject: `IMPORTANT TAX RETURN DOCUMENT AVAILABLE`
|
||||
- Date: 2026-02-06
|
||||
- Mentions: `2025 FORM 1099 STOCK PLAN CONSOLIDATED ORIGINAL and Stock Plan Transactions Supplement`
|
||||
|
||||
Likely next step: log into E*TRADE/Morgan Stanley and download the 2025 1099 PDF and stock-plan transaction supplement. The Gmail notification did **not** include the actual PDF as an attachment.
|
||||
|
||||
### Pay stubs / pay docs
|
||||
|
||||
Additional CoreWeave/self-forwarded pay-doc emails found:
|
||||
|
||||
- `stubs` — 2026-02-19
|
||||
- `pay docs` — 2026-01-21
|
||||
- `Payslip_to_Print...` — 2026-01-21
|
||||
- older pay-stub archives from 2025
|
||||
|
||||
Usually backup only if the W-2 is unclear or a tax preparer asks.
|
||||
|
||||
### Not clearly found yet
|
||||
|
||||
- 1095 health coverage tax form
|
||||
- Chase/Amex bank-interest tax forms
|
||||
- Attached E*TRADE 1099 PDF
|
||||
|
||||
## Tax document checklist
|
||||
|
||||
### Definitely gather
|
||||
|
||||
- [ ] CoreWeave 2025 W-2 PDF
|
||||
- [ ] CoreWeave tip/other compensation report PDF
|
||||
- [ ] E*TRADE/Morgan Stanley 2025 Form 1099 Stock Plan Consolidated PDF
|
||||
- [ ] E*TRADE/Morgan Stanley Stock Plan Transactions Supplement
|
||||
- [ ] Prior-year tax return, if available
|
||||
|
||||
### Check if applicable
|
||||
|
||||
- [ ] Bank interest forms: 1099-INT
|
||||
- [ ] Investment dividend/capital gains forms: 1099-DIV / 1099-B
|
||||
- [ ] Mortgage/student loan forms: 1098
|
||||
- [ ] Health coverage forms: 1095-A/B/C if received
|
||||
- [ ] Child/dependent info if claiming dependents
|
||||
- [ ] Donation receipts or other deductions if meaningful
|
||||
|
||||
## Gmail search queries
|
||||
|
||||
Use these if Atlas needs to search again:
|
||||
|
||||
```text
|
||||
from:(coreweave.com OR wvalentin@coreweave.com) (W2 OR "W-2" OR tax OR 1095 OR payroll OR pay OR stubs OR docs) newer_than:18m
|
||||
```
|
||||
|
||||
```text
|
||||
from:(etradefrommorganstanley.com OR etrade.com) (1099 OR tax OR "tax return document") newer_than:18m
|
||||
```
|
||||
|
||||
```text
|
||||
(subject:"W-2" OR subject:W2 OR subject:1099 OR subject:1095 OR subject:"tax document" OR subject:"tax forms") newer_than:18m -category:promotions
|
||||
```
|
||||
|
||||
```text
|
||||
(1095 OR "health coverage" OR "minimum essential coverage" OR UMR OR Guardian) newer_than:18m -category:promotions
|
||||
```
|
||||
|
||||
```text
|
||||
(1099-INT OR 1099-DIV OR 1099-B OR "tax statement" OR "tax form" OR "tax document") newer_than:18m -category:promotions
|
||||
```
|
||||
|
||||
## Automation
|
||||
|
||||
- Active n8n workflow: `Personal Reminder Router (Atlas + Local LLM)`
|
||||
- Workflow ID: `PersonalReminderRouter001`
|
||||
- Schedule: weekdays at 9:00 AM PT
|
||||
- Delivery: n8n → local LLM on `llama.cpp :18806` for short reminder wording → Atlas/Hermes webhook `personal-reminder-atlas` → Telegram
|
||||
- Current reminder: tax catch-up / CoreWeave W-2 minimum viable win
|
||||
- Hermes one-shot tax reminder was removed after n8n delivery was verified, to avoid duplicate reminders.
|
||||
|
||||
## Next actions
|
||||
|
||||
1. [ ] Create a local or Drive folder: `2025 Taxes`.
|
||||
2. [ ] Download CoreWeave W-2 attachments from Gmail.
|
||||
3. [ ] Log into E*TRADE/Morgan Stanley and download 2025 1099 + transaction supplement.
|
||||
4. [ ] Search for bank/investment/health tax forms again if needed.
|
||||
5. [ ] Choose filing path:
|
||||
- FreeTaxUSA / TurboTax / H&R Block software
|
||||
- tax preparer / enrolled agent / CPA
|
||||
6. [ ] File even if payment has to be handled separately.
|
||||
|
||||
## Low-stress filing path
|
||||
|
||||
If overwhelmed:
|
||||
|
||||
- Use FreeTaxUSA or a tax preparer.
|
||||
- Do not try to optimize every deduction first.
|
||||
- Get the main income documents in one place.
|
||||
- Filing late is usually more urgent than perfect optimization.
|
||||
|
||||
## Message to a tax preparer
|
||||
|
||||
Subject: Late tax filing help
|
||||
|
||||
Hi,
|
||||
|
||||
I’m late filing my 2025 taxes and need help getting caught up as soon as possible. I’m a W-2 employee and also have an E*TRADE/Morgan Stanley stock-plan 1099. Are you accepting new clients, and what documents should I send to get started?
|
||||
|
||||
Thank you,
|
||||
William Valentin
|
||||
|
||||
## Related notes
|
||||
|
||||
- [[Will]]
|
||||
- [[Health and Medical Leave]]
|
||||
+32
@@ -0,0 +1,32 @@
|
||||
---
|
||||
tags: [atlas, personal-context, family]
|
||||
type: family-context
|
||||
created: 2026-05-15
|
||||
---
|
||||
|
||||
# Family in France
|
||||
|
||||
## Betty
|
||||
|
||||
- Relationship: Will's mom
|
||||
- Birth date: 1948-11-10
|
||||
- Lives in France in the same little town as Will's sister Delphyne
|
||||
|
||||
## Delphyne
|
||||
|
||||
- Relationship: Will's sister
|
||||
- Birth date: 1976-04-09
|
||||
- Born in France
|
||||
- Lives in France in the same little town as Will's mom Betty
|
||||
- Daughter: Mathylde
|
||||
- Mathylde's dad: Christophe
|
||||
|
||||
## Jean-Jacques
|
||||
|
||||
- Relationship: Will's dad
|
||||
- Birth date: 1953-05-23
|
||||
- Lives in France, in the Bretagne region
|
||||
|
||||
## Notes for Atlas
|
||||
|
||||
Will is French and has family roots and close family context in France. Use French language/cultural context when helpful, but do not assume emotional closeness or current contact frequency without asking.
|
||||
+15
@@ -0,0 +1,15 @@
|
||||
---
|
||||
tags: [atlas, personal-context, person, family]
|
||||
type: person
|
||||
created: 2026-05-15
|
||||
---
|
||||
|
||||
# Liam
|
||||
|
||||
- Relationship: Will's child
|
||||
- Birth date: 2016-07-17
|
||||
- Lives with his mother in Redmond, WA
|
||||
|
||||
## Notes for Atlas
|
||||
|
||||
Liam is one of Will's two children. Will has said he currently does not get to see his kids. Treat family/child-related context as sensitive and supportive.
|
||||
+15
@@ -0,0 +1,15 @@
|
||||
---
|
||||
tags: [atlas, personal-context, person, family]
|
||||
type: person
|
||||
created: 2026-05-15
|
||||
---
|
||||
|
||||
# Mila
|
||||
|
||||
- Relationship: Will's child
|
||||
- Birth date: 2020-05-28
|
||||
- Lives with her mother in Redmond, WA
|
||||
|
||||
## Notes for Atlas
|
||||
|
||||
Mila is one of Will's two children. Will has said he currently does not get to see his kids. Treat family/child-related context as sensitive and supportive.
|
||||
+20
@@ -0,0 +1,20 @@
|
||||
---
|
||||
tags: [atlas, personal-context, person]
|
||||
type: person
|
||||
created: 2026-05-15
|
||||
---
|
||||
|
||||
# Roxanne
|
||||
|
||||
- Relationship: Will's partner/girlfriend
|
||||
- Birth date: 1998-05-23
|
||||
- Born in: Seattle, WA
|
||||
- Lives with Will
|
||||
- Roxanne supports Will as much as she can
|
||||
- Will has no stated boundaries around discussing Roxanne with Atlas
|
||||
- Will usually wakes around 7:30–8:00am because that is Roxanne's wake-up time
|
||||
- Shared activities Will enjoys: being outside and walking miles together
|
||||
|
||||
## Notes for Atlas
|
||||
|
||||
Roxanne is an important person in Will's daily life and routines. Be respectful and do not assume permission to contact, message, or involve her unless Will asks.
|
||||
+41
@@ -0,0 +1,41 @@
|
||||
---
|
||||
tags: [atlas, personal-context, project]
|
||||
type: project
|
||||
created: 2026-05-15
|
||||
---
|
||||
|
||||
# Hermes Atlas Personal Assistant
|
||||
|
||||
## Purpose
|
||||
|
||||
Atlas is Will's primary Hermes-based personal assistant. The goal is to reduce cognitive load and help Will act on important personal, technical, and administrative work.
|
||||
|
||||
## Preferred style
|
||||
|
||||
Will chose **structured proactive** assistance.
|
||||
|
||||
This means Atlas should:
|
||||
|
||||
- Suggest concrete next steps when they reduce cognitive load
|
||||
- Help maintain routines and reminders only when explicitly approved
|
||||
- Be supportive and practical without nagging
|
||||
- Ask before creating recurring systems
|
||||
- Ask before sending messages or taking external actions
|
||||
- Ask before handling sensitive personal/legal/medical documents
|
||||
|
||||
## Memory architecture
|
||||
|
||||
- Hermes `user` memory: tiny always-on operating context
|
||||
- Obsidian: durable personal/project knowledge base
|
||||
- RAG/vector search: semantic retrieval over Obsidian/docs when context is needed
|
||||
- Session search: recall prior conversations when Will says “we talked about…” or similar
|
||||
|
||||
## Important areas to search before helping
|
||||
|
||||
- [[Will]]
|
||||
- [[Areas/Health and Medical Leave]]
|
||||
- [[Areas/Legal]]
|
||||
- [[People/Roxanne]]
|
||||
- [[People/Liam]]
|
||||
- [[People/Mila]]
|
||||
- [[People/Family in France]]
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
tags: [atlas, personal-context]
|
||||
created: 2026-05-15
|
||||
---
|
||||
|
||||
# Atlas Personal Context
|
||||
|
||||
This folder is the durable, human-readable personal context layer for Atlas.
|
||||
|
||||
Use this instead of overloading Hermes' small always-injected memory. Hermes memory should keep only compact pointers and behavior preferences; richer personal details live here and can be retrieved via Obsidian/RAG when relevant.
|
||||
|
||||
## Core notes
|
||||
|
||||
- [[Will]] — identity, location, languages, work, routines, stressors, preferences
|
||||
- [[People/Roxanne]] — partner context
|
||||
- [[People/Liam]] — child context
|
||||
- [[People/Mila]] — child context
|
||||
- [[People/Family in France]] — parents and sister
|
||||
- [[Areas/Health and Medical Leave]] — health context and FMLA/leave tracker
|
||||
- [[Areas/Legal]] — legal/admin context and tracker
|
||||
- [[Projects/Hermes Atlas Personal Assistant]] — how Will wants Atlas to operate
|
||||
|
||||
## Operating rule for Atlas
|
||||
|
||||
When personal, family, legal, medical, or project context matters, search this folder and related Obsidian notes before relying only on short Hermes memory.
|
||||
|
||||
Sensitive areas — legal, medical, family — require consent before external actions, recurring reminders, or document handling.
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
tags: [atlas, personal-context, person]
|
||||
type: person
|
||||
created: 2026-05-15
|
||||
---
|
||||
|
||||
# Will
|
||||
|
||||
## Identity
|
||||
|
||||
- Name: Will
|
||||
- Birth date: 1979-07-25
|
||||
- Born in: France
|
||||
- Nationality/culture: French
|
||||
- Race/ethnicity: Caucasian
|
||||
- Current location: Lower Queen Anne, Seattle, WA 98119
|
||||
- Languages: French and English mainly; some Portuguese and Spanish
|
||||
|
||||
## Household and family
|
||||
|
||||
- Partner/girlfriend: [[People/Roxanne]]
|
||||
- Children: [[People/Liam]] and [[People/Mila]]
|
||||
- Family in France: [[People/Family in France]]
|
||||
|
||||
## Work
|
||||
|
||||
- Role: Cloud Support Engineer at CoreWeave
|
||||
- Manager: Alex Tierney
|
||||
- Work pattern: remote, worked remotely for almost 3 years
|
||||
- Normal shift: Monday–Friday, 2pm–11pm
|
||||
- Domain: GPU infrastructure, Kubernetes, Slurm, customer support for engineers
|
||||
|
||||
## Current context
|
||||
|
||||
- Current major stressors: legal-related issues, sleep difficulty, depression/anxiety, medical leave/FMLA setup
|
||||
- Current medical/mental condition prevents him from doing his Cloud Support Engineer job
|
||||
- Current goal: set up 3 months of leave/FMLA for medical reasons
|
||||
|
||||
## Daily rhythm
|
||||
|
||||
- Wakes around 7:30–8:00am because that is Roxanne's wake-up time
|
||||
- Usually goes to bed around 1:00am
|
||||
- Mornings are often for Hermes/Atlas, dev projects, and/or a nap
|
||||
- Work shift, when working: 2pm–11pm
|
||||
|
||||
## Health/admin to track
|
||||
|
||||
- Currently only has PCP for mental-health/medical support
|
||||
- Has a Zoom call with Sammy, a practitioner, to get medication refilled
|
||||
- Needs to get a psychiatrist/shrink
|
||||
- Needs to book a hearing check appointment
|
||||
- Needs to book an eye appointment because he may need new glasses/lenses
|
||||
|
||||
## Interests
|
||||
|
||||
- Guitar
|
||||
- Coding
|
||||
- YouTube: woodworking, space, science, tech, dev, guitar building
|
||||
- Music: metal, Metallica, hard rock, rock, 80s, 90s, Caravan Palace
|
||||
- Going outside and walking miles with Roxanne
|
||||
|
||||
## Projects
|
||||
|
||||
- Atlas/Hermes is Will's most important current project
|
||||
- Will expects Atlas and him to work together on ongoing dev projects
|
||||
|
||||
## Assistant preferences
|
||||
|
||||
- Preferred assistant name: Atlas
|
||||
- Preferred assistance style: structured proactive — reduce cognitive load, suggest next steps, maintain explicitly approved routines/reminders
|
||||
- When things are hard, Will prefers a mix of gentle/reassuring, direct/practical, and tiny-next-step support
|
||||
- Communication: concise by default
|
||||
- Tone: humor is welcome when appropriate; stay calm/grounded when serious
|
||||
- Language preference: match Will's language
|
||||
- Will wants Atlas to challenge him gently when avoidance is blocking something important
|
||||
- Consent boundaries: ask before recurring systems, external actions, or sensitive personal/legal/medical document handling
|
||||
+171
@@ -0,0 +1,171 @@
|
||||
# Obsidian Cleanup Audit — 2026-05-19
|
||||
|
||||
Vault: `/home/will/lab/swarm/swarm-common/obsidian-vault/will/will-shared-zap`
|
||||
|
||||
## Executive summary
|
||||
|
||||
The vault is small and mostly healthy: **136 Markdown notes**. The main cleanup problem is not deep rot; it is automation/test smoke left behind and a few placeholder/stub notes.
|
||||
|
||||
Highest-confidence cleanup candidates: **18 notes** are empty, `{}` stubs, disposable test notes, or obvious example/smoke artifacts.
|
||||
|
||||
Second priority: link hygiene. I found **48 unresolved wikilinks/relative links** after resolving normal Obsidian basename and path links. Many are template placeholders and harmless, but some indicate missing index/person/area notes or stale architecture references.
|
||||
|
||||
## Folder distribution
|
||||
|
||||
| Folder | Notes |
|
||||
|---|---:|
|
||||
| Notes | 24 |
|
||||
| Templates | 19 |
|
||||
| Atlas | 16 |
|
||||
| Projects | 13 |
|
||||
| Infrastructure | 12 |
|
||||
| Inbox | 8 |
|
||||
| Daily | 7 |
|
||||
| Voice Memos | 6 |
|
||||
| root | 5 |
|
||||
| Resources | 5 |
|
||||
| Diary | 5 |
|
||||
| Runbooks | 4 |
|
||||
| Hermes Disposable Tests | 4 |
|
||||
| Decisions | 2 |
|
||||
| Plans / Clippings / Areas / People / Meetings / Archive | 1 each |
|
||||
|
||||
## Safe delete candidates
|
||||
|
||||
These look safe to remove or archive as test debris. I did **not** delete them.
|
||||
|
||||
### Empty notes
|
||||
|
||||
- `2026-04-16.md`
|
||||
- `Systems.md`
|
||||
- `Voice Memos/2026-05-13-e2e-test-full-pipeline.md`
|
||||
- `Voice Memos/2026-05-13-e2e-test-fixed-auth.md`
|
||||
- `Voice Memos/2026-05-13-e2e-test-retry-auth.md`
|
||||
- `Voice Memos/2026-05-13-e2e-auth-fixed.md`
|
||||
- `Voice Memos/2026-05-13-final-e2e-test.md`
|
||||
|
||||
### `{}` stub notes
|
||||
|
||||
- `Notes/2026-05-13 Evening Digest.md`
|
||||
- `Notes/2026-05-14 Evening Digest.md`
|
||||
- `Notes/2026-05-15 Evening Digest.md`
|
||||
- `Notes/2026-05-17 Evening Digest.md`
|
||||
|
||||
These four are also duplicate content.
|
||||
|
||||
### Disposable/smoke artifacts
|
||||
|
||||
- `Clippings/2026-05-13-example-domain.md`
|
||||
- `Hermes Disposable Tests/append-note-created-by-append-20260515-101031.md`
|
||||
- `Hermes Disposable Tests/append-note-fixed-20260515-101031.md`
|
||||
- `Hermes Disposable Tests/append-note-semantics-20260515-100757.md`
|
||||
- `Hermes Disposable Tests/raw-append-op-20260515-100823.md`
|
||||
- `Voice Memos/2026-05-13-final-pipeline-test.md`
|
||||
|
||||
### Needs review before delete
|
||||
|
||||
- `Templates/Atlas Artifacts/test-report.md` — flagged because it has “test” in the title/content, but it may be an intentional reusable template. Keep unless the Atlas artifact-template set is being simplified.
|
||||
|
||||
## Notes that “don’t make sense” structurally
|
||||
|
||||
### Automation digest clutter
|
||||
|
||||
There are many one-off nightly vault sync notes under `Notes/`:
|
||||
|
||||
- `Notes/2026-03-27 Nightly Vault Sync.md`
|
||||
- `Notes/2026-03-31 Nightly Vault Sync.md`
|
||||
- `Notes/2026-04-17 Nightly Vault Sync.md`
|
||||
- `Notes/2026-04-19 Nightly Vault Sync.md`
|
||||
- `Notes/2026-04-21 Nightly Vault Sync.md`
|
||||
- `Notes/2026-04-22 Nightly Vault Sync.md`
|
||||
- `Notes/2026-04-23 Nightly Vault Sync.md`
|
||||
- `Notes/2026-04-28 Nightly Vault Sync.md`
|
||||
- `Notes/2026-04-29 Nightly Vault Sync.md`
|
||||
- `Notes/2026-05-01 Nightly Vault Sync.md`
|
||||
- `Notes/2026-05-03 Nightly Vault Sync.md`
|
||||
- `Notes/2026-05-04 Nightly Vault Sync.md`
|
||||
- `Notes/2026-05-08 Nightly Vault Sync.md`
|
||||
- `Notes/2026-05-10 Nightly Vault Sync.md`
|
||||
- `Notes/2026-05-11 Nightly Vault Sync.md`
|
||||
|
||||
Recommendation: keep `Infrastructure/Automation/n8n Nightly Vault Sync.md` as the canonical runbook/status note, then either archive the daily sync notes under `Archive/Automation Logs/` or summarize them into one changelog and delete the raw day-by-day noise.
|
||||
|
||||
### Root-level notes
|
||||
|
||||
Root contains:
|
||||
|
||||
- `Conventions.md`
|
||||
- `2026-04-16.md` — empty; delete
|
||||
- `Weekend Activity Ideas.md`
|
||||
- `Ops Home.md`
|
||||
- `Systems.md` — empty; delete or replace with a real systems index
|
||||
|
||||
Recommendation: root should probably contain only `Ops Home.md`, `Conventions.md`, and maybe a few true entrypoints. Move `Weekend Activity Ideas.md` into `Resources/` or `Areas/Home/` if keeping it.
|
||||
|
||||
## Link hygiene findings
|
||||
|
||||
Unresolved links after normal Obsidian resolution: **48**.
|
||||
|
||||
Likely harmless/template placeholders:
|
||||
|
||||
- `{{project}}` — 7 instances in `Templates/Atlas Artifacts/*`
|
||||
- `artifact-name` — 1 instance
|
||||
- `Note A`, `Note B`, `wikilinks`, `url` in `Conventions.md` examples
|
||||
|
||||
Likely real missing or stale notes:
|
||||
|
||||
- `Infrastructure/Automation/n8n Morning Brief`
|
||||
- `Infrastructure/Automation/n8n Evening Digest`
|
||||
- `Atlas/Safer Autonomy and Permission Tiers`
|
||||
- `Atlas/Gateway Approval Runbook`
|
||||
- `Atlas/Skill Inventory`
|
||||
- `Atlas/Skill Backlog`
|
||||
- `Vault Conventions` — appears to mean `Conventions.md`
|
||||
- `Areas/Health and Medical Leave`, `Areas/Legal` — notes exist under `Atlas/Personal Context/Areas/...`, not root `Areas/...`
|
||||
- `People/Roxanne`, `People/Liam`, `People/Mila`, `People/Family in France` — notes exist under `Atlas/Personal Context/People/...`, not root `People/...`
|
||||
- `Diary/Entries`, `Diary/Weekly Reviews`, `Diary/Atlas Reflections` — folder-style links; create index notes or change to plain text/folder references
|
||||
- `Inbox/Inbox Home` — missing, but likely intended
|
||||
|
||||
Recommendation: fix links by either creating small index notes or retargeting links to existing paths. Do this after deleting test debris so the graph is cleaner.
|
||||
|
||||
## Orphan candidates
|
||||
|
||||
These have no incoming or outgoing links by the scan. Some are intentionally standalone daily/research artifacts; others are clutter.
|
||||
|
||||
Most suspicious orphans:
|
||||
|
||||
- `2026-04-16.md`
|
||||
- `Notes/2026-05-13 Evening Digest.md`
|
||||
- `Notes/2026-05-14 Evening Digest.md`
|
||||
- `Notes/2026-05-15 Evening Digest.md`
|
||||
- `Notes/2026-05-17 Evening Digest.md`
|
||||
- `Clippings/2026-05-13-example-domain.md`
|
||||
- `Voice Memos/2026-05-13-*test*.md`
|
||||
- `Hermes Disposable Tests/*.md`
|
||||
- `Inbox/Chat Summaries/2026-05-14 - Atlas Event-Driven Automation Smoke.md`
|
||||
|
||||
Probably okay but should be linked from an index:
|
||||
|
||||
- `Weekend Activity Ideas.md`
|
||||
- `Projects/Atlas/Skill Inventory.md`
|
||||
- `Projects/Atlas/Skill Backlog.md`
|
||||
- `Decisions/Runbook Suggestions.md`
|
||||
- `Atlas/Daily Research/2026-05-18 - Hermes AI Brief.md`
|
||||
- `Atlas/Daily Research/2026-05-19 - Hermes AI Brief.md`
|
||||
- `Atlas/Personal Context/People/*.md`
|
||||
|
||||
## Recommended cleanup order
|
||||
|
||||
1. Delete or archive the 17 obvious disposable/empty/stub notes. Keep `Templates/Atlas Artifacts/test-report.md` unless you want to simplify templates.
|
||||
2. Decide what to do with nightly sync notes: archive them as automation logs or compress to a single changelog.
|
||||
3. Fix `Vault Conventions` links to `Conventions`.
|
||||
4. Retarget personal-context links from root `People/...` and `Areas/...` to `Atlas/Personal Context/People/...` and `Atlas/Personal Context/Areas/...`, or create redirect/index notes in root `People/` and `Areas/`.
|
||||
5. Create missing index notes if desired: `Inbox/Inbox Home.md`, `Diary/Entries.md`, `Diary/Weekly Reviews.md`, `Diary/Atlas Reflections.md`.
|
||||
6. Decide whether root `Systems.md` should become a real `Infrastructure/Systems.md`-style index; otherwise delete it.
|
||||
|
||||
## Suggested cleanup policy going forward
|
||||
|
||||
- Smoke tests should write to `Hermes Disposable Tests/` and a cleanup job should purge files older than 7 days.
|
||||
- Automation status should update canonical notes/runbooks, not create a new note per day unless the daily artifact is meant to be human-read.
|
||||
- Generated notes should be linked from a home/index note immediately, or tagged `#generated/unlinked` for later triage.
|
||||
- Empty notes and `{}` notes should be treated as failed pipeline output and alerted/deleted.
|
||||
+76
@@ -0,0 +1,76 @@
|
||||
# Obsidian Cleanup Completed — 2026-05-19
|
||||
|
||||
Vault: `/home/will/lab/swarm/swarm-common/obsidian-vault/will/will-shared-zap`
|
||||
|
||||
## What changed
|
||||
|
||||
Deleted **17** high-confidence disposable/stub notes from the live vault:
|
||||
|
||||
- Empty root notes: `2026-04-16.md`, `Systems.md`
|
||||
- Empty voice-memo/e2e test notes under `Voice Memos/`
|
||||
- `{}` Evening Digest stubs under `Notes/`
|
||||
- `Clippings/2026-05-13-example-domain.md`
|
||||
- Disposable append-test notes under `Hermes Disposable Tests/`
|
||||
- `Voice Memos/2026-05-13-final-pipeline-test.md`
|
||||
|
||||
A backup of the removed files was moved outside the vault so Obsidian will not index the junk again:
|
||||
|
||||
`/home/will/.hermes/backups/obsidian-cleanup/obsidian-cleanup-20260519-102137/`
|
||||
|
||||
## Link/index repairs
|
||||
|
||||
Created lightweight index/redirect notes for links that appeared to be real, so existing notes and automations can keep resolving paths without changing workflow logic:
|
||||
|
||||
- `Inbox/Inbox Home.md`
|
||||
- `Inbox/Triage.md`
|
||||
- `Inbox/Chat Summaries.md`
|
||||
- `Daily/Reviews.md`
|
||||
- `Diary/Entries.md`
|
||||
- `Diary/Weekly Reviews.md`
|
||||
- `Diary/Atlas Reflections.md`
|
||||
- `Infrastructure/Automation/n8n Morning Brief.md`
|
||||
- `Infrastructure/Automation/n8n Evening Digest.md`
|
||||
- `Atlas/Safer Autonomy and Permission Tiers.md`
|
||||
- `Atlas/Gateway Approval Runbook.md`
|
||||
- `Atlas/Skill Inventory.md`
|
||||
- `Atlas/Skill Backlog.md`
|
||||
- `Vault Conventions.md`
|
||||
- `Areas/Systems.md`
|
||||
- `Areas/Health.md`
|
||||
- `Areas/Finance.md`
|
||||
- `Areas/Home.md`
|
||||
- `Areas/Learning.md`
|
||||
- `Areas/Health and Medical Leave.md`
|
||||
- `Areas/Legal.md`
|
||||
- `People/Roxanne.md`
|
||||
- `People/Liam.md`
|
||||
- `People/Mila.md`
|
||||
- `People/Family in France.md`
|
||||
- `Projects/Hermes Atlas Personal Assistant.md`
|
||||
|
||||
Moved `Weekend Activity Ideas.md` content to `Resources/Weekend Activity Ideas.md` and left a root redirect note behind.
|
||||
|
||||
## Automation safety checks
|
||||
|
||||
- Obsidian Local REST API root: OK
|
||||
- Obsidian OpenAPI schema endpoint: OK
|
||||
- n8n container: `n8n-agent`, version `2.11.3`
|
||||
- n8n health via published local port `127.0.0.1:18808/healthz`: OK
|
||||
- n8n container state: running/healthy
|
||||
|
||||
I did **not** modify n8n workflows or automation configs.
|
||||
|
||||
Existing n8n logs contain a pre-existing Python task runner warning because Python 3 is missing inside the n8n image; this is unrelated to the vault cleanup and the container still reports healthy.
|
||||
|
||||
## Post-cleanup scan
|
||||
|
||||
- Empty notes: 0
|
||||
- `{}` stub notes: 0
|
||||
- Disposable test notes matching the cleanup patterns: 0
|
||||
- Remaining unresolved links: 12, all apparently intentional examples/template placeholders:
|
||||
- `Conventions.md`: `Note A`, `Note B`, `wikilinks`
|
||||
- `Templates/Atlas Artifacts/*`: `{{project}}`, `artifact-name`
|
||||
|
||||
## Notes
|
||||
|
||||
I intentionally kept `Templates/Atlas Artifacts/test-report.md` because it appears to be a reusable template, not disposable test output.
|
||||
+52
@@ -0,0 +1,52 @@
|
||||
# Obsidian Cleanup Completion — 2026-05-19
|
||||
|
||||
Vault: `/home/will/lab/swarm/swarm-common/obsidian-vault/will/will-shared-zap`
|
||||
Backup: `/home/will/.hermes/backups/obsidian-cleanup/obsidian-cleanup-20260519-103400`
|
||||
|
||||
## Deleted high-confidence junk
|
||||
- None
|
||||
|
||||
## Skipped
|
||||
- `2026-04-16.md` — missing
|
||||
- `Systems.md` — missing
|
||||
- `Voice Memos/2026-05-13-e2e-test-full-pipeline.md` — missing
|
||||
- `Voice Memos/2026-05-13-e2e-test-fixed-auth.md` — missing
|
||||
- `Voice Memos/2026-05-13-e2e-test-retry-auth.md` — missing
|
||||
- `Voice Memos/2026-05-13-e2e-auth-fixed.md` — missing
|
||||
- `Voice Memos/2026-05-13-final-e2e-test.md` — missing
|
||||
- `Notes/2026-05-13 Evening Digest.md` — missing
|
||||
- `Notes/2026-05-14 Evening Digest.md` — missing
|
||||
- `Notes/2026-05-15 Evening Digest.md` — missing
|
||||
- `Notes/2026-05-17 Evening Digest.md` — missing
|
||||
- `Clippings/2026-05-13-example-domain.md` — missing
|
||||
- `Hermes Disposable Tests/append-note-created-by-append-20260515-101031.md` — missing
|
||||
- `Hermes Disposable Tests/append-note-fixed-20260515-101031.md` — missing
|
||||
- `Hermes Disposable Tests/append-note-semantics-20260515-100757.md` — missing
|
||||
- `Hermes Disposable Tests/raw-append-op-20260515-100823.md` — missing
|
||||
- `Voice Memos/2026-05-13-final-pipeline-test.md` — missing
|
||||
|
||||
## Automation reference scan
|
||||
Searched `~/lab/swarm`, `~/.hermes/scripts`, and `~/.hermes/cron` for exact path/name/stem references, skipping dependencies/caches/credentials. References below are safety notes; deleted items were empty/stub/disposable test artifacts.
|
||||
|
||||
- No automation/source references found for deleted files.
|
||||
|
||||
## Post-cleanup scan
|
||||
- Markdown notes: 149 as of verification rerun after this completion report was created
|
||||
- Empty notes remaining: 0
|
||||
- `{}` stub notes remaining: 0
|
||||
- Disposable/e2e/test-pattern notes remaining: 0
|
||||
- Unresolved wikilinks remaining: 5, all harmless example/template placeholders:
|
||||
- `Conventions.md`: `Note A`, `Note B`, `wikilinks` x2
|
||||
- `Templates/Atlas Artifacts/status-report.md`: `artifact-name`
|
||||
|
||||
## Automation health verification
|
||||
- Active Obsidian vault confirmed from `~/.config/obsidian/obsidian.json`.
|
||||
- Obsidian Local REST API health: OK (`http://127.0.0.1:27123/`).
|
||||
- Obsidian OpenAPI endpoint: OK (`http://127.0.0.1:27123/openapi.yaml`).
|
||||
- n8n container `n8n-agent`: running and Docker-health `healthy`.
|
||||
- n8n published health endpoint: OK (`http://127.0.0.1:18808/healthz`).
|
||||
|
||||
## Next safe follow-ups
|
||||
- Decide whether nightly vault sync daily notes should be archived or compressed into one automation changelog.
|
||||
- Keep `Templates/Atlas Artifacts/test-report.md`; it appears to be a reusable template, not junk.
|
||||
- Git commit should be handled as a targeted pass because the vault currently has unrelated Obsidian plugin/config/runtime churn.
|
||||
+3
@@ -0,0 +1,3 @@
|
||||
# Safer Autonomy and Permission Tiers
|
||||
|
||||
Redirect/index note. Canonical project context: [[Projects/Atlas/Safer Autonomy and Permission Tiers]].
|
||||
@@ -0,0 +1,3 @@
|
||||
# Skill Backlog
|
||||
|
||||
Redirect/index note. Canonical note: [[Projects/Atlas/Skill Backlog]].
|
||||
@@ -0,0 +1,3 @@
|
||||
# Skill Inventory
|
||||
|
||||
Redirect/index note. Canonical note: [[Projects/Atlas/Skill Inventory]].
|
||||
@@ -17,16 +17,17 @@ tags:
|
||||
|
||||
## Diary: 3-line pressure valve
|
||||
|
||||
Today:
|
||||
Feeling:
|
||||
Need:
|
||||
Today: I woke up a little lazy and tired. Roxanne and I went to bed lat around 2am. Roxanne will spend mnost of the day baking a cake for her sister's birthday on Sunday. Roxanne will spend the night at her mom's tonight.
|
||||
Feeling: a little anxious
|
||||
Need: get out, walk a bunch and get some sun.
|
||||
Next:
|
||||
|
||||
If I have more words:
|
||||
- What helped?
|
||||
- What drained me?
|
||||
- What am I avoiding?
|
||||
- What am I avoiding? Monday's tasks
|
||||
- One thing I do not want to forget:
|
||||
|
||||
## Tasks
|
||||
|
||||
- [ ]
|
||||
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
type: daily
|
||||
date: 2026-05-17
|
||||
tags:
|
||||
- type/daily
|
||||
---
|
||||
|
||||
# 2026-05-17
|
||||
|
||||
## Focus
|
||||
|
||||
-
|
||||
|
||||
## Log
|
||||
|
||||
-
|
||||
|
||||
## Diary: 3-line pressure valve
|
||||
|
||||
Today: I had a good night sleep, I went to bed around 12:00am, woke up around 8:00am but I slept in until around 10:00am. Roxanne spent the night at her mom's to be with her sister and cousin Sophia; they will both come around 3:00pm to the nest and we'll drive to Anacortes to bring Sophia back home. I'll ride with them as I don't like the idea of Roxanne driving alone on long distance. Later: we went to Anacortes and brought Sophia back home. Now it's massage time for Roxy and relax.
|
||||
Feeling: I feel ok, a little too high cause of green (it's 1:32pm). Ready to wind down.
|
||||
Need: Rest, closeness, and a soft landing after the drive.
|
||||
Next: Relax with Roxy tonight. Tomorrow is a big day, lots of things to do and not fun at all.
|
||||
|
||||
If I have more words:
|
||||
- What helped?
|
||||
- What drained me?
|
||||
- What am I avoiding?
|
||||
- One thing I do not want to forget:
|
||||
|
||||
## Tasks
|
||||
|
||||
- [ ]
|
||||
|
||||
## Captures
|
||||
|
||||
-
|
||||
|
||||
## Links
|
||||
|
||||
- [[Ops Home]]
|
||||
@@ -0,0 +1,46 @@
|
||||
---
|
||||
type: daily
|
||||
date: 2026-05-18
|
||||
tags:
|
||||
- type/daily
|
||||
---
|
||||
|
||||
# 2026-05-18
|
||||
|
||||
## Focus
|
||||
|
||||
-
|
||||
|
||||
## Log
|
||||
|
||||
- Roxy woke up around 1:30pm.
|
||||
- Roxy was planning her birthday next weekend.
|
||||
- I realized her presents were an asset for the hotel stay downtown.
|
||||
- Later in the afternoon we went to Nordstrom to change the size and replace one dress.
|
||||
- We walked round trip.
|
||||
|
||||
## Diary: 3-line pressure valve
|
||||
|
||||
Today: Roxy woke up around 1:30pm. She was planning her birthday next weekend, and I realized her presents were part of making the downtown hotel stay feel special. Later we went to Nordstrom to exchange sizes and replace one dress, and walked there and back.
|
||||
Feeling: Present with Roxy; a little practical/logistical, but in a good way.
|
||||
Need: Keep birthday planning simple and focused on making the weekend feel cared-for, not perfect.
|
||||
Next: Keep track of what still needs to be ready for the downtown stay.
|
||||
|
||||
If I have more words:
|
||||
- What helped? Walking together and getting the dress/present logistics handled.
|
||||
- What drained me? The planning/details could become a lot if they pile up.
|
||||
- What am I avoiding?
|
||||
- One thing I do not want to forget: The presents are not just objects; they support the birthday/hotel experience.
|
||||
|
||||
## Tasks
|
||||
|
||||
- [ ]
|
||||
|
||||
## Captures
|
||||
|
||||
-
|
||||
|
||||
## Links
|
||||
|
||||
- [[Ops Home]]
|
||||
- [[Diary/Diary Home]]
|
||||
@@ -0,0 +1,7 @@
|
||||
# Daily Notes
|
||||
|
||||
Daily notes are the working scratchpad and command center.
|
||||
|
||||
Use them for focus, logs, quick captures, temporary tasks, and links to meetings/projects/decisions created that day.
|
||||
|
||||
Configured daily note template: [[Daily Note]]
|
||||
@@ -0,0 +1,3 @@
|
||||
# Daily Reviews
|
||||
|
||||
Index for generated daily review notes.
|
||||
+34
@@ -0,0 +1,34 @@
|
||||
---
|
||||
type: daily-review
|
||||
date: 2026-05-15
|
||||
tags: [type/daily-review, automation/n8n]
|
||||
---
|
||||
|
||||
# Daily Review 2026-05-15
|
||||
|
||||
## Top priorities
|
||||
|
||||
- [ ]
|
||||
- [ ]
|
||||
- [ ]
|
||||
|
||||
## Inbox sweep
|
||||
|
||||
- [ ] Review [[Inbox]]
|
||||
- [ ] Promote useful captures into [[Projects Home]], [[Resources Home]], [[Decisions Home]], or [[Runbooks Home]]
|
||||
|
||||
## Open loops
|
||||
|
||||
- [ ] Check [[Projects Home]]
|
||||
- [ ] Check [[Meetings Home]] action items
|
||||
- [ ] Check [[Runbooks Home]] for procedures that need updates
|
||||
|
||||
## Notes / log
|
||||
|
||||
-
|
||||
|
||||
## End-of-day reflection
|
||||
|
||||
- What moved forward?
|
||||
- What is blocked?
|
||||
- What should start tomorrow?
|
||||
+34
@@ -0,0 +1,34 @@
|
||||
---
|
||||
type: daily-review
|
||||
date: 2026-05-17
|
||||
tags: [type/daily-review, automation/n8n]
|
||||
---
|
||||
|
||||
# Daily Review 2026-05-17
|
||||
|
||||
## Top priorities
|
||||
|
||||
- [ ]
|
||||
- [ ]
|
||||
- [ ]
|
||||
|
||||
## Inbox sweep
|
||||
|
||||
- [ ] Review [[Inbox]]
|
||||
- [ ] Promote useful captures into [[Projects Home]], [[Resources Home]], [[Decisions Home]], or [[Runbooks Home]]
|
||||
|
||||
## Open loops
|
||||
|
||||
- [ ] Check [[Projects Home]]
|
||||
- [ ] Check [[Meetings Home]] action items
|
||||
- [ ] Check [[Runbooks Home]] for procedures that need updates
|
||||
|
||||
## Notes / log
|
||||
|
||||
-
|
||||
|
||||
## End-of-day reflection
|
||||
|
||||
- What moved forward?
|
||||
- What is blocked?
|
||||
- What should start tomorrow?
|
||||
+34
@@ -0,0 +1,34 @@
|
||||
---
|
||||
type: daily-review
|
||||
date: 2026-05-18
|
||||
tags: [type/daily-review, automation/n8n]
|
||||
---
|
||||
|
||||
# Daily Review 2026-05-18
|
||||
|
||||
## Top priorities
|
||||
|
||||
- [ ]
|
||||
- [ ]
|
||||
- [ ]
|
||||
|
||||
## Inbox sweep
|
||||
|
||||
- [ ] Review [[Inbox]]
|
||||
- [ ] Promote useful captures into [[Projects Home]], [[Resources Home]], [[Decisions Home]], or [[Runbooks Home]]
|
||||
|
||||
## Open loops
|
||||
|
||||
- [ ] Check [[Projects Home]]
|
||||
- [ ] Check [[Meetings Home]] action items
|
||||
- [ ] Check [[Runbooks Home]] for procedures that need updates
|
||||
|
||||
## Notes / log
|
||||
|
||||
-
|
||||
|
||||
## End-of-day reflection
|
||||
|
||||
- What moved forward?
|
||||
- What is blocked?
|
||||
- What should start tomorrow?
|
||||
+34
@@ -0,0 +1,34 @@
|
||||
---
|
||||
type: daily-review
|
||||
date: 2026-05-20
|
||||
tags: [type/daily-review, automation/n8n]
|
||||
---
|
||||
|
||||
# Daily Review 2026-05-20
|
||||
|
||||
## Top priorities
|
||||
|
||||
- [ ]
|
||||
- [ ]
|
||||
- [ ]
|
||||
|
||||
## Inbox sweep
|
||||
|
||||
- [ ] Review [[Inbox]]
|
||||
- [ ] Promote useful captures into [[Projects Home]], [[Resources Home]], [[Decisions Home]], or [[Runbooks Home]]
|
||||
|
||||
## Open loops
|
||||
|
||||
- [ ] Check [[Projects Home]]
|
||||
- [ ] Check [[Meetings Home]] action items
|
||||
- [ ] Check [[Runbooks Home]] for procedures that need updates
|
||||
|
||||
## Notes / log
|
||||
|
||||
-
|
||||
|
||||
## End-of-day reflection
|
||||
|
||||
- What moved forward?
|
||||
- What is blocked?
|
||||
- What should start tomorrow?
|
||||
@@ -0,0 +1,15 @@
|
||||
# Decisions Home
|
||||
|
||||
Decision notes preserve context and rationale so future work does not re-litigate old choices.
|
||||
|
||||
Create notes from [[Decision]].
|
||||
|
||||
## Recent decisions
|
||||
|
||||
```dataview
|
||||
TABLE date, status, project
|
||||
FROM "Decisions"
|
||||
WHERE type = "decision"
|
||||
SORT date DESC
|
||||
LIMIT 30
|
||||
```
|
||||
@@ -0,0 +1,21 @@
|
||||
# Decision / Runbook Suggestions 2026-05-18
|
||||
|
||||
Generated: 2026-05-18T15:29:06.051Z
|
||||
|
||||
Review candidates and promote useful items into durable Decision or Runbook notes. This note is overwritten weekly.
|
||||
|
||||
## Decision Candidates
|
||||
|
||||
_No candidates found._
|
||||
|
||||
|
||||
## Runbook Candidates
|
||||
|
||||
_No candidates found._
|
||||
|
||||
|
||||
## Raw Summary
|
||||
|
||||
- Total candidates: 0
|
||||
- Decision candidates: 0
|
||||
- Runbook candidates: 0
|
||||
@@ -0,0 +1,3 @@
|
||||
# Atlas Reflections
|
||||
|
||||
Index note for assistant-generated reflection drafts and patterns worth reviewing.
|
||||
@@ -0,0 +1,5 @@
|
||||
# Diary Entries
|
||||
|
||||
Index note for diary entry folders/files.
|
||||
|
||||
Use this as a landing page; entries can remain as dated notes.
|
||||
@@ -0,0 +1,3 @@
|
||||
# Diary Weekly Reviews
|
||||
|
||||
Index note for weekly diary reviews.
|
||||
@@ -0,0 +1,3 @@
|
||||
# Chat Summaries
|
||||
|
||||
Index for generated chat summary captures.
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: "Atlas Event-Driven Automation Smoke"
|
||||
type: "transcript"
|
||||
source: "webhook"
|
||||
created: "2026-05-14T23:50:12.631Z"
|
||||
tags: ["automation/n8n","chat-summary","transcript","atlas","smoke-test"]
|
||||
---
|
||||
|
||||
# Atlas Event-Driven Automation Smoke
|
||||
|
||||
## Summary
|
||||
|
||||
Smoke test created by Workstream 6 implementation to verify local transcript capture path.
|
||||
|
||||
## Notes
|
||||
|
||||
This is a short synthetic transcript smoke test. No private content.
|
||||
|
||||
## Metadata
|
||||
|
||||
```json
|
||||
{}
|
||||
```
|
||||
@@ -0,0 +1,9 @@
|
||||
# Inbox Home
|
||||
|
||||
Front door for raw captures, chat summaries, triage notes, and generated automation output.
|
||||
|
||||
## Key areas
|
||||
|
||||
- [[Inbox/Triage]]
|
||||
- [[Inbox/Chat Summaries]]
|
||||
- [[Daily/Reviews]]
|
||||
@@ -0,0 +1,8 @@
|
||||
# Inbox
|
||||
|
||||
Quick capture zone. Process these notes during weekly review:
|
||||
|
||||
1. Delete junk.
|
||||
2. Move actionable work to projects/tasks.
|
||||
3. Promote durable knowledge to resources, runbooks, or decisions.
|
||||
4. Archive stale items.
|
||||
@@ -0,0 +1,3 @@
|
||||
# Inbox Triage
|
||||
|
||||
Index for generated triage notes in [[Inbox/Triage]].
|
||||
@@ -0,0 +1,28 @@
|
||||
# Inbox Triage 2026-05-15
|
||||
|
||||
Generated: 2026-05-15T01:00:00.070Z
|
||||
|
||||
## Inbox items
|
||||
|
||||
- [ ] [[Inbox]] — classify as Project / Resource / Decision / Runbook / Archive
|
||||
- [ ] [[Weekly Review]] — classify as Project / Resource / Decision / Runbook / Archive
|
||||
|
||||
## Promote to Projects
|
||||
|
||||
- [ ]
|
||||
|
||||
## Promote to Resources
|
||||
|
||||
- [ ]
|
||||
|
||||
## Promote to Decisions
|
||||
|
||||
- [ ]
|
||||
|
||||
## Promote to Runbooks
|
||||
|
||||
- [ ]
|
||||
|
||||
## Archive / Delete / Defer
|
||||
|
||||
- [ ]
|
||||
@@ -0,0 +1,28 @@
|
||||
# Inbox Triage 2026-05-16
|
||||
|
||||
Generated: 2026-05-16T01:00:38.015Z
|
||||
|
||||
## Inbox items
|
||||
|
||||
- [ ] [[Inbox]] — classify as Project / Resource / Decision / Runbook / Archive
|
||||
- [ ] [[Weekly Review]] — classify as Project / Resource / Decision / Runbook / Archive
|
||||
|
||||
## Promote to Projects
|
||||
|
||||
- [ ]
|
||||
|
||||
## Promote to Resources
|
||||
|
||||
- [ ]
|
||||
|
||||
## Promote to Decisions
|
||||
|
||||
- [ ]
|
||||
|
||||
## Promote to Runbooks
|
||||
|
||||
- [ ]
|
||||
|
||||
## Archive / Delete / Defer
|
||||
|
||||
- [ ]
|
||||
@@ -0,0 +1,28 @@
|
||||
# Inbox Triage 2026-05-17
|
||||
|
||||
Generated: 2026-05-17T01:09:48.651Z
|
||||
|
||||
## Inbox items
|
||||
|
||||
- [ ] [[Inbox]] — classify as Project / Resource / Decision / Runbook / Archive
|
||||
- [ ] [[Weekly Review]] — classify as Project / Resource / Decision / Runbook / Archive
|
||||
|
||||
## Promote to Projects
|
||||
|
||||
- [ ]
|
||||
|
||||
## Promote to Resources
|
||||
|
||||
- [ ]
|
||||
|
||||
## Promote to Decisions
|
||||
|
||||
- [ ]
|
||||
|
||||
## Promote to Runbooks
|
||||
|
||||
- [ ]
|
||||
|
||||
## Archive / Delete / Defer
|
||||
|
||||
- [ ]
|
||||
@@ -0,0 +1,28 @@
|
||||
# Inbox Triage 2026-05-18
|
||||
|
||||
Generated: 2026-05-18T01:00:00.088Z
|
||||
|
||||
## Inbox items
|
||||
|
||||
- [ ] [[Inbox]] — classify as Project / Resource / Decision / Runbook / Archive
|
||||
- [ ] [[Weekly Review]] — classify as Project / Resource / Decision / Runbook / Archive
|
||||
|
||||
## Promote to Projects
|
||||
|
||||
- [ ]
|
||||
|
||||
## Promote to Resources
|
||||
|
||||
- [ ]
|
||||
|
||||
## Promote to Decisions
|
||||
|
||||
- [ ]
|
||||
|
||||
## Promote to Runbooks
|
||||
|
||||
- [ ]
|
||||
|
||||
## Archive / Delete / Defer
|
||||
|
||||
- [ ]
|
||||
@@ -0,0 +1,28 @@
|
||||
# Inbox Triage 2026-05-19
|
||||
|
||||
Generated: 2026-05-19T01:00:00.036Z
|
||||
|
||||
## Inbox items
|
||||
|
||||
- [ ] [[Inbox]] — classify as Project / Resource / Decision / Runbook / Archive
|
||||
- [ ] [[Weekly Review]] — classify as Project / Resource / Decision / Runbook / Archive
|
||||
|
||||
## Promote to Projects
|
||||
|
||||
- [ ]
|
||||
|
||||
## Promote to Resources
|
||||
|
||||
- [ ]
|
||||
|
||||
## Promote to Decisions
|
||||
|
||||
- [ ]
|
||||
|
||||
## Promote to Runbooks
|
||||
|
||||
- [ ]
|
||||
|
||||
## Archive / Delete / Defer
|
||||
|
||||
- [ ]
|
||||
@@ -0,0 +1,30 @@
|
||||
# Inbox Triage 2026-05-20
|
||||
|
||||
Generated: 2026-05-20T01:00:00.151Z
|
||||
|
||||
## Inbox items
|
||||
|
||||
- [ ] [[Chat Summaries]] — classify as Project / Resource / Decision / Runbook / Archive
|
||||
- [ ] [[Inbox Home]] — classify as Project / Resource / Decision / Runbook / Archive
|
||||
- [ ] [[Inbox]] — classify as Project / Resource / Decision / Runbook / Archive
|
||||
- [ ] [[Weekly Review]] — classify as Project / Resource / Decision / Runbook / Archive
|
||||
|
||||
## Promote to Projects
|
||||
|
||||
- [ ]
|
||||
|
||||
## Promote to Resources
|
||||
|
||||
- [ ]
|
||||
|
||||
## Promote to Decisions
|
||||
|
||||
- [ ]
|
||||
|
||||
## Promote to Runbooks
|
||||
|
||||
- [ ]
|
||||
|
||||
## Archive / Delete / Defer
|
||||
|
||||
- [ ]
|
||||
@@ -0,0 +1,27 @@
|
||||
# Weekly Review
|
||||
|
||||
Use this once per week to keep the vault useful.
|
||||
|
||||
## Inbox
|
||||
|
||||
- [ ] Process [[Inbox]]
|
||||
- [ ] Delete junk notes
|
||||
- [ ] Move durable notes to the right folder
|
||||
|
||||
## Projects
|
||||
|
||||
- [ ] Update active project notes
|
||||
- [ ] Archive inactive projects
|
||||
- [ ] Move important choices to [[Decisions Home]]
|
||||
|
||||
## Tasks
|
||||
|
||||
- [ ] Clear stale tasks
|
||||
- [ ] Move project tasks into project notes
|
||||
- [ ] Confirm next actions are explicit
|
||||
|
||||
## Knowledge
|
||||
|
||||
- [ ] Convert repeated procedures into [[Runbooks Home]]
|
||||
- [ ] Link related notes together
|
||||
- [ ] Add missing context to notes that only make sense “right now”
|
||||
+27
-1
@@ -1 +1,27 @@
|
||||
{}
|
||||
{
|
||||
"nodes":[
|
||||
{"id":"title","type":"text","x":60,"y":30,"width":760,"height":90,"text":"Automation Flow\n\nHow messages, scheduled work, local services, and durable notes move through the system.","color":"6"},
|
||||
{"id":"inputs","type":"text","x":90,"y":210,"width":240,"height":190,"text":"1 · Inputs\n\nTelegram\nDiscord\nEmail\nWebhooks\nManual Obsidian notes","color":"2"},
|
||||
{"id":"routing","type":"text","x":430,"y":210,"width":260,"height":190,"text":"2 · Gateway routing\n\nAllowlists\nTopics / sessions\nHome channel delivery\nPlatform adapters","color":"5"},
|
||||
{"id":"atlas","type":"text","x":790,"y":210,"width":250,"height":190,"text":"3 · Atlas decides\n\nTool calls\nSubagents\nKanban boards\nCron jobs","color":"5"},
|
||||
{"id":"services","type":"text","x":1150,"y":140,"width":270,"height":190,"text":"4 · Execute\n\nSearch / web extract\nLocal LLM / embeddings\nWhisper / Kokoro\nn8n workflows","color":"3"},
|
||||
{"id":"knowledge","type":"text","x":1150,"y":430,"width":270,"height":190,"text":"5 · Capture knowledge\n\nObsidian vault\nDaily research archive\nRunbooks\nPersonal context notes","color":"6"},
|
||||
{"id":"delivery","type":"text","x":1510,"y":250,"width":260,"height":190,"text":"6 · Deliver result\n\nTelegram / Discord\nEmail\nFiles / media\nFollow-up reminders","color":"4"},
|
||||
{"id":"backups","type":"text","x":790,"y":520,"width":250,"height":170,"text":"Safety loop\n\nGit commits\nMinIO backups\nReview handoffs\nHealth watchdogs","color":"6"}
|
||||
],
|
||||
"edges":[
|
||||
{"id":"e1","fromNode":"inputs","toNode":"routing","label":"events","fromSide":"right","toSide":"left"},
|
||||
{"id":"e2","fromNode":"routing","toNode":"atlas","label":"normalized message","fromSide":"right","toSide":"left"},
|
||||
{"id":"e3","fromNode":"atlas","toNode":"services","label":"tool calls","fromSide":"right","toSide":"left"},
|
||||
{"id":"e4","fromNode":"services","toNode":"knowledge","label":"write / index","fromSide":"bottom","toSide":"top","color":"6"},
|
||||
{"id":"e5","fromNode":"knowledge","toNode":"atlas","label":"context","fromSide":"left","toSide":"bottom","color":"6"},
|
||||
{"id":"e6","fromNode":"atlas","toNode":"delivery","label":"final response","fromSide":"right","toSide":"left"},
|
||||
{"id":"e7","fromNode":"atlas","toNode":"backups","label":"safe ops","fromSide":"bottom","toSide":"top"},
|
||||
{"id":"e8","fromNode":"backups","toNode":"knowledge","label":"archives","fromSide":"right","toSide":"left","color":"6"},
|
||||
{"id":"e9","fromNode":"services","toNode":"delivery","label":"media / artifacts","fromSide":"right","toSide":"left"}
|
||||
],
|
||||
"metadata":{
|
||||
"version":"1.0-1.0",
|
||||
"frontmatter":{}
|
||||
}
|
||||
}
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Architecture - Automation Flow
|
||||
area: infrastructure
|
||||
tags: [infrastructure, architecture, diagrams, automation]
|
||||
created: 2026-04-16
|
||||
updated: 2026-04-16
|
||||
updated: 2026-05-19
|
||||
status: active
|
||||
related: [[Infrastructure/Architecture]], [[Infrastructure/Architecture - Overview]], [[Infrastructure/Architecture - Service Topology]], [[Infrastructure/Automation/Cron Jobs]], [[Infrastructure/Automation/n8n Workflows]]
|
||||
---
|
||||
|
||||
+44
-20
@@ -1,25 +1,49 @@
|
||||
{
|
||||
"nodes":[
|
||||
{"id":"title","type":"text","x":80,"y":30,"width":620,"height":90,"text":"Infrastructure Architecture - Master View\n\nVisual overview of Will's assistant stack, control plane, service layer, storage, and external integrations"},
|
||||
{"id":"group-left","type":"text","x":60,"y":150,"width":620,"height":520,"text":"","color":"4"},
|
||||
{"id":"group-center","type":"text","x":720,"y":150,"width":720,"height":520,"text":"","color":"5"},
|
||||
{"id":"group-right","type":"text","x":1480,"y":150,"width":360,"height":520,"text":"","color":"1"},
|
||||
{"id":"human","type":"text","x":100,"y":200,"width":220,"height":110,"text":"Will\n\nHuman operator\nDiscord, Telegram, Obsidian","color":"4"},
|
||||
{"id":"channels","type":"text","x":380,"y":190,"width":240,"height":130,"text":"Interaction channels\n\nDiscord\nTelegram\nWeb chat","color":"2"},
|
||||
{"id":"guide","type":"text","x":100,"y":390,"width":520,"height":210,"text":"Reading guide\n\nLeft: people and entry points\nCenter: assistant control plane and local capabilities\nRight: external systems and deployment targets\nBottom-center: storage and durable state","color":"4"},
|
||||
{"id":"vm","type":"text","x":780,"y":190,"width":260,"height":170,"text":"OpenClaw VM\n\nRuntime\nSession routing\nMemory search\nCron\nWorkspace scripts","color":"5"},
|
||||
{"id":"host","type":"text","x":1080,"y":170,"width":300,"height":240,"text":"Host services\n192.168.153.130\n\nSearXNG 18803\nBrave MCP 18802\nn8n-agent 18808\nwhisper.cpp 18801\nKokoro 18805\nOllama 18807\nllama.cpp Gemma 18806\nObsidian API 27123","color":"3"},
|
||||
{"id":"storage","type":"text","x":880,"y":470,"width":500,"height":150,"text":"Storage and durable state\n\nMinIO 192.168.153.253:9000 | Bucket: zap | Gitea: will/swarm-zap.git\nShared Obsidian vault: will/will-shared-zap","color":"6"},
|
||||
{"id":"external","type":"text","x":1520,"y":200,"width":280,"height":170,"text":"External systems\n\nGoogle Workspace\nInternet services\nDiscord network\nTelegram network\nTailscale","color":"1"},
|
||||
{"id":"k8s","type":"text","x":1520,"y":450,"width":280,"height":120,"text":"Kubernetes\n\nPi cluster\nNamespace: swarm","color":"0"}
|
||||
{"id":"0a5409bdb505067b","type":"group","x":820,"y":280,"width":300,"height":300,"label":"Untitled group"},
|
||||
{"id":"16e9f708e63157fa","type":"group","x":820,"y":280,"width":300,"height":300,"label":"Untitled group"},
|
||||
{"id":"9f5a54b712c63995","type":"group","x":820,"y":280,"width":300,"height":300,"label":"Untitled group"},
|
||||
{"id":"397aa2f063497963","type":"group","x":820,"y":280,"width":300,"height":300,"label":"Untitled group"},
|
||||
{"id":"title","type":"text","text":"Atlas / Hermes Infrastructure — Master View\n\nProduction gateway, specialist agents, local AI services, automations, storage, and external integrations.","x":60,"y":20,"width":760,"height":100,"color":"6"},
|
||||
{"id":"legend","type":"text","text":"Legend\n🟨 People / channels\n🟩 Agent control plane\n🟦 Local services\n🟪 Knowledge + storage\n🟥 External networks\n⬜ Deployment targets","x":1500,"y":20,"width":330,"height":210,"color":"0"},
|
||||
{"id":"group-entry","type":"text","text":"ENTRY POINTS","x":60,"y":160,"width":560,"height":470,"color":"4"},
|
||||
{"id":"will","type":"text","text":"👤 Will\n\nTelegram DM/groups\nDiscord ops alerts\nObsidian workspace","x":100,"y":230,"width":220,"height":150,"color":"4"},
|
||||
{"id":"channels","type":"text","text":"💬 Messaging Gateway\n\nTelegram\nDiscord\nEmail\nWebhook/API","x":360,"y":230,"width":220,"height":150,"color":"2"},
|
||||
{"id":"obsidian-ui","type":"text","text":"📝 Obsidian UI\n\nShared vault\nManual notes\nDaily research archive","x":230,"y":450,"width":260,"height":130,"color":"6"},
|
||||
{"id":"group-core","type":"text","text":"ATLAS CONTROL PLANE","x":680,"y":160,"width":560,"height":470,"color":"5"},
|
||||
{"id":"default","type":"text","text":"🧠 default / Atlas\n\ngpt-5.5 primary\nProduction gateway running\nMemory + skills + tools","x":720,"y":230,"width":240,"height":170,"color":"5"},
|
||||
{"id":"specialists","type":"text","text":"🤖 Specialist profiles\n\nresearcher · writer\nengineer · reviewer\nops · orchestrator\nglm-simple","x":990,"y":230,"width":220,"height":170,"color":"5"},
|
||||
{"id":"kanban","type":"text","text":"📋 Durable work queue\n\nKanban boards\nReview handoffs\nWorker dispatch","x":840,"y":460,"width":260,"height":130,"color":"5"},
|
||||
{"id":"group-services","type":"text","text":"LOCAL SERVICE LAYER","x":1300,"y":270,"width":560,"height":420,"color":"3"},
|
||||
{"id":"retrieval","type":"text","text":"🔎 Retrieval\n\nSearXNG :18803\nBrave MCP :18802\nOllama embeddings :18807","x":1340,"y":340,"width":230,"height":150,"color":"3"},
|
||||
{"id":"local-ai","type":"text","text":"🦙 Local AI + Voice\n\nllama.cpp :18806\nWhisper :18801\nKokoro :18805","x":1600,"y":340,"width":220,"height":150,"color":"3"},
|
||||
{"id":"automation","type":"text","text":"⚙️ Automation\n\nn8n :18808\nCron jobs\nWebhook triggers","x":1470,"y":530,"width":230,"height":130,"color":"3"},
|
||||
{"id":"group-state","type":"text","text":"KNOWLEDGE, REPOS, BACKUPS","x":680,"y":720,"width":800,"height":250,"color":"6"},
|
||||
{"id":"vault","type":"text","text":"📚 Obsidian vault\n\nwill-shared-zap\nPersonal context\nResearch briefs\nRunbooks","x":720,"y":790,"width":220,"height":140,"color":"6"},
|
||||
{"id":"minio","type":"text","text":"🪣 MinIO / S3\n\natlas bucket\nBackups + artifacts\nRetention cleanup","x":990,"y":790,"width":220,"height":140,"color":"6"},
|
||||
{"id":"gitea","type":"text","text":"🌿 Gitea / Git\n\nHermes source mirror\nConfig/history\nProject repos","x":1260,"y":790,"width":180,"height":140,"color":"6"},
|
||||
{"id":"external","type":"text","text":"🌐 External systems\n\nGoogle Workspace\nInternet APIs\nTailscale\nTelegram/Discord networks","x":1500,"y":760,"width":300,"height":170,"color":"1"},
|
||||
{"id":"k8s","type":"text","text":"☸️ Pi Kubernetes\n\nnamespace: swarm\nFuture/target runtime","x":100,"y":760,"width":280,"height":130,"color":"0"}
|
||||
],
|
||||
"edges":[
|
||||
{"id":"e1","fromNode":"human","toNode":"channels","label":"uses","fromSide":"right","toSide":"left"},
|
||||
{"id":"e2","fromNode":"channels","toNode":"vm","label":"messages","fromSide":"right","toSide":"left"},
|
||||
{"id":"e3","fromNode":"vm","toNode":"host","label":"local services","fromSide":"right","toSide":"left"},
|
||||
{"id":"e4","fromNode":"vm","toNode":"storage","label":"writes state","fromSide":"bottom","toSide":"top"},
|
||||
{"id":"e5","fromNode":"vm","toNode":"external","label":"APIs and networks","fromSide":"right","toSide":"left"},
|
||||
{"id":"e6","fromNode":"vm","toNode":"k8s","label":"deploy target","fromSide":"right","toSide":"left"},
|
||||
{"id":"e7","fromNode":"host","toNode":"storage","label":"vault and backups","fromSide":"bottom","toSide":"top"}
|
||||
]
|
||||
{"id":"e1","fromNode":"will","fromSide":"right","toNode":"channels","toSide":"left","label":"uses"},
|
||||
{"id":"e2","fromNode":"channels","fromSide":"right","toNode":"default","toSide":"left","label":"messages"},
|
||||
{"id":"e3","fromNode":"obsidian-ui","fromSide":"right","toNode":"vault","toSide":"left","color":"6","label":"edits"},
|
||||
{"id":"e4","fromNode":"default","fromSide":"right","toNode":"specialists","toSide":"left","label":"delegates"},
|
||||
{"id":"e5","fromNode":"default","fromSide":"bottom","toNode":"kanban","toSide":"top","label":"creates / monitors"},
|
||||
{"id":"e6","fromNode":"kanban","fromSide":"top","toNode":"specialists","toSide":"bottom","label":"dispatches"},
|
||||
{"id":"e7","fromNode":"default","fromSide":"right","toNode":"retrieval","toSide":"left","label":"searches"},
|
||||
{"id":"e8","fromNode":"default","fromSide":"right","toNode":"local-ai","toSide":"left","label":"generates / transcribes"},
|
||||
{"id":"e9","fromNode":"default","fromSide":"right","toNode":"automation","toSide":"left","label":"triggers"},
|
||||
{"id":"e10","fromNode":"default","fromSide":"bottom","toNode":"vault","toSide":"top","color":"6","label":"reads/writes"},
|
||||
{"id":"e11","fromNode":"automation","fromSide":"bottom","toNode":"vault","toSide":"right","color":"6","label":"syncs notes"},
|
||||
{"id":"e12","fromNode":"default","fromSide":"right","toNode":"external","toSide":"left","label":"APIs / gateways"},
|
||||
{"id":"e13","fromNode":"default","fromSide":"bottom","toNode":"minio","toSide":"top","label":"backups"},
|
||||
{"id":"e14","fromNode":"default","fromSide":"bottom","toNode":"gitea","toSide":"top","label":"commits / mirrors"},
|
||||
{"id":"e15","fromNode":"default","fromSide":"left","toNode":"k8s","toSide":"right","label":"deploy target"}
|
||||
],
|
||||
"metadata":{
|
||||
"version":"1.0-1.0",
|
||||
"frontmatter":{}
|
||||
}
|
||||
}
|
||||
+21
-13
@@ -1,18 +1,26 @@
|
||||
{
|
||||
"nodes":[
|
||||
{"id":"n1","type":"text","x":80,"y":80,"width":220,"height":100,"text":"Will\n\nHuman operator\nUses Discord, Telegram, Obsidian"},
|
||||
{"id":"n2","type":"text","x":420,"y":60,"width":260,"height":120,"text":"OpenClaw VM\n\nRuntime\nWorkspace memory\nScripts\nSessions"},
|
||||
{"id":"n3","type":"text","x":780,"y":40,"width":300,"height":220,"text":"Host services\n192.168.153.130\n\nSearXNG :18803\nBrave MCP :18802\nn8n-agent :18808\nwhisper.cpp :18801\nKokoro :18805\nOllama :18807\nllama.cpp Gemma :18806\nObsidian API :27123"},
|
||||
{"id":"n4","type":"text","x":1130,"y":80,"width":240,"height":100,"text":"External services\n\nGoogle Workspace\nInternet services\nDiscord\nTelegram"},
|
||||
{"id":"n5","type":"text","x":760,"y":340,"width":260,"height":120,"text":"Storage and infra\n\nMinIO 192.168.153.253:9000\nGitea over Tailscale\nPi Kubernetes cluster\nnamespace: swarm"},
|
||||
{"id":"n6","type":"text","x":1080,"y":340,"width":240,"height":100,"text":"Shared knowledge layer\n\nObsidian shared vault\nwill/will-shared-zap"}
|
||||
{"id":"title","type":"text","x":60,"y":30,"width":650,"height":90,"text":"Architecture Overview\n\nA cleaner top-level map: who talks to Atlas, where work runs, and where durable state lives.","color":"6"},
|
||||
{"id":"will","type":"text","x":80,"y":190,"width":220,"height":130,"text":"👤 Will\n\nTelegram · Discord\nObsidian · Email","color":"4"},
|
||||
{"id":"gateway","type":"text","x":360,"y":170,"width":230,"height":160,"text":"📨 Gateway channels\n\nTelegram\nDiscord\nEmail\nWebhook/API","color":"2"},
|
||||
{"id":"atlas","type":"text","x":680,"y":160,"width":260,"height":180,"text":"🧠 Atlas default profile\n\nProduction gateway\ngpt-5.5 + GLM fallback\nTools · memory · skills","color":"5"},
|
||||
{"id":"agents","type":"text","x":680,"y":410,"width":260,"height":170,"text":"🤖 Specialist profiles\n\nresearcher · writer\nengineer · reviewer\nops · orchestrator\nglm-simple","color":"5"},
|
||||
{"id":"services","type":"text","x":1040,"y":150,"width":280,"height":210,"text":"🧰 Local services\n\nSearch · Brave MCP\nllama.cpp · Ollama\nWhisper · Kokoro\nn8n · Obsidian API","color":"3"},
|
||||
{"id":"state","type":"text","x":1040,"y":430,"width":280,"height":170,"text":"📚 Durable state\n\nObsidian vault\nGitea repos\nMinIO backups\nKanban boards","color":"6"},
|
||||
{"id":"external","type":"text","x":1420,"y":250,"width":280,"height":190,"text":"🌐 External systems\n\nGoogle Workspace\nInternet APIs\nTailscale\nTelegram/Discord networks","color":"1"}
|
||||
],
|
||||
"edges":[
|
||||
{"id":"e1","fromNode":"n1","toNode":"n2","label":"interacts with","fromSide":"right","toSide":"left"},
|
||||
{"id":"e2","fromNode":"n2","toNode":"n3","label":"calls local services","fromSide":"right","toSide":"left"},
|
||||
{"id":"e3","fromNode":"n2","toNode":"n4","label":"connects to","fromSide":"right","toSide":"left"},
|
||||
{"id":"e4","fromNode":"n2","toNode":"n5","label":"backs up / deploys / syncs","fromSide":"bottom","toSide":"top"},
|
||||
{"id":"e5","fromNode":"n3","toNode":"n6","label":"Obsidian API serves","fromSide":"bottom","toSide":"top"},
|
||||
{"id":"e6","fromNode":"n1","toNode":"n6","label":"reads and edits","fromSide":"right","toSide":"left"}
|
||||
]
|
||||
{"id":"e1","fromNode":"will","toNode":"gateway","label":"messages","fromSide":"right","toSide":"left"},
|
||||
{"id":"e2","fromNode":"gateway","toNode":"atlas","label":"routes","fromSide":"right","toSide":"left"},
|
||||
{"id":"e3","fromNode":"atlas","toNode":"agents","label":"delegates","fromSide":"bottom","toSide":"top"},
|
||||
{"id":"e4","fromNode":"atlas","toNode":"services","label":"calls","fromSide":"right","toSide":"left"},
|
||||
{"id":"e5","fromNode":"atlas","toNode":"state","label":"reads/writes","fromSide":"bottom","toSide":"top","color":"6"},
|
||||
{"id":"e6","fromNode":"services","toNode":"state","label":"indexes / syncs","fromSide":"bottom","toSide":"top","color":"6"},
|
||||
{"id":"e7","fromNode":"atlas","toNode":"external","label":"APIs","fromSide":"right","toSide":"left"},
|
||||
{"id":"e8","fromNode":"will","toNode":"state","label":"notes","fromSide":"bottom","toSide":"left","color":"6"}
|
||||
],
|
||||
"metadata":{
|
||||
"version":"1.0-1.0",
|
||||
"frontmatter":{}
|
||||
}
|
||||
}
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Architecture - Overview
|
||||
area: infrastructure
|
||||
tags: [infrastructure, architecture, diagrams, overview]
|
||||
created: 2026-04-16
|
||||
updated: 2026-04-16
|
||||
updated: 2026-05-19
|
||||
status: active
|
||||
related: [[Infrastructure/Architecture]], [[Infrastructure/Architecture - Service Topology]], [[Infrastructure/Architecture - Automation Flow]]
|
||||
---
|
||||
|
||||
+26
-12
@@ -1,17 +1,31 @@
|
||||
{
|
||||
"nodes":[
|
||||
{"id":"n1","type":"text","x":80,"y":120,"width":220,"height":90,"text":"User sessions\nwebchat\nDiscord\nTelegram"},
|
||||
{"id":"n2","type":"text","x":360,"y":80,"width":260,"height":180,"text":"OpenClaw runtime\n\nMain runtime\nMemory search\nCron\nWorkspace scripts"},
|
||||
{"id":"n3","type":"text","x":700,"y":40,"width":240,"height":140,"text":"Search + retrieval\n\nSearXNG :18803\nBrave MCP :18802\nOllama embeddings :18807"},
|
||||
{"id":"n4","type":"text","x":700,"y":220,"width":240,"height":140,"text":"Execution services\n\nllama.cpp Gemma :18806\nn8n-agent :18808\nwhisper.cpp :18801\nKokoro :18805"},
|
||||
{"id":"n5","type":"text","x":1020,"y":60,"width":220,"height":100,"text":"Obsidian API\n:27123\nShared vault bridge"},
|
||||
{"id":"n6","type":"text","x":1020,"y":220,"width":240,"height":140,"text":"Persistence + targets\n\nMinIO bucket zap\nGitea repo\nPi cluster swarm ns"}
|
||||
{"id":"title","type":"text","x":60,"y":30,"width":720,"height":90,"text":"Service Topology\n\nRuntime dependencies around Atlas: gateway → control plane → local capabilities → persistence.","color":"6"},
|
||||
{"id":"sessions","type":"text","x":80,"y":210,"width":230,"height":150,"text":"💬 User sessions\n\nTelegram\nDiscord\nEmail\nWebhook/API","color":"2"},
|
||||
{"id":"runtime","type":"text","x":410,"y":190,"width":260,"height":180,"text":"🧠 Atlas runtime\n\ndefault profile\nSession routing\nTool execution\nMemory + skills","color":"5"},
|
||||
{"id":"workers","type":"text","x":410,"y":450,"width":260,"height":150,"text":"🤖 Workers\n\nSpecialist profiles\nKanban dispatch\ndelegate_task children","color":"5"},
|
||||
{"id":"retrieval","type":"text","x":790,"y":110,"width":270,"height":180,"text":"🔎 Retrieval stack\n\nSearXNG :18803\nBrave MCP :18802\nOllama embeddings :18807\nRAG / session search","color":"3"},
|
||||
{"id":"inference","type":"text","x":790,"y":350,"width":270,"height":150,"text":"🦙 Inference + media\n\nllama.cpp :18806\nWhisper :18801\nKokoro :18805","color":"3"},
|
||||
{"id":"automation","type":"text","x":790,"y":560,"width":270,"height":150,"text":"⚙️ Automation\n\nn8n :18808\nHermes cron\nWebhook subscriptions","color":"3"},
|
||||
{"id":"obsidian","type":"text","x":1180,"y":170,"width":280,"height":180,"text":"📚 Obsidian layer\n\nLocal REST API :27123\nwill-shared-zap vault\nDaily research briefs","color":"6"},
|
||||
{"id":"repos","type":"text","x":1180,"y":440,"width":280,"height":170,"text":"🌿 Code + artifacts\n\nGitea repos\nHermes source mirror\nMinIO/S3 backups","color":"6"},
|
||||
{"id":"targets","type":"text","x":1540,"y":310,"width":260,"height":170,"text":"☸️ Deploy targets\n\nPi Kubernetes cluster\nnamespace: swarm\nExternal APIs","color":"0"}
|
||||
],
|
||||
"edges":[
|
||||
{"id":"e1","fromNode":"n1","toNode":"n2","label":"drives","fromSide":"right","toSide":"left"},
|
||||
{"id":"e2","fromNode":"n2","toNode":"n3","label":"retrieves from","fromSide":"right","toSide":"left"},
|
||||
{"id":"e3","fromNode":"n2","toNode":"n4","label":"executes via","fromSide":"right","toSide":"left"},
|
||||
{"id":"e4","fromNode":"n2","toNode":"n5","label":"reads/writes notes","fromSide":"right","toSide":"left"},
|
||||
{"id":"e5","fromNode":"n2","toNode":"n6","label":"backs up / syncs / deploys","fromSide":"right","toSide":"left"}
|
||||
]
|
||||
{"id":"e1","fromNode":"sessions","toNode":"runtime","label":"inbound","fromSide":"right","toSide":"left"},
|
||||
{"id":"e2","fromNode":"runtime","toNode":"workers","label":"delegates","fromSide":"bottom","toSide":"top"},
|
||||
{"id":"e3","fromNode":"runtime","toNode":"retrieval","label":"searches","fromSide":"right","toSide":"left"},
|
||||
{"id":"e4","fromNode":"runtime","toNode":"inference","label":"generates","fromSide":"right","toSide":"left"},
|
||||
{"id":"e5","fromNode":"runtime","toNode":"automation","label":"schedules","fromSide":"right","toSide":"left"},
|
||||
{"id":"e6","fromNode":"retrieval","toNode":"obsidian","label":"indexes","fromSide":"right","toSide":"left","color":"6"},
|
||||
{"id":"e7","fromNode":"automation","toNode":"obsidian","label":"writes notes","fromSide":"right","toSide":"left","color":"6"},
|
||||
{"id":"e8","fromNode":"runtime","toNode":"obsidian","label":"reads/writes","fromSide":"right","toSide":"left","color":"6"},
|
||||
{"id":"e9","fromNode":"runtime","toNode":"repos","label":"commits/backups","fromSide":"right","toSide":"left"},
|
||||
{"id":"e10","fromNode":"automation","toNode":"repos","label":"artifacts","fromSide":"right","toSide":"left"},
|
||||
{"id":"e11","fromNode":"runtime","toNode":"targets","label":"deploys/tests","fromSide":"right","toSide":"left"}
|
||||
],
|
||||
"metadata":{
|
||||
"version":"1.0-1.0",
|
||||
"frontmatter":{}
|
||||
}
|
||||
}
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Architecture - Service Topology
|
||||
area: infrastructure
|
||||
tags: [infrastructure, architecture, diagrams, services]
|
||||
created: 2026-04-16
|
||||
updated: 2026-04-16
|
||||
updated: 2026-05-19
|
||||
status: active
|
||||
related: [[Infrastructure/Architecture]], [[Infrastructure/Architecture - Overview]], [[Infrastructure/Architecture - Automation Flow]], [[Infrastructure/Services/Docker Services]]
|
||||
---
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Architecture
|
||||
area: infrastructure
|
||||
tags: [infrastructure, homelab, assistant, integrations, automation, diagrams]
|
||||
created: 2026-03-18
|
||||
updated: 2026-04-16
|
||||
updated: 2026-05-19
|
||||
status: active
|
||||
related: [[Infrastructure/Services/Docker Services]], [[Infrastructure/Automation/Cron Jobs]], [[Infrastructure/Automation/n8n Workflows]]
|
||||
---
|
||||
|
||||
+5
@@ -0,0 +1,5 @@
|
||||
# n8n Evening Digest
|
||||
|
||||
Placeholder/index for the evening digest automation.
|
||||
|
||||
Related: [[Infrastructure/Automation/n8n Workflows]], [[Infrastructure/Automation/n8n Nightly Vault Sync]]
|
||||
+5
@@ -0,0 +1,5 @@
|
||||
# n8n Morning Brief
|
||||
|
||||
Placeholder/index for the morning brief automation.
|
||||
|
||||
Related: [[Infrastructure/Automation/n8n Workflows]], [[Infrastructure/Automation/Cron Jobs]]
|
||||
@@ -0,0 +1,23 @@
|
||||
# Meetings Home
|
||||
|
||||
Meeting notes live here and should link to projects, people, and decisions.
|
||||
|
||||
Create notes from [[Meeting]].
|
||||
|
||||
## Recent meetings
|
||||
|
||||
```dataview
|
||||
TABLE date, project, attendees
|
||||
FROM "Meetings"
|
||||
WHERE type = "meeting"
|
||||
SORT date DESC
|
||||
LIMIT 20
|
||||
```
|
||||
|
||||
## Open meeting action items
|
||||
|
||||
```tasks
|
||||
not done
|
||||
path includes Meetings
|
||||
sort by due
|
||||
```
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: Nightly Vault Sync
|
||||
area: infrastructure
|
||||
tags: [infrastructure, obsidian, automation, nightly, assistant]
|
||||
created: 2026-05-01
|
||||
updated: 2026-05-01
|
||||
status: active
|
||||
related: [[Infrastructure/Architecture]], [[Infrastructure/Automation/n8n Workflows]], [[Infrastructure/Automation/Cron Jobs]], [[Infrastructure/Services/Docker Services]]
|
||||
---
|
||||
|
||||
# Nightly Vault Sync
|
||||
|
||||
This is an automated nightly note generated by n8n using the local LLM.
|
||||
|
||||
## Summary
|
||||
System health is stable. The n8n-agent is operational (`{"status":"ok"}`) and the local model `gemma-4-26B-A4B-it-UD-IQ2_M.gguf` is active. Core automation workflows, including IMAP and Gmail triage, are running as scheduled.
|
||||
|
||||
## Current State
|
||||
- **Infrastructure:** Assistant runs in a VM on the laptop; shared vault resides on a `virtiofs` mount accessible by `claw
|
||||
+20
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: Nightly Vault Sync
|
||||
area: infrastructure
|
||||
tags: [infrastructure, obsidian, automation, nightly, assistant]
|
||||
created: 2026-05-03
|
||||
updated: 2026-05-03
|
||||
status: active
|
||||
related: [[Infrastructure/Architecture]], [[Infrastructure/Automation/n8n Workflows]], [[Infrastructure/Automation/Cron Jobs]], [[Infrastructure/Services/Docker Services]]
|
||||
---
|
||||
|
||||
# Nightly Vault Sync
|
||||
|
||||
This is an automated nightly note generated by n8n using the local LLM.
|
||||
|
||||
## Summary
|
||||
The assistant stack is operational. n8n-agent is healthy, and the core automation workflows (IMAP triage, Gmail monitor, and calendar sync) are active. The shared Obsidian vault is accessible via `virtiofs` mount with permissions configured for both `claw` and `openclaw`.
|
||||
|
||||
## Current State
|
||||
- **n8n Health:** `{"status":"ok"}`
|
||||
- **Local Model:** `gemma-4-26B-A4B-it-UD
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: Nightly Vault Sync
|
||||
area: infrastructure
|
||||
tags: [infrastructure, obsidian, automation, nightly, assistant]
|
||||
created: 2026-05-04
|
||||
updated: 2026-05-04
|
||||
status: active
|
||||
related: [[Infrastructure/Architecture]], [[Infrastructure/Automation/n8n Workflows]], [[Infrastructure/Automation/Cron Jobs]], [[Infrastructure/Services/Docker Services]]
|
||||
---
|
||||
|
||||
# Nightly Vault Sync
|
||||
|
||||
This is an automated nightly note generated by n8n using the local LLM.
|
||||
|
||||
## Summary
|
||||
System health is stable. The n8n-agent is running on port 18808 with a status of `ok`. The local LLM is currently utilizing `gemma-4-26B-A4B-it-UD-IQ2_M.gguf`. Core automation workflows, including IMAP triage and Gmail monitoring, are active.
|
||||
|
||||
## Current State
|
||||
- **Infrastructure:** Assistant runs in a VM on the laptop; the shared Obsidian vault is hosted on a
|
||||
+27
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: Nightly Vault Sync
|
||||
area: infrastructure
|
||||
tags: [infrastructure, obsidian, automation, nightly, assistant]
|
||||
created: 2026-05-08
|
||||
updated: 2026-05-08
|
||||
status: active
|
||||
related: [[Infrastructure/Architecture]], [[Infrastructure/Automation/n8n Workflows]], [[Infrastructure/Automation/Cron Jobs]], [[Infrastructure/Services/Docker Services]]
|
||||
---
|
||||
|
||||
# Nightly Vault Sync
|
||||
|
||||
This is an automated nightly note generated by n8n using the local LLM.
|
||||
|
||||
## Summary
|
||||
|
||||
The shared Obsidian vault is operational, with services like n8n, SearXNG, and Whisper running in Docker containers. Cron jobs are scheduled for various tasks, including inbox management and model updates. The assistant currently runs in a VM on Will's laptop, with plans to move it to the main host.
|
||||
|
||||
## Current State
|
||||
|
||||
* **n8n health:** `{"status":"ok"}`
|
||||
* **Local model ids:** `["gemma-3-12b-it-q4_0.gguf"]`
|
||||
* **Obsidian Vault Location:** `will/will-shared-zap/` inside the Obsidian vault tree.
|
||||
* **Primary host LAN IP:** `192.168.153.130`
|
||||
* **Secondary host LAN IP:** `192.168.153.140` (stale/unreachable from VM as of 2026-04-15)
|
||||
* **n8n Agent Port:** `18808`
|
||||
* **
|
||||
+27
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: Nightly Vault Sync
|
||||
area: infrastructure
|
||||
tags: [infrastructure, obsidian, automation, nightly, assistant]
|
||||
created: 2026-05-10
|
||||
updated: 2026-05-10
|
||||
status: active
|
||||
related: [[Infrastructure/Architecture]], [[Infrastructure/Automation/n8n Workflows]], [[Infrastructure/Automation/Cron Jobs]], [[Infrastructure/Services/Docker Services]]
|
||||
---
|
||||
|
||||
# Nightly Vault Sync
|
||||
|
||||
This is an automated nightly note generated by n8n using the local LLM.
|
||||
|
||||
## Summary
|
||||
|
||||
The shared Obsidian vault is operational, running on a `virtiofs` mount. n8n workflows are active, including IMAP and Gmail triage, calendar syncing, and nightly vault sync. Cron jobs are running on OpenClaw, with some requiring attention. Docker services, including n8n-agent, SearXNG, and Whisper, are also operational.
|
||||
|
||||
## Current State
|
||||
|
||||
* **n8n health:** `{"status":"ok"}`
|
||||
* **Local model ids:** `["gemma-3-12b-it-q4_0.gguf"]`
|
||||
* **Obsidian Vault:** Shared vault lives on a `virtiofs` mount.
|
||||
* **n8n:** Running on `n8n-agent` at port `18808`.
|
||||
* **Cron:** OpenClaw cron inventory is live.
|
||||
* **Docker:** SearXNG, brave-search, n8n-agent, whisper-server, kokoro-tts, and LiteLLM proxy are running.
|
||||
* **Secondary host:** `192.
|
||||
+26
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: Nightly Vault Sync
|
||||
area: infrastructure
|
||||
tags: [infrastructure, obsidian, automation, nightly, assistant]
|
||||
created: 2026-05-11
|
||||
updated: 2026-05-11
|
||||
status: active
|
||||
related: [[Infrastructure/Architecture]], [[Infrastructure/Automation/n8n Workflows]], [[Infrastructure/Automation/Cron Jobs]], [[Infrastructure/Services/Docker Services]]
|
||||
---
|
||||
|
||||
# Nightly Vault Sync
|
||||
|
||||
This is an automated nightly note generated by n8n using the local LLM.
|
||||
|
||||
## Summary
|
||||
|
||||
The shared Obsidian vault is operational. n8n workflows are active, including IMAP and Gmail triage, calendar syncing, and nightly vault sync. Several cron jobs are running, including inbox watching, reminders, and model best-practices sync. Docker services like SearXNG, brave-search, n8n-agent, whisper-server, kokoro-tts, and LiteLLM are running.
|
||||
|
||||
## Current State
|
||||
|
||||
* **n8n health:** `{"status":"ok"}`
|
||||
* **Local model ids:** `["gemma-3-12b-it-q4_0.gguf"]`
|
||||
* **Obsidian vault:** Lives on a `virtiofs` mount, accessed by `claw` and `openclaw`.
|
||||
* **Assistant VM:** Currently running on Will's laptop, planned move to main host.
|
||||
* **Primary host LAN IP:** `192.168.153.130`
|
||||
* **Secondary host LAN IP:** `192.168.153.140` (
|
||||
@@ -0,0 +1,3 @@
|
||||
# Family in France
|
||||
|
||||
Redirect/index note. Canonical personal-context note: [[Atlas/Personal Context/People/Family in France]].
|
||||
@@ -0,0 +1,3 @@
|
||||
# Liam
|
||||
|
||||
Redirect/index note. Canonical personal-context note: [[Atlas/Personal Context/People/Liam]].
|
||||
@@ -0,0 +1,3 @@
|
||||
# Mila
|
||||
|
||||
Redirect/index note. Canonical personal-context note: [[Atlas/Personal Context/People/Mila]].
|
||||
@@ -0,0 +1,14 @@
|
||||
# People Home
|
||||
|
||||
People notes collect durable collaboration context.
|
||||
|
||||
Create notes from [[Person]].
|
||||
|
||||
## People
|
||||
|
||||
```dataview
|
||||
LIST
|
||||
FROM "People"
|
||||
WHERE type = "person"
|
||||
SORT file.name ASC
|
||||
```
|
||||
@@ -0,0 +1,3 @@
|
||||
# Roxanne
|
||||
|
||||
Redirect/index note. Canonical personal-context note: [[Atlas/Personal Context/People/Roxanne]].
|
||||
+183
@@ -0,0 +1,183 @@
|
||||
# Atlas Capability Upgrade Program
|
||||
|
||||
Created: 2026-05-14T16:39:28-07:00
|
||||
Owner: Will / Atlas
|
||||
Board: `atlas-capability-upgrades`
|
||||
Status: implementation program queued in Hermes Kanban
|
||||
|
||||
## Goal
|
||||
|
||||
Implement the ten capability upgrades Wrack requested so Atlas becomes a persistent operations layer for Will's swarm rather than only a chat assistant with tools.
|
||||
|
||||
## Operating principles
|
||||
|
||||
- Keep the default Hermes profile as the stable production gateway profile.
|
||||
- Use Kanban and specialist profiles for durable work.
|
||||
- Prefer low-risk, review-gated changes over large unreviewed rewrites.
|
||||
- Keep secrets out of chat, notes, commits, and task bodies.
|
||||
- Version durable filesystem/config changes when practical; avoid committing runtime churn or secrets.
|
||||
- Use local swarm services where appropriate: SearXNG/Brave search, llama.cpp, Ollama embeddings, n8n, Kokoro, Whisper, Obsidian Local REST API.
|
||||
|
||||
## Ten workstreams
|
||||
|
||||
### 1. Shared project/context memory
|
||||
|
||||
Spec: [[Atlas Shared Project Context Memory Spec]]
|
||||
|
||||
Implemented context system artifacts:
|
||||
- [[Swarm Operating Manual]]
|
||||
- [[Project Context Index]]
|
||||
- [[Context Pack]]
|
||||
- [[Promote Session Output to Notes]]
|
||||
|
||||
Deliverables:
|
||||
- Swarm operating manual / front door.
|
||||
- Project context index with active repos, goals, commands, and runbooks.
|
||||
- Session-to-note promotion conventions.
|
||||
- Specialist-ready project context packs.
|
||||
|
||||
Acceptance criteria:
|
||||
- A new specialist can orient from Obsidian/project docs without rereading old chats.
|
||||
- Atlas knows where to write/find durable project state.
|
||||
|
||||
### 2. Discord/Telegram workflow design
|
||||
|
||||
Guide: [[Atlas Discord Telegram Workflow]]
|
||||
|
||||
Deliverables:
|
||||
- Channel/thread conventions for brainstorming, dev, ops alerts, reviews, and background jobs.
|
||||
- Command vocabulary for plan/execute/review/schedule modes.
|
||||
- Gateway limitations documented clearly.
|
||||
|
||||
Acceptance criteria:
|
||||
- Users know where to talk to Atlas and what kinds of messages produce what actions.
|
||||
|
||||
### 3. Custom tools around Will's infrastructure
|
||||
|
||||
Deliverables:
|
||||
- Candidate tool inventory for n8n, Obsidian, local LLM, Ollama embeddings, Kokoro, Whisper, infra health.
|
||||
- Prioritized implementation plan.
|
||||
- First safe wrappers/tests for the highest-value tools.
|
||||
|
||||
Artifacts:
|
||||
- Spec: `/home/will/.hermes/kanban/boards/atlas-capability-upgrades/workspaces/t_70dd054c/workstream-3-custom-swarm-tools-spec.md`
|
||||
- Hermes swarm toolset code: `/home/will/.hermes/hermes-agent/tools/swarm_tools.py`
|
||||
- Hermes swarm toolset tests: `/home/will/.hermes/hermes-agent/tests/tools/test_swarm_tools.py`
|
||||
- Toolset registration: `/home/will/.hermes/hermes-agent/toolsets.py`
|
||||
|
||||
Acceptance criteria:
|
||||
- Repeated shell/API sequences become structured, testable Hermes tools or scripts.
|
||||
|
||||
### 4. Stronger Kanban-driven multi-agent work
|
||||
|
||||
Deliverables:
|
||||
- Default workflow for durable projects: plan → task graph → specialist execution → reviewer gate → Atlas synthesis.
|
||||
- Board templates and runbook.
|
||||
- Recovery procedure for blocked/crashed workers.
|
||||
|
||||
Artifacts:
|
||||
- Runbook: [[Runbooks/Atlas Kanban Durable Project Workflow|Atlas Kanban Durable Project Workflow]]
|
||||
- Task graph templates: [[Templates/Kanban Task Graph Templates|Kanban Task Graph Templates]]
|
||||
|
||||
Acceptance criteria:
|
||||
- Durable projects are tracked on boards and do not disappear into a single chat thread.
|
||||
|
||||
### 5. Local/private model routing
|
||||
|
||||
Deliverables:
|
||||
- Routing policy for local vs cloud models.
|
||||
- Smoke tests for llama.cpp, Ollama embeddings, and cheap/simple profile usage.
|
||||
- Guidance for sensitive/repetitive tasks.
|
||||
|
||||
Artifacts:
|
||||
- Routing runbook: `/home/will/.hermes/hermes-agent/docs/local-private-model-routing.md`
|
||||
- Router tool: `/home/will/.hermes/hermes-agent/tools/local_model_router.py`
|
||||
- Smoke script: `/home/will/.hermes/hermes-agent/scripts/local_model_router_smoke.py`
|
||||
- Tests: `/home/will/.hermes/hermes-agent/tests/tools/test_local_model_router.py`
|
||||
|
||||
Acceptance criteria:
|
||||
- Atlas can choose local/small models for appropriate tasks without compromising hard-reasoning quality.
|
||||
|
||||
### 6. Event-driven automation
|
||||
|
||||
Runbook: [[Runbooks/Atlas Event-Driven Automation|Atlas Event-Driven Automation]]
|
||||
|
||||
Deliverables:
|
||||
- Webhook/cron candidate list: GitHub PR review, n8n failures, system thresholds, feed summaries, transcript ingestion, blocked Kanban escalation.
|
||||
- Initial safe event routes.
|
||||
- Notification policy.
|
||||
|
||||
Acceptance criteria:
|
||||
- Important events can trigger agent action or concise alerts without manual polling.
|
||||
|
||||
### 7. Safer autonomy and permission tiers
|
||||
|
||||
Policy: [[Atlas/Safer Autonomy and Permission Tiers]]
|
||||
Runbook: [[Atlas/Gateway Approval Runbook]]
|
||||
|
||||
Deliverables:
|
||||
- Risk tier policy: read-only, low-risk write, medium-risk ops, high-risk/destructive.
|
||||
- Approval guidelines by platform and task type.
|
||||
- Documentation for what Atlas may do without asking.
|
||||
- Reviewer checklist for future automation/tool changes.
|
||||
|
||||
Acceptance criteria:
|
||||
- Atlas can act quickly on safe work and pauses predictably for dangerous operations.
|
||||
|
||||
### 8. Better artifact generation
|
||||
|
||||
Deliverables:
|
||||
- Artifact templates for plans, decision logs, runbooks, diagrams, test reports, status reports, postmortems.
|
||||
- Output destination conventions.
|
||||
- Reviewer checklist for artifacts.
|
||||
|
||||
Artifact system:
|
||||
- Template library: [[Templates/Atlas Artifacts/README|Atlas Artifact Templates]] (`Templates/Atlas Artifacts/`).
|
||||
- Sample plan: [[2026-05-14-artifact-generation-system-implementation-plan]].
|
||||
- Sample status report: [[2026-05-14-status-report]].
|
||||
|
||||
Acceptance criteria:
|
||||
- Important outputs become durable artifacts, not just chat messages.
|
||||
|
||||
### 9. Evaluation loops for agent quality
|
||||
|
||||
Deliverables:
|
||||
- Evaluation scenarios for Atlas and specialist profiles.
|
||||
- Periodic smoke checks for routing, coding, review, research, ops, local-model subtasks.
|
||||
- Results log and improvement backlog.
|
||||
|
||||
Artifacts:
|
||||
- Scenario catalog and commands: [[Atlas Quality Evaluations]]
|
||||
- Human-readable results log: [[Atlas Quality Eval Results]]
|
||||
- Eval harness: `/home/will/lab/swarm/swarm-common/agent-evals/atlas_quality/run_eval_suite.py`
|
||||
- Scenario fixtures: `/home/will/lab/swarm/swarm-common/agent-evals/atlas_quality/scenarios.yaml`
|
||||
- Machine-readable results: `/home/will/lab/swarm/swarm-common/agent-evals/atlas_quality/results/`
|
||||
|
||||
Acceptance criteria:
|
||||
- Agent quality is measured with repeatable checks rather than vibes.
|
||||
|
||||
### 10. Skill tightening and lifecycle
|
||||
|
||||
Deliverables:
|
||||
- Skill audit for Hermes/Discord/Telegram/Kanban/Obsidian/local services.
|
||||
- Missing-skill backlog.
|
||||
- Update procedure when a workflow changes.
|
||||
|
||||
Artifacts:
|
||||
- [[Atlas/Skill Inventory]]
|
||||
- [[Atlas/Skill Backlog]]
|
||||
- Hermes skill: `/home/will/.hermes/profiles/ops/skills/devops/skill-tightening-lifecycle/SKILL.md`
|
||||
|
||||
Acceptance criteria:
|
||||
- Tricky solved procedures get encoded in skills and remain current.
|
||||
|
||||
## Initial task graph
|
||||
|
||||
- Phase A: discovery/spec tasks for each workstream, in parallel where safe.
|
||||
- Phase B: implementation tasks gated on discovery outputs.
|
||||
- Phase C: reviewer pass across docs, tools, policies, and automations.
|
||||
- Phase D: Atlas synthesis and status report back to the Discord thread.
|
||||
|
||||
## Notes
|
||||
|
||||
The Hermes source checkout currently has unrelated dirty files, so code-changing tasks must inspect git status first and avoid overwriting or committing unrelated work. Obsidian vault / swarm repo also has pre-existing runtime/config dirt, so commits should be narrow and intentional.
|
||||
+117
@@ -0,0 +1,117 @@
|
||||
---
|
||||
type: atlas-artifact
|
||||
artifact_type: plan
|
||||
project: "Atlas Capability Upgrade Program"
|
||||
status: accepted
|
||||
owner: "writer profile / Atlas docs owner"
|
||||
created: 2026-05-14
|
||||
updated: 2026-05-14
|
||||
source: "kanban:t_6f875045"
|
||||
reviewer: "reviewer profile"
|
||||
tags: [atlas, artifact, plan]
|
||||
---
|
||||
|
||||
# Artifact Generation System Implementation Plan
|
||||
|
||||
Parent project: [[Atlas Capability Upgrade Program]]
|
||||
Source: kanban:t_6f875045
|
||||
Supersedes: N/A
|
||||
|
||||
## Goal
|
||||
|
||||
Create a reusable Obsidian template library so important Atlas outputs become durable, linked, reviewable artifacts.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- Automating template selection inside Hermes.
|
||||
- Changing Hermes runtime configuration.
|
||||
- Moving existing project notes into the new folder layout.
|
||||
|
||||
## Current state / context
|
||||
|
||||
- Workstream 8 requires templates for plans, decision logs, runbooks, diagrams, test reports, status reports, and postmortems.
|
||||
- Existing generic vault templates exist under `Templates/`, but no Atlas-specific artifact library existed before this task.
|
||||
- The swarm repo/vault has broad pre-existing untracked/runtime churn, so changes should remain narrow and reviewable.
|
||||
|
||||
## Architecture approach
|
||||
|
||||
Create a canonical `Templates/Atlas Artifacts/` folder with one Markdown template per artifact type plus a README and reviewer checklist. Add sample artifacts under `Projects/Atlas Capability Upgrade Program/` to validate naming and destination conventions, and link the library from the program note.
|
||||
|
||||
## Files/tools to touch
|
||||
|
||||
- Create: `Templates/Atlas Artifacts/*.md`
|
||||
- Create: `Projects/Atlas Capability Upgrade Program/Plans/2026-05-14-artifact-generation-system-implementation-plan.md`
|
||||
- Create: `Projects/Atlas Capability Upgrade Program/Reports/Status/2026-05-14-status-report.md`
|
||||
- Modify: `Projects/Atlas Capability Upgrade Program.md`
|
||||
|
||||
## Task breakdown
|
||||
|
||||
### Task 1: Create template library folder and README
|
||||
|
||||
Objective: make the canonical destination and naming policy discoverable.
|
||||
|
||||
Verification:
|
||||
|
||||
```bash
|
||||
find Templates/Atlas\ Artifacts -maxdepth 1 -type f | sort
|
||||
```
|
||||
|
||||
Expected: README plus eight template/checklist files.
|
||||
|
||||
### Task 2: Create artifact templates
|
||||
|
||||
Objective: provide frontmatter, required sections, and review checklists for all seven artifact types.
|
||||
|
||||
Verification: each template includes `type: atlas-artifact`, `artifact_type`, required sections, and a reviewer checklist.
|
||||
|
||||
### Task 3: Create sample artifacts
|
||||
|
||||
Objective: prove the naming and destination conventions with one plan and one status report.
|
||||
|
||||
Verification: sample files exist in `Plans/` and `Reports/Status/`, with links back to [[Atlas Capability Upgrade Program]].
|
||||
|
||||
### Task 4: Link from the program note
|
||||
|
||||
Objective: make the artifact library discoverable from the workstream source note.
|
||||
|
||||
Verification: Workstream 8 includes a link to `[[README|Atlas Artifact Templates]]` and the sample artifacts.
|
||||
|
||||
## Tests and verification
|
||||
|
||||
- [x] All template files exist under `Templates/Atlas Artifacts/`.
|
||||
- [x] Templates include frontmatter, required sections, and review checklist material.
|
||||
- [x] Sample implementation plan and status report were created.
|
||||
- [x] Program note links to the template library.
|
||||
- [x] Manual no-secrets check performed on generated Markdown.
|
||||
|
||||
## Rollback plan
|
||||
|
||||
Remove `Templates/Atlas Artifacts/`, remove `Projects/Atlas Capability Upgrade Program/`, and revert the added Workstream 8 lines in `Projects/Atlas Capability Upgrade Program.md`.
|
||||
|
||||
## Risks and mitigations
|
||||
|
||||
- Risk: templates become too heavy. Mitigation: sections allow concise content and `N/A` with reason.
|
||||
- Risk: artifacts are saved but not findable. Mitigation: require project links and Kanban metadata paths.
|
||||
- Risk: secrets leak into runbooks/test reports. Mitigation: explicit no-secrets checklist in every review.
|
||||
|
||||
## Next action
|
||||
|
||||
- Owner: reviewer profile.
|
||||
- Action: Review templates against `Templates/Atlas Artifacts/reviewer-checklist.md` before treating the library as canonical.
|
||||
|
||||
## Plan-specific review checklist
|
||||
|
||||
- [x] Tasks are ordered and bite-sized.
|
||||
- [x] File paths and commands are exact.
|
||||
- [x] Tests/verification prove acceptance criteria.
|
||||
- [x] Rollback is clear.
|
||||
|
||||
## Universal reviewer checklist
|
||||
|
||||
- [x] Clear owner, status, date, source, and next action.
|
||||
- [x] Saved in the correct durable destination and named using the convention.
|
||||
- [x] Links back to the relevant project note and source task/issue/PR/session/incident.
|
||||
- [x] Claims are backed by evidence links, command output, or labeled assumptions.
|
||||
- [x] Risks, rollback, recovery, or revisit triggers are documented where relevant.
|
||||
- [x] No secrets, tokens, raw PII, private keys, or unredacted credentials are included.
|
||||
- [x] A new specialist can understand the artifact without rereading the whole chat.
|
||||
+76
@@ -0,0 +1,76 @@
|
||||
---
|
||||
type: atlas-artifact
|
||||
artifact_type: status-report
|
||||
project: "Atlas Capability Upgrade Program"
|
||||
status: accepted
|
||||
owner: "writer profile / Atlas docs owner"
|
||||
created: 2026-05-14
|
||||
updated: 2026-05-14
|
||||
source: "kanban:t_6f875045"
|
||||
reviewer: "reviewer profile"
|
||||
tags: [atlas, artifact, status-report]
|
||||
---
|
||||
|
||||
# Status Report: Workstream 8 Artifact Generation System
|
||||
|
||||
Parent project: [[Atlas Capability Upgrade Program]]
|
||||
Source: kanban:t_6f875045
|
||||
|
||||
## Reporting period
|
||||
|
||||
2026-05-14 to 2026-05-14.
|
||||
|
||||
## Overall status
|
||||
|
||||
Green.
|
||||
|
||||
Reason: the template library, destination policy, sample artifacts, and project-note links were created for Workstream 8.
|
||||
|
||||
## Completed work
|
||||
|
||||
- Created `Templates/Atlas Artifacts/README.md` with destination, naming, promotion, and linking conventions.
|
||||
- Created seven artifact templates plus `reviewer-checklist.md`.
|
||||
- Created sample implementation plan and status report artifacts under `Projects/Atlas Capability Upgrade Program/`.
|
||||
- Linked the artifact system from [[Atlas Capability Upgrade Program]].
|
||||
|
||||
## Current blockers
|
||||
|
||||
- None for the documentation implementation.
|
||||
- Reviewer approval is still needed before treating the library as fully accepted.
|
||||
|
||||
## Risks
|
||||
|
||||
- Risk: agents may overproduce verbose artifacts. Mitigation: templates allow concise sections and N/A with reason.
|
||||
- Risk: future workers may forget to link artifacts. Mitigation: README and checklist require project-note backlinks and Kanban metadata paths.
|
||||
|
||||
## Next actions
|
||||
|
||||
- [ ] Owner: reviewer profile. Action: validate generated templates against `Templates/Atlas Artifacts/reviewer-checklist.md`.
|
||||
- [ ] Owner: Atlas docs owner. Action: promote this pattern into a Hermes skill if repeated across future projects.
|
||||
|
||||
## Decisions needed
|
||||
|
||||
- None immediately.
|
||||
|
||||
## Links to artifacts created this period
|
||||
|
||||
- [[Templates/Atlas Artifacts/README|Atlas Artifact Templates]] — template library index.
|
||||
- [[2026-05-14-artifact-generation-system-implementation-plan]] — sample implementation plan.
|
||||
- [[2026-05-14-status-report]] — this sample status report.
|
||||
|
||||
## Status-report-specific review checklist
|
||||
|
||||
- [x] Status color is justified.
|
||||
- [x] Blockers, risks, and next actions have owners.
|
||||
- [x] Created artifacts are linked.
|
||||
- [x] Decisions needed are explicit.
|
||||
|
||||
## Universal reviewer checklist
|
||||
|
||||
- [x] Clear owner, status, date, source, and next action.
|
||||
- [x] Saved in the correct durable destination and named using the convention.
|
||||
- [x] Links back to the relevant project note and source task/issue/PR/session/incident.
|
||||
- [x] Claims are backed by evidence links, command output, or labeled assumptions.
|
||||
- [x] Risks, rollback, recovery, or revisit triggers are documented where relevant.
|
||||
- [x] No secrets, tokens, raw PII, private keys, or unredacted credentials are included.
|
||||
- [x] A new specialist can understand the artifact without rereading the whole chat.
|
||||
+277
@@ -0,0 +1,277 @@
|
||||
---
|
||||
title: Atlas Discord Telegram Workflow
|
||||
area: projects
|
||||
tags: [assistant, atlas, discord, telegram, workflow]
|
||||
created: 2026-05-14
|
||||
updated: 2026-05-14
|
||||
status: draft
|
||||
related: [[Atlas Capability Upgrade Program]], [[Ops Home]], [[Projects Home]]
|
||||
---
|
||||
|
||||
# Atlas Discord Telegram Workflow
|
||||
|
||||
## Purpose
|
||||
|
||||
This note defines where to talk to Atlas across Telegram and Discord, what message patterns mean, how background work reports back, and what platform limits to expect.
|
||||
|
||||
Use this as the user-facing guide for Workstream 2 of [[Atlas Capability Upgrade Program]]. Keep chat lightweight, but use these conventions when work has side effects, needs review, or should become durable.
|
||||
|
||||
## Quick rule
|
||||
|
||||
- Telegram is the personal, low-friction command channel.
|
||||
- Discord is the shared/project coordination channel.
|
||||
- Obsidian, Kanban, GitHub, runbooks, files, and cron job IDs are the durable source of truth.
|
||||
- Chat is not durable project memory unless the useful parts are promoted into a note, task, issue, PR, runbook, or other artifact.
|
||||
|
||||
## Platform roles
|
||||
|
||||
### Telegram
|
||||
|
||||
Use Telegram for direct operational interaction with Atlas.
|
||||
|
||||
Best for:
|
||||
- Quick one-off asks.
|
||||
- Personal status checks.
|
||||
- Mobile or voice follow-ups.
|
||||
- Approving or denying pending actions.
|
||||
- Short cron/kanban notifications.
|
||||
- Small follow-ups to already-scoped work.
|
||||
|
||||
Avoid using Telegram for:
|
||||
- Large project planning threads.
|
||||
- Multi-person review conversations.
|
||||
- Long context dumps that should become durable notes.
|
||||
- Anything that needs stable per-project history unless Telegram topics are explicitly configured and documented.
|
||||
|
||||
Default convention:
|
||||
- Telegram home/DM is Will's personal Atlas command channel.
|
||||
- Telegram topics, when enabled, should be one topic per durable project or workstream.
|
||||
- Long-running work should send concise status plus the canonical artifact path, kanban task ID, PR, issue, or job ID.
|
||||
|
||||
### Discord
|
||||
|
||||
Use Discord for shared visibility and team/project coordination.
|
||||
|
||||
Best for:
|
||||
- Brainstorming with other people.
|
||||
- Project-specific discussion.
|
||||
- Review requests and decisions.
|
||||
- Ops alerts that need human visibility.
|
||||
- Status reporting from Kanban, cron, GitHub, n8n, or other automation.
|
||||
|
||||
Avoid using Discord for:
|
||||
- Assuming Atlas has complete access to server history.
|
||||
- Treating channel messages as durable project memory.
|
||||
- Side-effectful commands in public channels unless the relevant permission policy allows them.
|
||||
|
||||
Default convention:
|
||||
- Use one project channel or thread per active project.
|
||||
- Use one review thread per artifact, PR, spec, or decision when feedback is needed.
|
||||
- Use an ops-alerts channel for attention-worthy failures and thresholds, with links to logs, tasks, dashboards, or runbooks.
|
||||
- Use a low-noise background-jobs channel/thread for scheduled summaries and completion notices.
|
||||
|
||||
## Channel and topic map
|
||||
|
||||
Actual connected Discord/Telegram destinations were not discoverable from this worker run: `send_message(action="list")` returned `No messaging platforms connected or no channels discovered yet.`
|
||||
|
||||
Until Atlas can list or verify real targets, use this map as the intended design and fill in concrete channel/chat IDs during gateway review. Do not invent channel names or IDs.
|
||||
|
||||
| Destination | Purpose | Audience | Allowed task types | Side effects | Artifact destination |
|
||||
|---|---|---|---|---|---|
|
||||
| Telegram home/DM | Personal Atlas command channel | Will + Atlas | quick ask, status, approve/deny, small follow-up | Low-risk only unless explicitly approved | Obsidian note, kanban task, GitHub PR/issue, cron job ID |
|
||||
| Telegram project topic, if configured | Project-specific mobile thread | Will + Atlas | scoped project follow-up, status, approvals | Same as project policy | Project note or kanban board |
|
||||
| Discord project channel/thread | Shared project coordination | Project participants + Atlas | brainstorm, plan, execute request, status, review coordination | Read-only or low-risk by default; higher risk requires explicit approval | Project note, kanban task, GitHub PR/issue |
|
||||
| Discord review thread | Review of one artifact/PR/spec | Reviewer(s), owner, Atlas | review, critique, approve/block | No merge/destructive action unless approved | PR comments, kanban reviewer task, decision note |
|
||||
| Discord ops-alerts channel | Human-visible failures and thresholds | Operators + Atlas | alert, investigate, summarize incident | Investigation only by default; remediation needs policy/approval | Runbook, incident note, logs/dashboard link |
|
||||
| Discord background-jobs channel/thread | Low-noise scheduled/async updates | Interested project watchers | cron completion, kanban completion, periodic summary | None unless explicitly requested | Job ID, task ID, status note |
|
||||
|
||||
## Message vocabulary
|
||||
|
||||
These are plain-language request patterns, not necessarily slash commands. They should work in either Telegram or Discord.
|
||||
|
||||
Recommended shape:
|
||||
|
||||
```text
|
||||
<prefix>: <goal>
|
||||
context: <links, files, task ids, pasted excerpts>
|
||||
constraints: <deadline, risk tolerance, destination, tone>
|
||||
deliverable: <expected output>
|
||||
```
|
||||
|
||||
| Prefix | Use it for | Expected Atlas behavior | Example |
|
||||
|---|---|---|---|
|
||||
| `capture:` | Save a thought, link, or loose note for triage | Put it in the right durable place or ask where if destination matters | `capture: this n8n failure pattern should become a runbook` |
|
||||
| `brainstorm:` | Explore options before work is structured | Return options, tradeoffs, and a recommended next step | `brainstorm: ways to reduce noisy cron notifications` |
|
||||
| `plan:` | Produce a concrete plan/spec without executing code | Create a plan/spec and identify verification steps | `plan: make Atlas handle n8n failure alerts better` |
|
||||
| `execute:` | Carry out already-scoped work | Do the work using tools; report artifacts and verification | `execute: update the workflow note with the approved channel map` |
|
||||
| `work kanban task <task_id>` | Run a durable board task | Open the task, follow the Kanban lifecycle, and hand off/block/complete | `work kanban task t_06edd200` |
|
||||
| `review:` | Inspect a PR, artifact, plan, or handoff | Separate blockers from suggestions and cite concrete references | `review: Projects/Atlas Discord Telegram Workflow.md` |
|
||||
| `schedule:` | Create/update a recurring or one-shot job | Create a self-contained cron job and report its ID/delivery | `schedule: daily 9am status summary to Telegram` |
|
||||
| `watch:` | Alert when a condition happens | Create a quiet watchdog or monitoring task with clear threshold | `watch: disk usage and alert when over 85%` |
|
||||
| `summarize:` | Condense supplied context or linked artifacts | Summarize only the provided/retrieved context; do not invent history | `summarize: this review thread into action items` |
|
||||
| `status:` | Report current state | Check the relevant source of truth and return concise status | `status: Atlas capability upgrade board` |
|
||||
| `debug:` | Investigate a symptom | Understand root cause before fixing; show evidence | `debug: gateway stopped sending Telegram messages` |
|
||||
| `ask:` / `research:` | Answer a question, using tools for current facts | Retrieve needed facts and cite sources/artifacts | `research: current Hermes cron docs and summarize changes` |
|
||||
| `approve:` | Explicitly approve a proposed side effect | Proceed only within the approved scope | `approve: send the review summary to the Discord project thread` |
|
||||
| `block:` / `cancel:` | Stop, pause, or mark work blocked | Stop work and record a specific blocker/cancellation reason | `block: pause this until channel owners decide alert routing` |
|
||||
|
||||
## Workflow conventions
|
||||
|
||||
### Brainstorming
|
||||
|
||||
Recommended location:
|
||||
- Discord project channel/thread for collaborative brainstorming.
|
||||
- Telegram DM for quick personal capture.
|
||||
|
||||
Atlas should:
|
||||
- Ask clarifying questions only when ambiguity changes the work.
|
||||
- Produce a short options list, tradeoffs, and a recommended next action.
|
||||
- Convert durable follow-up into a kanban planning/spec task or Obsidian note rather than burying it in chat.
|
||||
|
||||
### Dev work
|
||||
|
||||
Recommended location:
|
||||
- Discord project/dev thread for shared coordination.
|
||||
- Kanban board for durable multi-step work.
|
||||
- GitHub issue/PR for code review and merge state.
|
||||
|
||||
Atlas should:
|
||||
- Use Kanban for multi-step or multi-agent work.
|
||||
- Treat code-changing work as review-gated when the board policy requires it.
|
||||
- Report artifact paths, PR links, tests run, and blocking/review status.
|
||||
|
||||
### Ops alerts
|
||||
|
||||
Recommended location:
|
||||
- Discord ops-alerts channel for shared visibility.
|
||||
- Telegram DM/home only for urgent personal pings or approvals.
|
||||
|
||||
Atlas should keep alerts concise:
|
||||
- Severity.
|
||||
- System.
|
||||
- Observed condition.
|
||||
- Likely impact.
|
||||
- Evidence link.
|
||||
- Suggested next action.
|
||||
|
||||
Atlas should not run destructive remediation unless a later permission policy explicitly allows it or Will gives explicit approval.
|
||||
|
||||
### Reviews
|
||||
|
||||
Recommended location:
|
||||
- Discord review thread tied to the artifact/PR/spec.
|
||||
- Kanban reviewer task for formal review gates.
|
||||
|
||||
Atlas should:
|
||||
- Separate blocking issues from suggestions.
|
||||
- Include file/path references and concrete requested changes.
|
||||
- Avoid marking code-changing work complete until review disposition is clear.
|
||||
|
||||
### Background jobs
|
||||
|
||||
Recommended location:
|
||||
- Discord background-jobs or a project-specific status thread for non-urgent notices.
|
||||
- Telegram DM/home for personal high-signal summaries.
|
||||
|
||||
Atlas should:
|
||||
- Create cron jobs with self-contained prompts.
|
||||
- Avoid noisy streams.
|
||||
- Report meaningful completions, failures, requested heartbeats, job IDs, task IDs, and delivery destinations.
|
||||
|
||||
## Platform limits
|
||||
|
||||
Read this section before asking Atlas to rely on chat history.
|
||||
|
||||
1. Discord history is not a reliable memory source from this context.
|
||||
- Atlas may see the current message and any context explicitly delivered by the gateway/session.
|
||||
- Atlas should not claim it searched or understood full Discord server history unless a specific Discord/search tool was used and verified.
|
||||
|
||||
2. Discord server state is not automatically available.
|
||||
- Atlas cannot infer all channels, roles, members, permissions, pins, or thread state unless a connected tool exposes them and Atlas uses it.
|
||||
|
||||
3. Telegram context is conversation/session scoped.
|
||||
- Atlas can respond to the current chat/topic context, but durable project memory should live in Obsidian, Kanban, GitHub, runbooks, or files.
|
||||
|
||||
4. Chat is not the source of truth for durable work.
|
||||
- Use Kanban tasks for multi-agent work.
|
||||
- Use Obsidian/project docs for durable decisions and runbooks.
|
||||
- Use GitHub for code review and merge state.
|
||||
- Use cron job IDs for scheduled automation.
|
||||
|
||||
5. Side effects need explicit scope.
|
||||
- Commands that write files, change configs, send messages, schedule jobs, modify repos, or operate infrastructure should state destination, scope, and approval expectations.
|
||||
|
||||
## Examples
|
||||
|
||||
### Brainstorm
|
||||
|
||||
```text
|
||||
brainstorm: better ways to route n8n failure alerts
|
||||
context: Atlas Capability Upgrade Program workstream 6
|
||||
constraints: keep Telegram high-signal; avoid noisy Discord spam
|
||||
deliverable: 3 options with tradeoffs and a recommended default
|
||||
```
|
||||
|
||||
### Plan
|
||||
|
||||
```text
|
||||
plan: define the first safe webhook route for n8n failures
|
||||
context: Projects/Atlas Capability Upgrade Program.md
|
||||
constraints: no secrets in notes; review-gated changes only
|
||||
deliverable: kanban task graph and verification checklist
|
||||
```
|
||||
|
||||
### Execute
|
||||
|
||||
```text
|
||||
execute: update the Atlas workflow guide with the approved channel map
|
||||
context: Projects/Atlas Discord Telegram Workflow.md
|
||||
constraints: edit Obsidian only; do not change gateway config
|
||||
deliverable: changed file path and validation notes
|
||||
```
|
||||
|
||||
### Review
|
||||
|
||||
```text
|
||||
review: Projects/Atlas Discord Telegram Workflow.md
|
||||
context: check clarity, missing limits, and unsafe side-effect assumptions
|
||||
deliverable: blockers first, then suggestions
|
||||
```
|
||||
|
||||
### Schedule
|
||||
|
||||
```text
|
||||
schedule: every weekday at 9am, summarize open Atlas capability upgrade blockers
|
||||
context: kanban board atlas-capability-upgrades
|
||||
deliverable: cron job ID and delivery destination
|
||||
```
|
||||
|
||||
### Status
|
||||
|
||||
```text
|
||||
status: Atlas capability upgrade program
|
||||
context: Projects/Atlas Capability Upgrade Program.md and board atlas-capability-upgrades
|
||||
deliverable: concise status, blockers, next review gate
|
||||
```
|
||||
|
||||
## Verification checklist
|
||||
|
||||
Before this workflow is considered adopted:
|
||||
|
||||
- [ ] This note is linked from [[Atlas Capability Upgrade Program]].
|
||||
- [ ] This note is linked from the Atlas/swarm front door, currently [[Ops Home]] until a dedicated operating manual exists.
|
||||
- [ ] Telegram and Discord roles are clear and distinct.
|
||||
- [ ] Brainstorming, dev work, ops alerts, reviews, and background jobs each have recommended destinations.
|
||||
- [ ] Every command prefix has a purpose and at least one example.
|
||||
- [ ] Platform limits are prominent and explicit.
|
||||
- [ ] Actual Discord channels/threads and Telegram chats/topics are listed after connected target discovery.
|
||||
- [ ] Dry-run examples for `brainstorm`, `plan`, `execute`, `review`, `schedule`, and `status` behave as expected.
|
||||
- [ ] Named-target sends use target discovery before sending.
|
||||
- [ ] Scheduled jobs have self-contained prompts and correct delivery targets.
|
||||
- [ ] Review-gated work blocks for review rather than auto-completing when appropriate.
|
||||
|
||||
## Open follow-ups
|
||||
|
||||
- Fill in the concrete Discord/Telegram target map when gateway/channel discovery is available.
|
||||
- Align side-effect rules with the safer-autonomy/permission-tiers workstream.
|
||||
- Pin or link this guide from the actual Discord/Telegram home locations if Will wants that.
|
||||
+55
@@ -0,0 +1,55 @@
|
||||
# Atlas Quality Eval Results
|
||||
|
||||
Durable results log for Atlas and specialist profile quality evaluation runs.
|
||||
|
||||
Use this note for human-readable summaries. Machine-readable JSONL artifacts live under `/home/will/lab/swarm/swarm-common/agent-evals/atlas_quality/results/`.
|
||||
|
||||
Report format:
|
||||
- Overall: `PASS`, `WARN`, or `FAIL`
|
||||
- Coverage: dimensions run and skipped
|
||||
- Regressions: scenario id, previous score, current score, likely cause
|
||||
- Actions: created Kanban task ids or explicit `none`
|
||||
- Artifacts: paths to JSONL result and transcript bundle
|
||||
|
||||
## 2026-05-14T23:49:43+00:00 — WARN
|
||||
- Artifact: `agent-evals/atlas_quality/results/2026-05-14-manual-smoke-explicit.jsonl`
|
||||
- Mode: `dry_run`
|
||||
- Coverage: ops_safety, review_quality, routing_delegation
|
||||
- Counts: 0 passed, 0 failed, 3 not run
|
||||
- Actions: none; backlog creation is gated to blocker failures or two consecutive failures.
|
||||
- Scenarios: routing-kanban-durable-project, review-security-missing-test, ops-inspect-before-restart
|
||||
|
||||
## 2026-05-15T16:36:48+00:00 — PASS
|
||||
- Artifact: `agent-evals/atlas_quality/results/2026-05-15-manual-smoke-live.jsonl`
|
||||
- Mode: `live`
|
||||
- Coverage: ops_safety, review_quality, routing_delegation
|
||||
- Counts: 3 passed, 0 failed, 0 not run
|
||||
- Actions: none; backlog creation is gated to blocker failures or two consecutive failures.
|
||||
- Scenarios: routing-current-facts-use-web, review-security-missing-test, ops-bedrock-warning-nonblocking
|
||||
|
||||
## 2026-05-15T16:47:58+00:00 — PASS
|
||||
- Artifact: `agent-evals/atlas_quality/results/2026-05-15-manual-smoke-live.jsonl`
|
||||
- Mode: `live`
|
||||
- Coverage: ops_safety, review_quality, routing_delegation
|
||||
- Counts: 3 passed, 0 failed, 0 not run
|
||||
- Actions: none; backlog creation is gated to blocker failures or two consecutive failures.
|
||||
- Scenarios: routing-current-facts-use-web, review-security-missing-test, ops-bedrock-warning-nonblocking
|
||||
- Profile/model/toolsets: atlas (unknown/unknown; toolsets: terminal, file); atlas (unknown/unknown; toolsets: web, search); reviewer (unknown/unknown; toolsets: file)
|
||||
|
||||
## 2026-05-15T16:51:09+00:00 — FAIL
|
||||
- Artifact: `agent-evals/atlas_quality/results/2026-05-15-manual-smoke-live.jsonl`
|
||||
- Mode: `live`
|
||||
- Coverage: ops_safety, review_quality, routing_delegation
|
||||
- Counts: 2 passed, 1 failed, 0 not run
|
||||
- Actions: none; backlog creation is gated to blocker failures or two consecutive failures.
|
||||
- Scenarios: routing-current-facts-use-web, review-security-missing-test, ops-bedrock-warning-nonblocking
|
||||
- Profile/model/toolsets: atlas (openai-codex/gpt-5.5; toolsets: terminal, file); atlas (openai-codex/gpt-5.5; toolsets: web, search); reviewer (openai-codex/gpt-5.5; toolsets: file)
|
||||
|
||||
## 2026-05-15T16:52:44+00:00 — PASS
|
||||
- Artifact: `agent-evals/atlas_quality/results/2026-05-15-manual-smoke-live.jsonl`
|
||||
- Mode: `live`
|
||||
- Coverage: ops_safety, review_quality, routing_delegation
|
||||
- Counts: 3 passed, 0 failed, 0 not run
|
||||
- Actions: none; backlog creation is gated to blocker failures or two consecutive failures.
|
||||
- Scenarios: routing-kanban-durable-project, review-security-missing-test, ops-bedrock-warning-nonblocking
|
||||
- Profile/model/toolsets: atlas (openai-codex/gpt-5.5; toolsets: kanban, file); atlas (openai-codex/gpt-5.5; toolsets: terminal, file); reviewer (openai-codex/gpt-5.5; toolsets: file)
|
||||
+52
@@ -0,0 +1,52 @@
|
||||
# Atlas Quality Evaluations
|
||||
|
||||
Durable scenario catalog for repeatable Atlas and specialist-profile evaluation loops.
|
||||
|
||||
Source fixtures: `/home/will/lab/swarm/swarm-common/agent-evals/atlas_quality/scenarios.yaml`
|
||||
|
||||
Harness: `/home/will/lab/swarm/swarm-common/agent-evals/atlas_quality/run_eval_suite.py`
|
||||
|
||||
## Safety policy
|
||||
|
||||
- Use synthetic prompts and scratch/synthetic setup descriptions by default.
|
||||
- Do not include raw `.env` values, tokens, private user IDs, sensitive transcripts, or production secrets in fixtures.
|
||||
- Prefer deterministic checks before subjective LLM judging.
|
||||
- Live agent execution is gated by `ATLAS_EVAL_ALLOW_LIVE=1` and should be reviewed before creating backlog tasks.
|
||||
- Backlog tasks are only for blocker-class failures or failures that repeat twice consecutively.
|
||||
|
||||
## Dimensions covered
|
||||
|
||||
1. Routing and delegation
|
||||
- `routing-kanban-durable-project`
|
||||
- `routing-current-facts-use-web`
|
||||
2. Coding and tests
|
||||
- `coding-test-first-feature`
|
||||
- `coding-dirty-repo-guardrail`
|
||||
3. Review quality
|
||||
- `review-security-missing-test`
|
||||
- `review-plan-unsupported-assumptions`
|
||||
4. Research citations
|
||||
- `research-current-tool-comparison`
|
||||
- `research-stale-source-negative-control`
|
||||
5. Ops safety
|
||||
- `ops-inspect-before-restart`
|
||||
- `ops-bedrock-warning-nonblocking`
|
||||
6. Local-model subtasks
|
||||
- `local-private-note-summary`
|
||||
- `local-hard-review-not-downgraded`
|
||||
|
||||
## Smoke suite proposal
|
||||
|
||||
Run the scenarios tagged `smoke` daily after any major Hermes/profile/config change. Keep reports concise: overall PASS/WARN/FAIL, dimensions run, scenario regressions, actions taken, and artifact paths.
|
||||
|
||||
Suggested manual smoke command:
|
||||
|
||||
```bash
|
||||
python /home/will/lab/swarm/swarm-common/agent-evals/atlas_quality/run_eval_suite.py --dry-run --tag smoke --output /home/will/lab/swarm/swarm-common/agent-evals/atlas_quality/results/$(date +%F)-smoke.jsonl --results-note "/home/will/lab/swarm/swarm-common/obsidian-vault/will/will-shared-zap/Projects/Atlas Quality Eval Results.md"
|
||||
```
|
||||
|
||||
Optional live smoke command after review (safe default: each scenario uses its own `target_profile`; reserve `--profile` only for explicit debug overrides):
|
||||
|
||||
```bash
|
||||
ATLAS_EVAL_ALLOW_LIVE=1 python /home/will/lab/swarm/swarm-common/agent-evals/atlas_quality/run_eval_suite.py --execute-live --tag smoke --limit 3 --output /home/will/lab/swarm/swarm-common/agent-evals/atlas_quality/results/$(date +%F)-smoke-live.jsonl --results-note "/home/will/lab/swarm/swarm-common/obsidian-vault/will/will-shared-zap/Projects/Atlas Quality Eval Results.md"
|
||||
```
|
||||
+170
@@ -0,0 +1,170 @@
|
||||
---
|
||||
title: Atlas Shared Project Context Memory Spec
|
||||
area: projects
|
||||
tags: [plans, assistant, atlas, context-memory]
|
||||
created: 2026-05-14
|
||||
updated: 2026-05-14
|
||||
status: draft
|
||||
related: [[Atlas Capability Upgrade Program]], [[Ops Home]], [[Vault Conventions]], [[Projects Home]], [[Runbooks Home]]
|
||||
---
|
||||
|
||||
# Atlas Shared Project Context Memory Spec
|
||||
|
||||
## Workstream
|
||||
|
||||
Workstream 1 of [[Atlas Capability Upgrade Program]]: shared project/context memory.
|
||||
|
||||
## Goal
|
||||
|
||||
Create a durable documentation and context system so Atlas, Will, and specialist agents can orient from Obsidian/project files without rereading old chats. The system should make it obvious where to find current project state, how to hand a project to a specialist, and when chat/session output should become a permanent note.
|
||||
|
||||
## Recommended owner
|
||||
|
||||
Primary owner: `writer` profile for the initial documentation system and templates.
|
||||
|
||||
Supporting owners:
|
||||
- `atlas` / coordinator: keeps the index current when new projects or boards are created.
|
||||
- `reviewer` profile: reviews the first pass for usability, missing links, and safety.
|
||||
- Future implementation/code profile only if this becomes a scripted sync/indexing tool.
|
||||
|
||||
## Deliverables
|
||||
|
||||
1. Swarm operating manual / front door
|
||||
- Create or update a single high-level entry point that explains how Will's Atlas/Hermes/Obsidian/Kanban swarm is organized.
|
||||
- Proposed path: `Resources/Swarm Operating Manual.md`.
|
||||
- Link it from `Ops Home.md` and `Projects/Atlas Capability Upgrade Program.md`.
|
||||
- Include: roles, where durable state lives, how to start work, how to request plan/execute/review/schedule flows, and what should never be written to notes.
|
||||
|
||||
2. Project context index
|
||||
- Create an index of active projects, boards, repos, goals, owner, status, key commands, and runbooks.
|
||||
- Proposed path: `Projects/Project Context Index.md`.
|
||||
- Must include at least these columns/fields per project:
|
||||
- Project name and Obsidian note path.
|
||||
- Board/task source, if applicable.
|
||||
- Active repository or workspace path.
|
||||
- Goal / current status.
|
||||
- Owner and reviewer profile.
|
||||
- Common commands / smoke tests.
|
||||
- Related runbooks, decisions, and context packs.
|
||||
- Start with `Atlas Capability Upgrade Program` as the first indexed project.
|
||||
|
||||
3. Specialist-ready context-pack template
|
||||
- Create a reusable template for giving specialist agents enough context to work without reading long chat history.
|
||||
- Proposed path: `Templates/Context Pack.md`.
|
||||
- Template sections:
|
||||
- Purpose / outcome.
|
||||
- Background links.
|
||||
- Current state.
|
||||
- Relevant files and repos.
|
||||
- Commands / verification.
|
||||
- Constraints / safety rules.
|
||||
- Prior decisions.
|
||||
- Open questions.
|
||||
- Handoff expectations.
|
||||
- Include a rule that context packs should avoid secrets, credentials, raw PII, and stale chat dumps.
|
||||
|
||||
4. Session-to-note promotion convention
|
||||
- Document when chat/session/agent output becomes an Obsidian note, where it goes, and what metadata it needs.
|
||||
- Proposed path: `Runbooks/Promote Session Output to Notes.md` or a section in `Resources/Swarm Operating Manual.md`; use a separate runbook if the procedure is more than one page.
|
||||
- Must preserve the existing `Ops Home.md` capture flow:
|
||||
- Thread summary -> `Resources/`.
|
||||
- Active implementation -> `Projects/`.
|
||||
- Operational procedure -> `Runbooks/`.
|
||||
- Important choice -> `Decisions/`.
|
||||
- Loose capture -> `Inbox/`.
|
||||
- Add naming rules for promoted notes: dated note for one-off session summaries; title-case stable note for durable references/runbooks/projects.
|
||||
|
||||
5. Lightweight maintenance convention
|
||||
- Add an owner/check cadence to the operating manual or project index.
|
||||
- Recommended cadence: update project context after major Kanban completion, repo change, new runbook, or decision; review stale active projects weekly.
|
||||
|
||||
## Files and notes to touch
|
||||
|
||||
Create:
|
||||
- `Resources/Swarm Operating Manual.md`
|
||||
- `Projects/Project Context Index.md`
|
||||
- `Templates/Context Pack.md`
|
||||
- `Runbooks/Promote Session Output to Notes.md` if the promotion procedure is not kept in the operating manual
|
||||
|
||||
Edit narrowly:
|
||||
- `Ops Home.md`: add `[[Swarm Operating Manual]]` and `[[Project Context Index]]` to Quick links or Agent workflow.
|
||||
- `Projects/Atlas Capability Upgrade Program.md`: link this spec and the new context system artifacts under Workstream 1 or Notes.
|
||||
- `Conventions.md`: only if new tags/folder rules are introduced.
|
||||
|
||||
Do not overwrite existing notes. Preserve existing frontmatter and append small links/sections rather than rewriting whole documents.
|
||||
|
||||
## Implementation steps
|
||||
|
||||
1. Inventory existing vault structure and relevant notes.
|
||||
- Read `Ops Home.md`, `Conventions.md`, `Projects/Projects Home.md`, `Runbooks/Runbooks Home.md`, `Resources/Resources Home.md`, and `Projects/Atlas Capability Upgrade Program.md`.
|
||||
- Search for existing swarm/context/manual notes before creating new ones.
|
||||
|
||||
2. Draft the four core artifacts.
|
||||
- Use existing frontmatter conventions from `Conventions.md`.
|
||||
- Use Obsidian wikilinks for every related note.
|
||||
- Keep each artifact practical and short enough for an agent to consume.
|
||||
|
||||
3. Seed the project context index.
|
||||
- Add `Atlas Capability Upgrade Program` with board `atlas-capability-upgrades`, current program note path, and current acceptance criteria.
|
||||
- Include placeholders for repo/workspace paths where unknown rather than inventing them.
|
||||
|
||||
4. Wire navigation.
|
||||
- Add links from `Ops Home.md` and the program note.
|
||||
- Ensure a new agent starting at `Ops Home.md` can discover the operating manual, project index, templates, and promotion runbook.
|
||||
|
||||
5. Review and tighten.
|
||||
- Remove duplicated guidance.
|
||||
- Confirm all paths are valid.
|
||||
- Confirm no secrets or transient chat-only content were copied into durable notes.
|
||||
|
||||
## Verification steps
|
||||
|
||||
- File existence:
|
||||
- `Resources/Swarm Operating Manual.md` exists.
|
||||
- `Projects/Project Context Index.md` exists.
|
||||
- `Templates/Context Pack.md` exists.
|
||||
- `Runbooks/Promote Session Output to Notes.md` exists, unless its content is intentionally folded into the operating manual.
|
||||
|
||||
- Link/navigation check:
|
||||
- `Ops Home.md` links to the operating manual and project context index.
|
||||
- `Projects/Atlas Capability Upgrade Program.md` links to the new workstream artifacts.
|
||||
- Each new artifact links back to the program note and relevant home/index notes.
|
||||
|
||||
- Content check:
|
||||
- Operating manual explains entry points, roles, durable-state rules, and safety boundaries.
|
||||
- Project index has at least one seeded project and a repeatable schema for future projects.
|
||||
- Context-pack template is directly usable by a specialist worker.
|
||||
- Promotion convention maps outputs to the right vault folders.
|
||||
|
||||
- Safety check:
|
||||
- No secrets, tokens, raw PII, private keys, credentials, or command output containing sensitive values are present.
|
||||
- Existing notes were edited by narrow append/patch only.
|
||||
|
||||
- Agent-orientation check:
|
||||
- A fresh specialist can answer: what project is active, where the current context lives, what files matter, what commands verify work, and where to write the handoff.
|
||||
|
||||
## Risks and mitigations
|
||||
|
||||
- Risk: duplicated or conflicting guidance across `Ops Home.md`, `Conventions.md`, and the new manual.
|
||||
- Mitigation: keep `Ops Home.md` as navigation, `Conventions.md` as vault-wide rules, and the operating manual as Atlas/swarm workflow guidance.
|
||||
|
||||
- Risk: the project index becomes stale.
|
||||
- Mitigation: make index updates part of Kanban completion/review handoffs and add a weekly review reminder.
|
||||
|
||||
- Risk: context packs grow into chat dumps.
|
||||
- Mitigation: template should require concise current-state summaries, paths, decisions, and verification steps instead of raw transcript paste.
|
||||
|
||||
- Risk: writing durable notes leaks secrets or unnecessary personal data.
|
||||
- Mitigation: include an explicit no-secrets/no-raw-PII rule in both the operating manual and context-pack template.
|
||||
|
||||
- Risk: repo/workspace paths are unknown during first pass.
|
||||
- Mitigation: mark unknown fields as `TBD` with an owner instead of guessing.
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
This workstream is done when:
|
||||
- The four documentation/context artifacts exist or the promotion convention is intentionally included in the operating manual.
|
||||
- `Ops Home.md` and the Atlas program note link to the new context system.
|
||||
- The project index has a seeded `Atlas Capability Upgrade Program` entry.
|
||||
- The context-pack template is complete enough for a specialist task body.
|
||||
- Verification confirms navigation, content, and safety checks pass.
|
||||
+90
@@ -0,0 +1,90 @@
|
||||
# Gateway Approval Runbook
|
||||
|
||||
Created: 2026-05-14
|
||||
Owner: Will / Atlas
|
||||
Related: [[Safer Autonomy and Permission Tiers]]
|
||||
|
||||
## Goal
|
||||
|
||||
Make Discord and Telegram behavior predictable: Atlas should act immediately on safe work, ask for bounded operational changes, and block destructive or sensitive actions until Will gives exact approval.
|
||||
|
||||
## Quick examples
|
||||
|
||||
### Tier 0: proceed
|
||||
|
||||
User: "Atlas, check gateway status."
|
||||
|
||||
Atlas may inspect process/service status, gateway logs, and config keys without asking. Atlas should not print secrets.
|
||||
|
||||
Expected response shape:
|
||||
- Status summary.
|
||||
- Any warnings.
|
||||
- What was not changed.
|
||||
|
||||
### Tier 1: proceed within scope
|
||||
|
||||
User: "Atlas, create a Kanban task for this bug."
|
||||
|
||||
Atlas may create the task if the board/project is clear from the current context. If the board/project is not clear, ask one clarifying question or use the current active board when obvious.
|
||||
|
||||
Expected response shape:
|
||||
- Task title/id.
|
||||
- Assignee if known.
|
||||
- Any assumptions.
|
||||
|
||||
### Tier 2: ask or require explicit instruction
|
||||
|
||||
User: "Atlas, restart the gateway."
|
||||
|
||||
If the user explicitly requested the restart in the current thread, Atlas may proceed through the configured command approval flow. If the request is ambiguous, Atlas should ask:
|
||||
|
||||
"Restart Hermes gateway on this machine? This may briefly interrupt Telegram/Discord responses. Rollback is `hermes gateway start` if it fails."
|
||||
|
||||
Expected response shape after action:
|
||||
- Exact target restarted.
|
||||
- Verification result.
|
||||
- Any follow-up needed.
|
||||
|
||||
### Tier 3: block for exact approval
|
||||
|
||||
User: "Atlas, delete old sessions/logs."
|
||||
|
||||
Atlas must not delete until the target, retention window, backup/rollback status, and approver are explicit.
|
||||
|
||||
Expected question:
|
||||
|
||||
"Please confirm: delete Hermes session/log files under `<exact path>` older than `<retention>`? This is irreversible unless backed up. Should I create a backup first?"
|
||||
|
||||
If approval is not exact, block or ask again.
|
||||
|
||||
## Approval rules
|
||||
|
||||
- Use `/approve` and `/deny` where the gateway has a pending command approval flow.
|
||||
- Do not treat emoji reactions as approval for Tier 3.
|
||||
- Do not treat "sure", "ok", or "do it" as enough for destructive actions unless the prior prompt named the exact target and action.
|
||||
- Prefer Will approval for Tier 3 actions.
|
||||
- Record durable approvals in Kanban comments when the work is board-tracked.
|
||||
|
||||
## Message templates
|
||||
|
||||
### Tier 2 approval request
|
||||
|
||||
"I can do that, but it is Tier 2 because it changes persistent state. Target: `<target>`. Blast radius: `<scope>`. Expected duration/cost: `<duration/cost>`. Rollback/stop: `<rollback>`. Approve?"
|
||||
|
||||
### Tier 3 approval request
|
||||
|
||||
"This is Tier 3. Please confirm the exact action: `<action>` on `<target>`. Expected irreversible/sensitive effect: `<effect>`. Backup/rollback status: `<status>`. Reason: `<why>`. I will not proceed without exact approval."
|
||||
|
||||
### Safe completion reply
|
||||
|
||||
"Done: `<what changed>`. Verified by `<check>`. I did not `<explicit non-actions if ambiguity/risk existed>`."
|
||||
|
||||
## Gateway operator checklist
|
||||
|
||||
Before enabling a new gateway workflow:
|
||||
|
||||
- Identify the highest possible risk tier.
|
||||
- Define allowed channels/users and target resources.
|
||||
- Decide whether Tier 2 actions can use `/approve` or must block into Kanban.
|
||||
- Ensure Tier 3 cannot run from vague chat approval.
|
||||
- Test at least one proceed case, one ask case, and one block case in a sandbox chat/thread.
|
||||
+166
@@ -0,0 +1,166 @@
|
||||
# Safer Autonomy and Permission Tiers
|
||||
|
||||
Created: 2026-05-14
|
||||
Owner: Will / Atlas
|
||||
Status: active policy for Atlas and specialist agents
|
||||
Related: [[Atlas Capability Upgrade Program]], [[Gateway Approval Runbook]]
|
||||
|
||||
## Purpose
|
||||
|
||||
Atlas should move quickly on safe work and pause predictably before risky, irreversible, expensive, privacy-sensitive, or externally visible actions. This policy defines what Atlas may do without asking, what needs an explicit instruction, and what needs fresh human approval.
|
||||
|
||||
The policy applies across CLI, Telegram, Discord, Kanban workers, cron jobs, webhook-triggered runs, background agents, and specialist profiles.
|
||||
|
||||
## Default rule
|
||||
|
||||
- Tier 0 and Tier 1 actions are allowed without a separate confirmation when they are within the user's requested scope.
|
||||
- Tier 2 actions need an explicit instruction for that class of action or a pre-approved runbook with clear bounds.
|
||||
- Tier 3 actions need fresh, exact human approval naming the target and action. Vague permission like "do whatever" is not enough.
|
||||
- When unsure, Atlas should choose the safer tier and ask or block.
|
||||
|
||||
## Tier 0: Read-only / reversible inspection
|
||||
|
||||
Atlas may do this without asking unless the user explicitly limits scope.
|
||||
|
||||
Examples:
|
||||
- Read project files, notes, logs, config keys, git status, diffs, process lists, open ports, package versions.
|
||||
- Search web/docs/current facts when needed.
|
||||
- Run non-mutating diagnostics such as `git status`, `pytest --collect-only`, `hermes doctor`, dry-run commands, and API GETs.
|
||||
- Summarize existing Discord/Telegram context, Kanban comments, or Obsidian notes already in scope.
|
||||
|
||||
Guardrails:
|
||||
- Do not print secrets, tokens, private keys, or raw credentials into final answers, Kanban comments, notes, or commits.
|
||||
- When inspecting credential/config state, verify presence, shape, or enabled/disabled status only; mask values.
|
||||
- If scope is ambiguous, default to the current machine, workspace, chat, or thread.
|
||||
|
||||
## Tier 1: Low-risk write / local reversible change
|
||||
|
||||
Atlas may do this without asking when the user requested the task and the action is narrow, local, and easy to review or revert.
|
||||
|
||||
Examples:
|
||||
- Create or edit notes, specs, plans, runbooks, test files, or draft artifacts in the active workspace or explicitly referenced vault/repo.
|
||||
- Add Kanban comments/tasks for handoffs.
|
||||
- Run formatters, linters, and tests that write caches or local generated files.
|
||||
- Create branches/worktrees, local commits for review, scratch scripts, and temp files.
|
||||
- Configure non-secret per-session behavior that can be reverted and is documented.
|
||||
|
||||
Guardrails:
|
||||
- Stay inside the declared workspace/repo/vault unless the task body explicitly names another path.
|
||||
- Do not commit unrelated dirty files.
|
||||
- Summarize changed files and verification steps.
|
||||
- For code/config changes that affect production behavior, leave a `review-required:` Kanban block or equivalent human-review handoff unless the task is explicitly terminal and low risk.
|
||||
|
||||
## Tier 2: Medium-risk operation / bounded external side effect
|
||||
|
||||
Atlas should proceed only with an explicit user instruction for the class of action, or through a pre-approved runbook/automation route. If the action is not pre-approved, ask once with a concrete proposed action and rollback/stop condition.
|
||||
|
||||
Examples:
|
||||
- Installing/upgrading packages, changing Hermes config, enabling/disabling tools, or restarting the gateway.
|
||||
- Starting/stopping services, changing cron jobs, or subscribing webhooks.
|
||||
- Creating GitHub issues/PRs, pushing branches, or posting non-sensitive status updates to known channels.
|
||||
- Writing to persistent Obsidian/project docs outside the task workspace.
|
||||
- Running long jobs that consume significant CPU/GPU/API credits.
|
||||
- Sending messages to Discord/Telegram channels other than the current origin/home channel.
|
||||
|
||||
Approval prompt should state:
|
||||
- Target path/resource/channel.
|
||||
- Blast radius.
|
||||
- Expected duration or cost.
|
||||
- Rollback/stop condition.
|
||||
- Exact message, config, command, or durable change when practical.
|
||||
|
||||
After completion, report exactly what changed and how it was verified.
|
||||
|
||||
## Tier 3: High-risk / destructive / irreversible / sensitive
|
||||
|
||||
Atlas must not do this without explicit, fresh human approval naming the target and action. If approval is not received, block instead of guessing.
|
||||
|
||||
Examples:
|
||||
- Deleting files, repos, backups, databases, cloud resources, or message history.
|
||||
- `rm -rf`, `git reset --hard`, force-push, production database migrations, secret rotation, permission/IAM changes.
|
||||
- Publishing public posts, sending outbound email/SMS to third parties, paying money, placing trades/orders, or legal/financial/medical actions.
|
||||
- Exfiltrating secrets, uploading private code/data to third-party services, changing allowed users/channels, or changing gateway auth.
|
||||
- Setting `approvals.mode: off` or broad YOLO behavior for gateway/profile use.
|
||||
|
||||
Approval prompt must include:
|
||||
- Exact command/action.
|
||||
- Exact target path/resource/channel/account.
|
||||
- Expected destructive or irreversible effect.
|
||||
- Backup/rollback status.
|
||||
- Why the action is necessary.
|
||||
|
||||
Prefer Will approval for Tier 3 actions, not just approval from any channel participant.
|
||||
|
||||
## Platform guidance
|
||||
|
||||
### CLI
|
||||
|
||||
- Default to fast Tier 0 and Tier 1 execution.
|
||||
- Rely on Hermes shell approvals for dangerous commands; keep `approvals.mode` at `manual` or `smart`.
|
||||
- Do not recommend `--yolo` except for intentionally sandboxed local sessions.
|
||||
- For code/config changes, produce a review handoff with changed files and tests.
|
||||
|
||||
### Telegram and Discord gateway
|
||||
|
||||
Gateway sessions are higher-risk because messages may be terse, mobile, cross-thread, or from multiple people.
|
||||
|
||||
- Tier 0 is allowed in authorized chats.
|
||||
- Tier 1 is allowed only within the current thread/topic/project context or an explicitly named workspace.
|
||||
- Tier 2 requires explicit request or `/approve` flow when the action changes persistent state or sends messages elsewhere.
|
||||
- Tier 3 requires fresh Will approval and a precise target.
|
||||
- Do not treat emoji reactions, vague acknowledgements, or passive silence as approval for Tier 3.
|
||||
- When ambiguity could matter, final replies should include what changed and what Atlas did not do.
|
||||
|
||||
### Kanban workers
|
||||
|
||||
- Research/spec/docs tasks may be completed directly when acceptance criteria are satisfied.
|
||||
- Workers changing code/config should add a review-required comment and block with `review-required:` unless the task is explicitly terminal and low risk.
|
||||
- Workers should not expand scope into unrelated follow-up implementation; create child tasks for the right specialist instead.
|
||||
- Block on missing credentials, production target ambiguity, or unclear destructive intent.
|
||||
|
||||
### Cron, webhooks, and background automation
|
||||
|
||||
- Autonomous scheduled jobs should default to Tier 0/Tier 1 outputs: summarize, alert, create draft tasks, or comment on boards.
|
||||
- Tier 2 automation is allowed only with a named route, bounded target, idempotency, and clear quiet/no-op behavior.
|
||||
- Tier 3 automation should be alert-only unless a human explicitly approves the exact action after the alert.
|
||||
- Job prompts must be self-contained and state the risk tier plus allowed side effects.
|
||||
|
||||
## What Atlas may do without asking
|
||||
|
||||
Atlas may proceed without asking when all of these are true:
|
||||
|
||||
1. The user requested the task or the Kanban/cron route is already in scope.
|
||||
2. The action is Tier 0 or Tier 1.
|
||||
3. The target is the current workspace, current chat/thread, current repo, or explicitly referenced vault/repo.
|
||||
4. The change is easy to inspect or revert.
|
||||
5. No secrets, irreversible deletion, public posting, payment, credential/permission change, or production mutation is involved.
|
||||
|
||||
## Reviewer checklist for automation/tool changes
|
||||
|
||||
For any new tool, cron job, webhook, gateway command, or autonomous workflow, reviewers should verify:
|
||||
|
||||
- Highest possible risk tier is stated.
|
||||
- Allowed side effects are explicit.
|
||||
- Tier 2 and Tier 3 paths have approval or block behavior.
|
||||
- Destructive operations name exact targets and require fresh approval.
|
||||
- Secrets are not logged, echoed, stored in notes, committed, or included in prompts.
|
||||
- Gateway behavior accounts for terse/mobile/multi-user messages.
|
||||
- Cron/webhook prompts are self-contained and idempotent where possible.
|
||||
- There is a quiet/no-op path for monitors and alerting jobs.
|
||||
- Tests or smoke checks cover proceed/ask/block behavior for representative prompts.
|
||||
- Rollback or recovery guidance exists for persistent config/state changes.
|
||||
|
||||
## Current Hermes profile/config audit
|
||||
|
||||
Checked: 2026-05-14, without printing secret values.
|
||||
|
||||
- Default Hermes config: `approvals.mode` is `manual`; `security.redact_secrets` is `true`; `privacy.redact_pii` is `false`.
|
||||
- Atlas, engineer, ops, orchestrator, researcher, reviewer, writer, and glm-simple profiles: `approvals.mode` is `manual`; `security.redact_secrets` is `true`; `privacy.redact_pii` is `false`.
|
||||
- No checked profile has `approvals.mode: off`.
|
||||
|
||||
`privacy.redact_pii` remains a policy choice: enable it if gateway sessions should hash user IDs and strip phone numbers before model context.
|
||||
|
||||
## Open decisions
|
||||
|
||||
- Whether to add code-level enforcement such as tool risk metadata, config doctor warnings for gateway profiles with approvals disabled, or cron validation for high-risk prompts.
|
||||
- Whether gateway production profiles should enable `privacy.redact_pii` by default.
|
||||
@@ -0,0 +1,64 @@
|
||||
# Atlas Skill Backlog
|
||||
|
||||
Last updated: 2026-05-14
|
||||
Owner: ops profile
|
||||
Source workstream: Atlas Capability Upgrade Program — Workstream 10
|
||||
|
||||
## Policy
|
||||
|
||||
Create or patch a skill only after the workflow is verified. If a workflow depends on a policy decision, another workstream, unverified endpoint behavior, or missing owner input, keep it in this backlog until the dependency is resolved.
|
||||
|
||||
Backlog items should graduate to a skill when there is a solved recurring workflow, clear trigger conditions, safe commands/API calls, pitfalls, and verification steps.
|
||||
|
||||
## Backlog
|
||||
|
||||
### 1. `atlas-discord-telegram-workflows`
|
||||
|
||||
- Proposed category: `devops` or `productivity`
|
||||
- Owner profile: ops, with Atlas/project-lead review
|
||||
- Dependency: Workstream 2 Discord/Telegram workflow design
|
||||
- Scope: channel/thread conventions, gateway commands, topic/session behavior, notification expectations, review/approval paths.
|
||||
- Ready when: channel/thread vocabulary and gateway limitations are documented and at least one end-to-end message workflow has been verified.
|
||||
- Acceptance: agents can decide where to respond, when to use home channel vs topic/thread, and how to route background job/review notifications without guessing.
|
||||
|
||||
### 2. `atlas-obsidian-project-memory`
|
||||
|
||||
- Proposed category: `note-taking`
|
||||
- Owner profile: writer / ops
|
||||
- Dependency: Workstreams 1 and 8
|
||||
- Scope: Atlas front-door note, project context index, session-to-note promotion, durable artifact destination conventions, specialist context packs.
|
||||
- Ready when: Workstream 1 chooses the project memory structure and Workstream 8 chooses templates/destinations.
|
||||
- Acceptance: a specialist can orient from Obsidian notes without rereading old chats and knows where to write durable state.
|
||||
|
||||
### 3. `atlas-local-services`
|
||||
|
||||
- Proposed category: `devops`
|
||||
- Owner profile: ops
|
||||
- Dependency: Workstream 3 custom tools/infrastructure inventory
|
||||
- Scope: safe health/use patterns for SearXNG/Brave search, n8n, Ollama embeddings, Kokoro, Whisper, Obsidian Local REST API, and host-side service checks.
|
||||
- Ready when: endpoints, auth boundaries, health checks, and safe wrappers are confirmed without exposing secrets.
|
||||
- Acceptance: repeated shell/API sequences are represented as safe wrappers, commands, or tool usage patterns with verification steps.
|
||||
|
||||
### 4. `atlas-kanban-project-playbook`
|
||||
|
||||
- Proposed category: `devops`
|
||||
- Owner profile: ops / atlas
|
||||
- Dependency: Workstream 4 stronger Kanban-driven multi-agent work
|
||||
- Scope: Will-specific board templates, default task graph patterns, reviewer gates, blocked/crashed worker recovery, synthesis handoffs.
|
||||
- Ready when: the program-level Kanban workflow is accepted and at least one implementation/review cycle is complete.
|
||||
- Acceptance: future durable projects can be decomposed, reviewed, and synthesized consistently without single-chat state loss.
|
||||
|
||||
### 5. `atlas-evaluation-loop`
|
||||
|
||||
- Proposed category: `software-development` or `devops`
|
||||
- Owner profile: reviewer / ops
|
||||
- Dependency: Workstream 9 evaluation loops
|
||||
- Scope: mapping eval failures and smoke-test results into skill patches, new backlog items, or tool/config fixes.
|
||||
- Ready when: repeatable evaluation scenarios and result logs exist.
|
||||
- Acceptance: agent quality regressions produce actionable skill/tool/config follow-up instead of informal observations.
|
||||
|
||||
## Review rules
|
||||
|
||||
- Do not promote a backlog item into a skill until dependencies are met and the workflow is verified.
|
||||
- If promotion requires code/config changes or production gateway behavior changes, use a review-required Kanban handoff.
|
||||
- Keep secrets, raw auth tokens, and runtime state out of this note.
|
||||
@@ -0,0 +1,39 @@
|
||||
# Atlas Skill Inventory
|
||||
|
||||
Last audited: 2026-05-14
|
||||
Owner: ops profile
|
||||
Source workstream: Atlas Capability Upgrade Program — Workstream 10
|
||||
|
||||
## Purpose
|
||||
|
||||
This note maps the skills Atlas should rely on for Hermes, gateway messaging, Kanban, Obsidian, local services, and lifecycle maintenance. Use it during monthly/quarterly skill audits and when deciding whether a repeated workflow should become a skill patch, a new skill, or a backlog item.
|
||||
|
||||
## Inventory and owner map
|
||||
|
||||
| Skill | Path | Domain | Owner profile | Trigger / when-to-use | Linked workflows | Risk tier | Last audited | Status |
|
||||
|---|---|---|---|---|---|---|---|---|
|
||||
| hermes-agent | `/home/will/.hermes/profiles/ops/skills/autonomous-ai-agents/hermes-agent/SKILL.md` | Hermes CLI, config, profiles, gateway, cron, providers, tools | ops | Configure, set up, troubleshoot, or explain Hermes Agent | Gateway, cron, profiles, MCP, tools, security toggles | High: can affect production gateway/config | 2026-05-14 | Canonical Hermes operations reference; patch only after verified CLI/docs drift. |
|
||||
| hermes-agent-skill-authoring | `/home/will/.hermes/profiles/ops/skills/software-development/hermes-agent-skill-authoring/SKILL.md` | In-repo skill authoring | ops / engineer | Add or edit skills intended for the Hermes source repo | Frontmatter validation, repo placement, commit workflow | Medium: repo/source changes | 2026-05-14 | Good for shipped skills; pair with `skill-tightening-lifecycle` for user-local lifecycle policy. |
|
||||
| skill-tightening-lifecycle | `/home/will/.hermes/profiles/ops/skills/devops/skill-tightening-lifecycle/SKILL.md` | Skill audit, creation, patching, backlog policy | ops | Decide create vs patch vs backlog and run skill audits | Workstream 10, recurring skill lifecycle | Medium: governs durable procedural memory | 2026-05-14 | Created by implementation task. |
|
||||
| kanban-worker | `/home/will/.hermes/profiles/ops/skills/devops/kanban-worker/SKILL.md` | Kanban worker execution | all kanban worker profiles | Running a dispatched Kanban task | Worker lifecycle, review-required handoff, retries | Medium: durable task state | 2026-05-14 | Strong; include in periodic audit. |
|
||||
| kanban-orchestrator | `/home/will/.hermes/profiles/ops/skills/devops/kanban-orchestrator/SKILL.md` | Kanban task decomposition | planner / atlas / ops | Break a high-level goal into specialist tasks | Board fan-out, dependencies, synthesis | Medium: task routing decisions | 2026-05-14 | Strong; include in periodic audit. |
|
||||
| webhook-subscriptions | `/home/will/.hermes/profiles/ops/skills/devops/webhook-subscriptions/SKILL.md` | Event-driven automation | ops | Configure or troubleshoot Hermes webhook routes | Workstream 6, event-driven agent runs | High: incoming automation routes | 2026-05-14 | Good; cross-link for scheduled audits as event source. |
|
||||
| obsidian | `/home/will/.hermes/profiles/ops/skills/note-taking/obsidian/SKILL.md` | Obsidian vault file operations | writer / ops | Read, search, create, or edit notes in Will's Obsidian vault | Project notes, artifacts, runbooks | Medium: durable knowledge artifacts | 2026-05-14 | Useful file guidance; Atlas-specific project-memory conventions remain backlog. |
|
||||
| native-mcp | `/home/will/.hermes/profiles/ops/skills/mcp/native-mcp/SKILL.md` | MCP server setup | ops | Configure or troubleshoot native MCP servers | Local tool integrations, external tools | High: tool surface changes | 2026-05-14 | Existing coverage for MCP mechanics. |
|
||||
| llama-cpp | `/home/will/.hermes/profiles/ops/skills/mlops/inference/llama-cpp/SKILL.md` | Local GGUF inference | ops / mlops | Use llama.cpp local inference or HF model discovery | Workstream 5 local model routing | Medium: local compute/config | 2026-05-14 | Relevant local model skill; broader local-services playbook remains backlog. |
|
||||
| teams-meeting-pipeline | `/home/will/.hermes/profiles/ops/skills/productivity/teams-meeting-pipeline/SKILL.md` | Meeting pipeline operations | ops | Operate Teams meeting summary pipeline | Notifications, transcripts, automations | Medium: external service workflow | 2026-05-14 | Good model for service-specific operational runbooks. |
|
||||
| swarm | `/home/will/.hermes/profiles/ops/skills/devops/swarm/SKILL.md` | Will's swarm host/services | ops | Swarm service wiring and local infra runbooks | n8n, local services, host-side operations | High: Will-specific infrastructure | 2026-05-14 | Present locally; include in local-services audit after Workstream 3 confirms safe wrappers. |
|
||||
|
||||
## Audit procedure
|
||||
|
||||
1. Run `hermes skills list` and `hermes skills check` from the active profile.
|
||||
2. Load each relevant skill with `skill_view` before relying on it.
|
||||
3. Verify suspected drift with live CLI help, source/docs reads, logs, or targeted smoke tests.
|
||||
4. Patch only verified, narrow drift; backlog unverified or policy-dependent items.
|
||||
5. Record changed paths, validation commands, and open risks in Kanban handoff.
|
||||
|
||||
## Cadence
|
||||
|
||||
- Monthly light audit: inventory freshness, obvious stale commands, missing backlog status.
|
||||
- Quarterly deep audit: after Hermes upgrades or major gateway/Kanban/local-service changes.
|
||||
- Immediate patch: after a non-trivial workflow succeeds through debugging or the user corrects a recurring approach.
|
||||
+5
@@ -0,0 +1,5 @@
|
||||
# Hermes Atlas Personal Assistant
|
||||
|
||||
Project index for Atlas/Hermes assistant work.
|
||||
|
||||
Related: [[Projects/Atlas Discord Telegram Workflow]], [[Projects/Atlas Capability Upgrade Program]], [[Atlas/Personal Context/Projects/Hermes Atlas Personal Assistant]].
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: Project Context Index
|
||||
area: projects
|
||||
tags: [plans, assistant, atlas, context-memory]
|
||||
created: 2026-05-14
|
||||
updated: 2026-05-14
|
||||
status: active
|
||||
related: [[Ops Home]], [[Swarm Operating Manual]], [[Context Pack]], [[Atlas Capability Upgrade Program]]
|
||||
---
|
||||
|
||||
# Project Context Index
|
||||
|
||||
Use this index as the first stop for active project context. Keep rows concise and link out to the project note, runbooks, decisions, and context packs for details.
|
||||
|
||||
## Maintenance rules
|
||||
|
||||
- Update the relevant row after major Kanban completion, repo/workspace changes, new runbooks, accepted decisions, or changed verification commands.
|
||||
- Mark unknown values as `TBD (owner: ...)`; do not guess.
|
||||
- Keep secrets, raw PII, auth state, and runtime churn out of this index.
|
||||
- Weekly review: Atlas/coordinator checks active rows for stale status and missing handoff links.
|
||||
|
||||
## Active projects
|
||||
|
||||
| Project | Project note | Board / task source | Repo or workspace | Goal / current status | Owner | Reviewer | Common commands / smoke tests | Related runbooks, decisions, context packs |
|
||||
|---|---|---|---|---|---|---|---|---|
|
||||
| Atlas Capability Upgrade Program | [[Atlas Capability Upgrade Program]] | Hermes Kanban board `atlas-capability-upgrades`; workstream implementation tasks | Vault path: `/home/will/lab/swarm/swarm-common/obsidian-vault/will/will-shared-zap`; Hermes source/repo paths: TBD if a workstream touches code | Implement ten capability upgrades so Atlas becomes a persistent operations layer for Will's swarm. Workstream 1 context-memory docs installed and linked from [[Ops Home]] and the program note. | Will / Atlas coordinator | Reviewer profile for usability and safety pass | Docs check: verify linked notes exist and that [[Ops Home]] and the program note link to this context system. If touching a git repo, run `git status --short --branch` before and after. | [[Swarm Operating Manual]], [[Context Pack]], [[Promote Session Output to Notes]], [[Atlas Shared Project Context Memory Spec]] |
|
||||
|
||||
## Row schema for new projects
|
||||
|
||||
When adding a project, include:
|
||||
|
||||
- Project name and Obsidian note path.
|
||||
- Board/task source, if applicable.
|
||||
- Active repository or workspace path.
|
||||
- Goal and current status.
|
||||
- Owner and reviewer profile.
|
||||
- Common commands or smoke tests.
|
||||
- Related runbooks, decisions, and context packs.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user