@vortex-os/base 0.4.0 → 0.6.0

package/templates/routers/AGENT.md

@@ -1,93 +0,0 @@
----
-type: agent-entry
-status: active
----
-
-# VortEX Instance — Multi-Agent Personal AI Work OS
-
-> A vortex absorbing context, an executable runtime running it through agents.
-
-This is the unified entry point for every agent working in this instance (Claude Code, Codex CLI, Gemini CLI, Cursor). The per-agent files (`CLAUDE.md`, `AGENTS.md`, `CODEX.md`, `GEMINI.md`, `.cursorrules`) all route here — this file is the single source of truth.
-
-This instance was created from the `@vortex-os/base` framework. The framework code lives in `node_modules/@vortex-os/`; you do not edit it. You work in `data/` — your own content — and use the `vortex` CLI and the `/`-commands it installs.
-
-## First thing to check
-
-If `data/_memory/user_profile.md` is missing, this instance has not been set up yet. Run:
-
-```
-npx vortex init --name "<your name>" --role "<your role>" --task "<what you're working on>"
-```
-
-`init` creates a user-profile memory, today's first worklog, the agent slash-commands, and wires the session hooks. Everything after that grows as you work.
-
-## How VortEX behaves by default — auto the plumbing, propose the prose
-
-Operating principle: **auto-maintain the operational memory; propose changes to the knowledge base.** You should never have to learn commands to get value — the records that make recall smarter accumulate on their own, while you keep full control over your own topic documentation.
-
-**Auto (no prompt — append-only operational records; *show, don't ask*):**
-- **Session start.** Run the start ritual: if a sync remote is configured, `git pull` (report conflicts, never auto-resolve); detect the environment if one is configured; backfill any worklog missing from prior sessions; report status (recent work, what's in progress, the time). Where the `SessionStart` hook is configured this runs automatically; otherwise perform it as the first action of the session.
-- **Worklog.** As a work unit completes — and at session wind-down ("that's it for today", "wrap up") — ensure today's worklog exists and append the work. The agent is the primary path; the `SessionEnd` hook is the net.
-- **Decisions.** When the user makes a *substantive* decision ("let's go with X"), record it in the Decision Log. Real decisions, not casual asides.
-- **Ambient recall** (read-only). When the user references earlier work, run `/recall <the reference>` and weave a confident hit into one sentence. One nudge, not a list; drop it if waved off.
-
-These are **append-only and transparent**: do them without a yes/no prompt, but surface a brief, non-blocking note so the user always sees what was recorded. Everything lands in git and is reversible; disable any of them via `.agent/vortex.json` (`autoRecord.*`). `git push` stays **explicit**, never automatic.
-
-**Propose (ask first — the one place friction is intentional):**
-- **Knowledge-base documentation.** Changes to the user's topic documentation (the `data/<topic>/` tree and hubs) are **proposed, never auto-written**: "you've done X, Y, Z on this — update the existing doc, or create a new folder?" The user owns the shape of their knowledge base; the agent never silently restructures it.
-
-The line is technical: **append-only operational logs are safe to auto-write; structural or content changes to the knowledge base are proposed.**
-
-## Working style
-
-**Explain simply and briefly — assume the user is not an IT expert.** Default to plain language. Lead with the conclusion. Keep ordinary replies short (a few lines, at most a few bullets); add tables/code only when they earn their place. Unpack any unavoidable technical term in a line or with a plain analogy.
-
-**Ask one decision at a time.** When you need the user to decide, ask a single question and wait — do not stack several at once. Only batch when the choices are genuinely independent.
-
-**Match reasoning effort to the task.** Don't over-reason trivial asks — a status check, a one-line edit, a lookup; don't under-reason heavy ones — architecture design, multi-file refactors, large debugging or migration, broad reviews. If the host exposes a tunable reasoning/thinking level and the task ahead clearly needs a different one than the session is set for, recommend the change — but rarely: only at a real boundary (a sizable task's start, a major topic shift, a substantial new directive), one or two times across a long session, never per question.
-
-## The `data/` layout
-
-Your content lives under `data/`. Each category answers a different question:
-
-| Category | Question it answers |
-|---|---|
-| `worklog/` | "What happened today?" — chronological, one entry per day (`YYYY/MM/YYYY-MM-DD-keyword.md`). |
-| `decision-log/` | "Why did we choose X over Y?" — per-decision record with context + alternatives. |
-| `_memory/` | "What rule or fact must survive every session?" — curated facts reloaded each session start. |
-| `runbooks/` | "What is the procedure when X breaks?" — repeatable steps with `last_tested` aging. |
-| `hubs/` | "Where do I find everything about topic Z?" — a cross-cut landing page; grows organically once 3+ categories accumulate on the same topic. |
-| `inbox/` | "Where does an unfiled note land before I sort it?" |
-
-A typical day flows from short-lived capture (worklog) into longer-lived artifacts (decision-log, runbook, memory, hub). These are common promotion patterns, not required flows.
-
-## Commands you'll use
-
-These slash-commands are installed into `.claude/commands/` by `vortex init` (the agent runs the underlying `vortex` CLI and presents the result):
-
-| Command | What it does |
-|---|---|
-| `/vortex` | Instance operations: `init`, `status`, `import`, `doctor`, `help`. |
-| `/session-start` | Start-of-session report — recent work, current counts, the time. |
-| `/log <section>` | Append a section to today's worklog (creates it if needed). |
-| `/decision <slug> <title>` | Create a new Decision Log entry from the template. |
-| `/recall <query>` | Semantic search over your memories and past sessions. *(Only when the optional `@vortex-os/memory-extended` add-on is installed.)* |
-| `/agenda` | "What should I focus on?" — synthesizes open tasks, decisions, recent activity. |
-| `/reindex [dir]` | Regenerate `_INDEX.md` for a category (or all). Idempotent. |
-
-You can also run any of these directly: `npx vortex <command> [args]`.
-
-## Optional add-ons
-
-- **`@vortex-os/memory-extended`** — semantic recall over memories and past conversation sessions. Install alongside this instance to light up `/recall`; without it, everything else works and `/recall` is simply absent.
-
-## Agent routing
-
-| Agent | Entry | Shared config | Dedicated config |
-|---|---|---|---|
-| Claude Code | `CLAUDE.md` → `AGENT.md` | `.agent/` | `.claude/` |
-| Codex CLI | `AGENTS.md` → `AGENT.md` (Codex auto-loads `AGENTS.md`; `CODEX.md` is legacy/manual) | `.agent/` | `.codex/` |
-| Gemini CLI | `GEMINI.md` → `AGENT.md` | `.agent/` | `.gemini/` |
-| Cursor | `.cursorrules` → `AGENT.md` | `.agent/` | `.cursor/` |
-
-Per-agent files contain only agent-specific supplements. System-wide rules belong in this file.

package/templates/routers/CODEX.md

@@ -1,16 +0,0 @@
-# CODEX.md
-
-NOTE: Codex CLI auto-loads `AGENTS.md`, not this file. The auto-load entry for
-Codex is `AGENTS.md` (which routes to `AGENT.md`). This `CODEX.md` is a manual /
-legacy supplement — read it only when explicitly pointed here.
-
-## Route to unified entry
-
-Read [`AGENT.md`](./AGENT.md) first — it is the single source of truth for how this instance behaves.
-
-This `CODEX.md` holds only Codex-specific supplements. For everything else, refer to `AGENT.md`.
-
-## Codex-specific config
-
-- Dedicated dir: `.codex/`
-- Shared dir: `.agent/`