Dashboard/AI-OS (Second-Brain)/My-OS-Specs.md
AI-OS (Second-Brain)

My-OS-Specs.md

My OS — Component Specs

Running capture of what My OS is and its components, as Arijit specifies them. My OS is Arijit's personal operating system for running his portfolio of projects. This doc grows as he gives specs. Companion to My-Projects (the live tracker data) and About-Arijit. Started 2026-07-01.

What My OS is

A personal operating system: the tools, records, and dashboard through which Arijit runs and tracks all his projects, and the self-model of how he works. The My-Projects tracker is its data spine; a visual dashboard is its face.

Components (specified so far)

1. Project tracker

  • What: durable, cross-thread record of every project — one-pager (what / value prop / customer / benefits) + stage + health + next + an append-only progress log.
  • Where: vault My-Projects (human-facing) + memory project-tracker-status.md (recall). Maintained by the project-tracker skill.
  • Rule: every significant git commit's release-log notes are ALSO appended to the tracker's progress log (commit and tracker stay in lockstep). This gives the dashboard plain-English per-project history.
  • Why durable: SESSION.md is single-thread and gets overwritten when another thread runs; the tracker is the cross-thread source of truth.

2. Dashboard (visual project status) — TO BUILD (UI thread)

  • What: a visual/graphical view of project status, not just text. Renders the tracker: portfolio at a glance, per-project stage + health, and a progress graph over time (the dated log is the time series).
  • Data contract: stable project keys; stage enum (idea | in-build | shipping | paused | idle | reference); health enum (on-track | at-risk | stalled | blocked | unknown); dated progress log per project.
  • Interim: until built, the project-tracker skill and /persist emit an ASCII status board (health glyphs 🟢🟡🔴⚪) so the shape is visible in-thread.
  • Status: design/spec; to be built in the parallel UI thread.

3. Persist integration (the trigger)

  • /persist is the event source. On persist: save everything (memory, SESSION.md, GitHub commit with release-log notes) AND summarize the session update and POST it to the tracker webhook (see Execution pipeline below). Persist already has the rich description (it wrote the commit + memory), so the payload is detailed.
  • /persist also shows the dashboard graph in-thread (interim: ASCII status board), so persist always leaves Arijit looking at the current portfolio shape.

4. Cross-project awareness

  • Global CLAUDE.md + every project CLAUDE.md carry a pointer to My-Projects, so in any project thread the assistant knows where the other projects live and can read their wikis on demand (e.g. mid-PRISM, fetch + embed the latest Scout by reading Projects/Scout/).

5. CLAUDE.md hygiene (standard practice)

  • A default project CLAUDE.md template lives at vault System/Project-CLAUDE-template.md. As Arijit opens each project, its CLAUDE.md is created/refreshed from the template + that project's specs. Keeping CLAUDE.md fresh is a regular exercise (natural at /persist), not a one-off. Arijit has flagged his current CLAUDE.md management as weak and wants this rigour.

6. Repo rigour: frontend/backend split (portfolio-wide)

  • Every active project trends toward a clean FRONTEND vs BACKEND divide (PRISM = frontend, PIP = backend is the reference pair; see My-Projects and memory reference-two-repos-prism-vs-pip). Plus periodic code-health / quality / structure audits per repo.

7. Vault-update layer = record-knowledge (extended, not a new skill)

  • The record-knowledge skill IS the vault-update mechanism. It writes DEEP per-project knowledge to the wiki (decisions, dev-log, ideas, exploratory directions, open questions, sources). Decision: do NOT create a separate "Vault-Update" skill (that would duplicate record-knowledge and drift).
  • Extended 2026-07-01: on every significant project write, record-knowledge also calls project-tracker to bump that project's rollup (stage/health/one-liner + progress-log line) and mirror to memory. So one "record this" = deep wiki entry + rollup update + (later) dashboard + Athena notify.
  • Layering: record-knowledge (deep, source of truth) → project-tracker (shallow rollup) → dashboard (visual) → Athena (notify). One writes deep, one summarizes, one displays, one tells Arijit.

8. Code Auditor (checks and balances) — the missing enforcer

  • Problem it solves: the Code-Housekeeping-SOP is the process; the Auditor is the enforcement. Writing an SOP does not make existing code follow it. Something must actively check every active codebase and catch drift.
  • What it does: a skill (code-auditor) that runs periodically across every repo. It reads the project tracker to know which projects/repos exist and their tool/stage, then audits each repo against the SOP: repo structure (frontend/backend split, folder=repo name, under git), git hygiene (uncommitted/branch sprawl), AGENTS.md canonical+symlink+fresh, code health (run linter/formatter/type-check/tests), versioning (tags/changelog), deps (lockfiles/drift), secrets not committed, modularization drift.
  • Reports back to the project tracker: per-repo health (on-track/at-risk/…) + a drift report, so the Auditor's findings flow up to the tracker → Athena → Arijit. Closes the loop.
  • Cheap by default: per-repo audits dispatch worker subagents at T1/T2 (haiku/sonnet); orchestration stays higher.
  • Status: skill scaffolded 2026-07-01 (~/.claude/skills/code-auditor/). Not yet scheduled/run.

9. Self-improvement / learning loop — how MyOS gets smarter

  • Problem: MyOS (and Arijit) must keep up with fast-moving AI/tech. Two intake modes:
  • Push (Telegram): Arijit, from his phone, sends trend/insight notes as he watches YouTube videos or spots something on X. The agent LEARNS from them — files to the knowledge base (record-knowledge ingest), and where warranted, builds/updates a skill.
  • Pull (active seeking): the agent proactively pulls from followed sources — YouTuber channels, YouTube, X accounts (Arijit will supply the list) — and synthesizes what is new. Building block: the existing last30days multi-source trend skill + record-knowledge for filing.
  • Output: new knowledge in vault Knowledge/, occasionally new/updated skills. This is a standing mechanism, not a one-off.
  • Open research (in progress): how does Hermes itself learn / acquire knowledge (memory curator, memory providers, ingestion/RAG, runtime skill growth)? Answer feeds how we build this loop on Hermes. Research launched 2026-07-01.
  • Status: spec only. To build: a Telegram intake path + a scheduled feed-pull, both feeding record-knowledge.

Execution pipeline (TARGET, specified 2026-07-01) — event-driven, not polling

Earlier idea was a /loop every 6h (polling). Arijit's refined design is event-driven: work → persist → webhook → tracker updates → CEO notifies. The chain:

  1. Any session (any Claude Code or Codex instance, any project) finishes work and runs /persist.
  2. Persist saves memory + SESSION.md + a GitHub commit (release-log notes), then POSTs a summarized update to the tracker webhook.
  3. A listener on that webhook fires the project-tracker skill/app with the payload.
  4. The tracker skill understands the update, updates the tracker (status + one-liner description + progress log) and the dashboard graph.
  5. The tracker then notifies a Hermes agent which sends Arijit an update on his phone.

This makes the tracker reportable from ANY instance/tool — the webhook is how another Claude Code instance, a Codex session, or a machine reports status. It is the missing piece that turns the tracker from shared files into a live system.

The agent hierarchy (checks and balances) — record under MyOS

MyOS runs as a hierarchy of agents/skills, each with a job, running periodically. This is the checks-and-balances system that keeps the portfolio healthy and Arijit up to speed:

Athena (CEO)                     ← top agent; monitors the portfolio, notifies Arijit
   └─ Project Tracker            ← maintains the rollup; the portfolio state
         ├─ record-knowledge     ← deep per-project knowledge (feeds the tracker)
         └─ Code Auditor         ← periodic code-health check across every repo; reports drift back
  • Athena = Arijit's CEO agent (Hermes persona), the top of the hierarchy. Monitors the Project Tracker and sends Arijit periodic updates on his phone (Telegram). (Name = Athena; earlier audio was mis-heard as "Athena" — Athena is correct.)
  • Project Tracker = the portfolio-state skill. Fed by record-knowledge (deep) and by the Auditor (health). Athena reads it.
  • Code Auditor = see component 8. Called by / reports to the tracker.
  • Persona map on Hermes: Athena = MyOS portfolio CEO / notifier; Cassandra = PRISM sales coach; Argus = CI-OS competitive-intelligence voice. All run on Hermes.

Hermes = THE executioner

  • Hermes is the engine and muscle for all of it. MyOS, ArijitOS, "The Soul" — the specs/identity/records we build here are handed to Hermes to execute. The webhook listener, the tracker updater, the auditor scheduler, and Athena all run on Hermes. Build MyOS so it can be productised on Hermes (multi-tenant).

Honest current status (nothing overclaimed)

  • Tracker = vault doc + memory file + skill definition. Not a live app.
  • Webhook, listener, dashboard, phone notification, Athena: NONE built. All target/spec.
  • Near-term without the webhook: /persist can update the tracker files directly (no HTTP). The webhook matters once multiple tools/instances/machines must report and Athena must notify.

Storage architecture — RESOLVED (see Storage-Architecture)

Markdown vault = human source of truth; Postgres = the queryable projection the dashboard reads (status + time-series progress log); pgvector in the same Postgres for agent retrieval; multi-tenant via tenant_id + Postgres RLS; a file-watcher daemon syncs vault → Postgres (DB is rebuildable). Full detail + Hermes storage facts (SQLite sessions + markdown memory) in Storage-Architecture.

Open / next

  • Build the Code Auditor loop (skill scaffolded) + schedule it across repos; wire its drift reports into the tracker.
  • Build the learning loop: Telegram push intake + scheduled feed-pull → record-knowledge (pending the Hermes-learning research).
  • Decide the tracker's runtime home: standalone webhook service vs a Hermes plugin (Hermes = executioner argues for a Hermes-hosted listener + Athena persona).
  • Build the webhook + listener + Athena notification path.
  • Build the dashboard (UI thread) against the data contract above.
  • Roll the CLAUDE.md/AGENTS.md template into each project as Arijit visits them (AGENTS.md canonical, ln -s AGENTS.md CLAUDE.md; done for CI-OS).
  • Confirm + execute the PRISM/PIP repo rename (local + GitHub + VPS).