Sync with live vault: 28 new files, 7 imports, 16 updates
This commit is contained in:
@@ -0,0 +1,15 @@
|
||||
# Agent Discussion Log
|
||||
|
||||
> Coordination channel between Jimmy (Hermes) and Leonard.
|
||||
> Format: date + name + message, newest at top.
|
||||
> Only loop Anthony in for final plan approval or when blocked.
|
||||
|
||||
---
|
||||
|
||||
## Pending Messages
|
||||
|
||||
<!-- New pending messages appear here -->
|
||||
|
||||
## Discussion History
|
||||
|
||||
<!-- Completed discussions below -->
|
||||
@@ -0,0 +1,88 @@
|
||||
# Decision Log — Agent OS Architecture
|
||||
|
||||
Records key architectural decisions for the Personal Agent OS.
|
||||
|
||||
## 2026-06-20: Initial Repo Structure
|
||||
|
||||
**Decision:** Created `personal-agent-os` as a single repo under `Tony_tech` org with `projects/`, `knowledge-base/`, `archive/`, `templates/`, `agent-config/`, and `_meta/`.
|
||||
|
||||
**Rationale:**
|
||||
- Single repo over multiple repos: easier for Hermes to search_files across everything, simpler cross-referencing between projects and knowledge
|
||||
- `archive/` over deletion: git history preserves everything, but active views stay clean
|
||||
- `_meta/` at root (not under kb): repo-wide conventions and decision log should be immediately discoverable
|
||||
- No auto-generating tag index in a folder: better to rebuild via cron script periodically
|
||||
|
||||
**Migrated from:** `Tony_tech/research/hermes-automation/` into `knowledge-base/automation-blueprints/hermes/`
|
||||
|
||||
**Trade-offs accepted:**
|
||||
- Single repo means one default branch; projects share tag space (mitigated by hierarchical dir names)
|
||||
- Cron scripts stored in two places: local disk (runs from) and repo (documentation). Must keep in sync.
|
||||
|
||||
## 2026-06-20: Daily Brief — Script + Context-From Pattern
|
||||
|
||||
**Decision:** Replaced agent-driven web/X search data gathering with a no-agent shell script that fetches free public APIs (wttr.in, HN Firebase, GitHub API).
|
||||
|
||||
**Why:** web_search and x_search were silently failing (Firecrawl unconfigured, xAI credits exhausted). The brief was returning `[SILENT]` for weeks.
|
||||
|
||||
**Result:** Working brief in <5 minutes, zero API costs, reliable data every tick.
|
||||
|
||||
**Cron job ID:** e94447937052
|
||||
|
||||
## 2026-07-12: GitHub Excluded from AI News Daily Feed
|
||||
|
||||
**Decision:** GitHub repos are excluded from the AI News Daily site feed (`generate_from_athena.py`). Athena still ingests them into `oracle.db` for research; the site generator filters them out.
|
||||
|
||||
**Rationale:**
|
||||
- GitHub entries (repo releases, model cards) are tool announcements, not news events
|
||||
- They dominated the feed due to high star-velocity scores (GLM-5.2, DeepSeek-R1, etc.)
|
||||
- A "Breaking" tag on a repo release violates the editorial rule: repos/papers are never breaking
|
||||
- GitHub was silently reappearing in the feed at least once this week despite prior exclusion — root cause not conclusively identified (possibly a reverted patch, config drift, or manual override)
|
||||
|
||||
**Implementation:** `generate_from_athena.py` filters `source IN ('github', 'gitlab', 'huggingface', 'arxiv')` → renders as plain links or drops entirely. This is a runtime filter, not a pipeline-level exclusion — Athena's DB still has the data.
|
||||
|
||||
**Trade-offs accepted:**
|
||||
- Some genuinely interesting repos won't appear on the site (acceptable — site is for news, not discovery)
|
||||
- If GitHub exclusion is ever reversed, it requires an explicit commit + decision-log entry, not an ad-hoc patch
|
||||
- Root cause of the silent revert is not conclusively identified; this entry documents the symptom and the fix, not a proven cause
|
||||
|
||||
## 2026-07-12: Score-Floor Tiering Replaces Percentile Gates
|
||||
|
||||
**Decision:** AI News Daily tiering (breaking/update/normal) uses absolute score floors + rank, not percentile cutoffs. A tier is allowed to be empty if nothing qualifies.
|
||||
|
||||
**Rationale:**
|
||||
- Previous system: `BREAKING_PCT = 0.90` (top 10%), `UPDATE_PCT = 0.75` (next 25%) — this guaranteed something always appeared in each tier regardless of quality
|
||||
- Result: 6 red + 15 green items in a single run because rank alone forced items into tiers
|
||||
- New system: `min_score` floor per tier; if nothing clears the bar, the tier is empty
|
||||
- Tiers must reflect editorial quality, not statistical inevitability
|
||||
|
||||
**Implementation:** `config.yaml` defines `tiering.breaking.min_score` and `tiering.update.min_score`. Generator script reads these at runtime. Floors set from real score distribution analysis (see score distribution in oracle.db).
|
||||
|
||||
**Trade-offs accepted:**
|
||||
- Some runs may have zero "Breaking" items — this is correct behavior, not a bug
|
||||
- Score floors require periodic review as the score distribution evolves
|
||||
|
||||
## 2026-07-12: "UPDATE" Text Label Dropped (Color-Only for Tier 2)
|
||||
|
||||
**Decision:** Tier 2 (update) items render in green (`#34a83d`) without a "UPDATE | " text prefix. Breaking items retain "Breaking | " prefix.
|
||||
|
||||
**Rationale:**
|
||||
- "UPDATE | " prefix was visually noisy and implied a correction/follow-up relationship that doesn't exist for most tier-2 items
|
||||
- Green color alone provides sufficient visual distinction from normal (black) and breaking (red)
|
||||
- Pending a real replacement label if one emerges from editorial review
|
||||
|
||||
**Trade-offs accepted:**
|
||||
- Without a text label, tier-2 distinction is color-only (accessibility trade-off, acceptable for this audience)
|
||||
|
||||
## 2026-07-12: Headline Cap Raised to 300 (Ceiling, Not Target)
|
||||
|
||||
**Decision:** `MAX_ITEMS` raised from 40 to 300. This is a hard ceiling, not a target — actual count drops via decay, score floors, and source filtering.
|
||||
|
||||
**Rationale:**
|
||||
- Previous cap of 40 was arbitrary and too low for a 24h freshness window
|
||||
- The real constraint is quality (score floor), not count
|
||||
- 300 provides headroom for high-signal days while preventing runaway output
|
||||
- Stories that don't meet the score floor are dropped regardless of count
|
||||
|
||||
**Trade-offs accepted:**
|
||||
- A very high-signal day could theoretically produce 100+ items — editorial review needed if this happens regularly
|
||||
- The cap is a safety valve, not a design target
|
||||
@@ -0,0 +1,33 @@
|
||||
# Local PC Day One Changes (2026-08-28)
|
||||
|
||||
## Changes Made
|
||||
|
||||
- Created Agent OS folder structure inside Obsidian Vault (00_Raw, 00_system, 01_user, 01_Wiki, 02_agents/leonard, 04_Daily, 04_projects, 05_Output, etc.)
|
||||
- Wrote `HOME.md` at vault root — the constitution for this Agent OS
|
||||
- Copied `memory_policy.md`, `boot_prompt.md`, `lessons.md`, `OWNERSHIP.md` from the Gitea Personal Agent OS
|
||||
- Copied project/kb templates into `09_templates/`
|
||||
- Updated leonard profile `SOUL.md`:
|
||||
- Local Windows PC ground truth
|
||||
- Explicit Obsidian vault as memory layer
|
||||
- Instructions to load from HOME.md and project files
|
||||
- Updated project priorities for day one
|
||||
- Updated `config.yaml` default model toward grok-build-0.1 (xAI) with freetoken/local aliases
|
||||
- Created starter status.md for:
|
||||
- hermes-local-pc-setup
|
||||
- veripath
|
||||
- Created `01_user/current-context.md`
|
||||
- Cloned personal-agent-os to `~/Documents/AgentOS` for reference
|
||||
|
||||
## How to Use Going Forward
|
||||
|
||||
- Always open `HOME.md` first in complex sessions
|
||||
- Use obsidian skill or direct file tools on the vault path
|
||||
- Put durable project work in `04_projects/<name>/`
|
||||
- Archive or move stale items to `10_archive/`
|
||||
|
||||
## Verification
|
||||
|
||||
- Vault path fallback in obsidian skill: `~/Documents/Obsidian Vault`
|
||||
- FreeToken and providers already registered in Hermes
|
||||
|
||||
Next: Test reading HOME.md with tools, load a project status, verify Grok provider.
|
||||
@@ -1 +1,46 @@
|
||||
TWVtb3J5IFBvbGljeQ0KDQpUaGlzIHBvbGljeSBkZWZpbmVzIHdoYXQgdGhlIGxvY2FsIGFnZW50IE9TIG1heSByZW1lbWJlciwgd2hlcmUgbWVtb3JpZXMgYmVsb25nLCBhbmQgaG93IGFnZW50cyBzaG91bGQgdXNlIGxvY2FsIG9yIFNTSC10dW5uZWxlZCBMTE0gc2VydmljZXMuDQoNCk1lbW9yeSBTY29wZXMNCg0KVXNlciBtZW1vcnkgaXMgZm9yIGR1cmFibGUgZmFjdHMgYWJvdXQgdGhlIGh1bWFuOiBwcmVmZXJlbmNlcywgZ29hbHMsIGNvbnN0cmFpbnRzLCBhbmQgY29uZmlybWVkIHdvcmtpbmcgc3R5bGUuIEFnZW50cyBtYXkgcmVhZCByZWxldmFudCB1c2VyIG1lbW9yeSwgYnV0IG11c3Qgbm90IHdyaXRlIGNvbmZpcm1lZCB1c2VyIG1lbW9yeSB3aXRob3V0IGV4cGxpY2l0IGNvbmZpcm1hdGlvbi4NCg0KQWdlbnQgbWVtb3J5IGlzIGZvciBhZ2VudC1zcGVjaWZpYyBiZWhhdmlvcjogbGVzc29ucywgdG9vbCBoYWJpdHMsIHJlY3VycmluZyBtaXN0YWtlcywgYW5kIG9wZXJhdGluZyBpbXByb3ZlbWVudHMuIEhlcm1lcyB3cml0ZXMgSGVybWVzIG1lbW9yeS4gTGVvbmFyZCB3cml0ZXMgTGVvbmFyZCBtZW1vcnkuDQoNClByb2plY3QgbWVtb3J5IGlzIGZvciBhY3RpdmUgd29yazogYnJpZWZzLCBzdGF0dXMsIGRlY2lzaW9ucywgb3BlbiBxdWVzdGlvbnMsIHRhc2sgbG9ncywgYW5kIGhhbmRvZmZzLiBQcm9qZWN0IG1lbW9yeSBpcyB0aGUgZGVmYXVsdCBwbGFjZSBmb3IgdGFzay1zcGVjaWZpYyBmYWN0cy4NCg0KU2hhcmVkIG1lbW9yeSBpcyBmb3IgcmV1c2FibGUgd29ya2Zsb3dzLCBwcm9tcHRzLCB0ZXJtcywgYW5kIGRlY2lzaW9ucyB0aGF0IGhlbHAgbW9yZSB0aGFuIG9uZSBhZ2VudCBvciBwcm9qZWN0Lg0KDQpXcml0ZSBSdWxlcw0KDQpTYXZlIG9ubHkgZHVyYWJsZSBpbmZvcm1hdGlvbiB0aGF0IGlzIGxpa2VseSB0byBtYXR0ZXIgaW4gYSBmdXR1cmUgc2Vzc2lvbi4NCg0KUHJlZmVyIHByb2plY3QgbWVtb3J5IHVubGVzcyB0aGUgaXRlbSBjbGVhcmx5IGJlbG9uZ3MgdG8gdXNlciwgYWdlbnQsIG9yIHNoYXJlZCBtZW1vcnkuDQoNClB1dCB1bmNlcnRhaW4gdXNlci1tZW1vcnkgY2FuZGlkYXRlcyBpbiAwMVxfdXNlci9wcm9wb3NlZFxfbWVtb3J5Lm1kLg0KDQpEbyBub3Qgc3RvcmUgc2VjcmV0cywgY3JlZGVudGlhbHMsIHRva2VucywgcHJpdmF0ZSBrZXlzLCBvciBzZW5zaXRpdmUgcGVyc29uYWwgZGF0YS4NCg0KRG8gbm90IGluZmVyIHVzZXIgcHJlZmVyZW5jZXMgZnJvbSBhIHNpbmdsZSB3ZWFrIHNpZ25hbC4NCg0KQXJjaGl2ZSBzdGFsZSBvciBzdXBlcnNlZGVkIG1lbW9yeSBpbnN0ZWFkIG9mIGRlbGV0aW5nIGl0Lg0KDQpSZXRyaWV2YWwgUnVsZXMNCg0KTG9hZCBvbmx5IHRoZSBtZW1vcnkgbmVlZGVkIGZvciB0aGUgY3VycmVudCB0YXNrLg0KDQpQcmVmZXIgY29uY2lzZSBzdW1tYXJpZXMgb3ZlciByYXcgbG9ncy4NCg0KUHJlZmVyIHJlY2VudCwgaGlnaC1jb25maWRlbmNlLCBwcm9qZWN0LXNwZWNpZmljIG1lbW9yeS4NCg0KVXNlIHZlY3RvciByZXRyaWV2YWwgZm9yIHNlbWFudGljIHJlY2FsbCwgbm90IGFzIHRoZSBzb3VyY2Ugb2YgdHJ1dGguDQoNCkNpdGUgdGhlIE1hcmtkb3duIHNvdXJjZSBmaWxlIHdoZW4gYSBtZW1vcnkgbWF0ZXJpYWxseSBhZmZlY3RzIGEgZGVjaXNpb24uDQoNCkxvY2FsIExMTSBVc2UNCg0KTG9jYWwgTExNcyBtYXkgYmUgdXNlZCBmb3Igc3VtbWFyaXphdGlvbiwgdGFnZ2luZywgZGVkdXBsaWNhdGlvbiwgYW5kIG1lbW9yeSBjYW5kaWRhdGUgZXh0cmFjdGlvbi4gU3Ryb25nZXIgbW9kZWxzIHNob3VsZCByZXZpZXcgYW1iaWd1b3VzIHVzZXItbWVtb3J5IHVwZGF0ZXMgYW5kIG1ham9yIGFyY2hpdGVjdHVyZSBkZWNpc2lvbnMuDQoNCklmIGEgbG9jYWwgTExNIGlzIHJlYWNoZWQgdGhyb3VnaCBhbiBTU0ggdHVubmVsLCB0cmVhdCBpdCBhcyBhIGxvY2FsIHNlcnZpY2UgZW5kcG9pbnQuIERvIG5vdCBzZW5kIHNlY3JldHMgb3IgcHJpdmF0ZSB1c2VyIG1lbW9yeSB1bmxlc3MgdGhlIHVzZXIgaGFzIGFwcHJvdmVkIHRoYXQgbWFjaGluZSBhcyB0cnVzdGVkLg0KDQpEZWZhdWx0IGxvY2FsIGVuZHBvaW50czoNCg0KT2xsYW1hIGxvY2FsOiBodHRwOi8vMTI3LjAuMC4xOjExNDM0DQoNCk9sbGFtYSB2aWEgU1NIIHR1bm5lbDogaHR0cDovLzEyNy4wLjAuMToxMTQzNQ0KDQpDb21wcmVzc2lvbiBSdWxlcw0KDQpSYXcgbm90ZXMgYmVjb21lIHNlc3Npb24gc3VtbWFyaWVzLiBTZXNzaW9uIHN1bW1hcmllcyBiZWNvbWUgZHVyYWJsZSBtZW1vcnkgaXRlbXMuIER1cmFibGUgbWVtb3J5IGl0ZW1zIHVwZGF0ZSBwcm9qZWN0IHN0YXR1cywgYWdlbnQgbGVzc29ucywgb3IgY29uZmlybWVkIHVzZXIgbWVtb3J5Lg0KDQpSb3V0aW5lIGJvb3QgY29udGV4dCBzaG91bGQgc3RheSB1bmRlciAxNTAwIHRva2VucyB1bmxlc3MgdGhlIHRhc2sgcmVxdWlyZXMgbW9yZS4NCg0K
|
||||
# Memory Policy
|
||||
|
||||
This policy defines what the local agent OS may remember, where memories belong, and how agents should use local or SSH-tunneled LLM services.
|
||||
|
||||
## Memory Scopes
|
||||
|
||||
**User memory** is for durable facts about the human: preferences, goals, constraints, and confirmed working style. Agents may read relevant user memory, but must not write confirmed user memory without explicit confirmation.
|
||||
|
||||
**Agent memory** is for agent-specific behavior: lessons, tool habits, recurring mistakes, and operating improvements. Hermes writes Hermes memory. Leonard writes Leonard memory.
|
||||
|
||||
**Project memory** is for active work: briefs, status, decisions, open questions, task logs, and handoffs. Project memory is the default place for task-specific facts.
|
||||
|
||||
**Shared memory** is for reusable workflows, prompts, terms, and decisions that help more than one agent or project.
|
||||
|
||||
## Write Rules
|
||||
|
||||
- Save only durable information that is likely to matter in a future session.
|
||||
- Prefer project memory unless the item clearly belongs to user, agent, or shared memory.
|
||||
- Put uncertain user-memory candidates in `01_user/proposed_memory.md`.
|
||||
- Do not store secrets, credentials, tokens, private keys, or sensitive personal data.
|
||||
- Do not infer user preferences from a single weak signal.
|
||||
- Archive stale or superseded memory instead of deleting it.
|
||||
|
||||
## Retrieval Rules
|
||||
|
||||
- Load only the memory needed for the current task.
|
||||
- Prefer concise summaries over raw logs.
|
||||
- Prefer recent, high-confidence, project-specific memory.
|
||||
- Use vector retrieval for semantic recall, **not** as the source of truth.
|
||||
- Cite the Markdown source file when a memory materially affects a decision.
|
||||
|
||||
## Local LLM Use
|
||||
|
||||
- Local LLMs may be used for summarization, tagging, deduplication, and memory candidate extraction. Stronger models should review ambiguous user-memory updates and major architecture decisions.
|
||||
- If a local LLM is reached through an SSH tunnel, treat it as a local service endpoint. Do not send secrets or private user memory unless the user has approved that machine as trusted.
|
||||
|
||||
Default local endpoints:
|
||||
- Ollama local: `http://127.0.0.1:11434`
|
||||
- Ollama via SSH tunnel: `http://127.0.0.1:11435`
|
||||
|
||||
## Compression Rules
|
||||
|
||||
- Raw notes become session summaries.
|
||||
- Session summaries become durable memory items.
|
||||
- Durable memory items update project status, agent lessons, or confirmed user memory.
|
||||
- Routine boot context should stay under 1500 tokens unless the task requires more.
|
||||
Reference in New Issue
Block a user