{"owner":"EpicenterHQ","repo":"epicenter","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["CLAUDE.md","AGENTS.md"],"skills":{"CLAUDE.md":"@AGENTS.md\n\n# Claude-specific notes\n\nClaude leads the mission: make the in-scope calls, choose what evidence is\nenough, and decide how to verify the result. Codex is an optional second agent,\nreached through the literal `/codex:rescue` command (the\n`openai/codex-plugin-cc` plugin is installed). Use it when a bounded search,\ndiff or history read, focused edit, verification pass, or independent check\nwould help. Give it one job and the inputs it needs.\n\nWhat comes back is evidence, not a verdict. Read it against the code and use\nyour judgment: a confident Codex answer that conflicts with what you have seen\nis a reason to look again, not a reason to defer.\n\n`/codex:review`, `/codex:adversarial-review`, `/codex:transfer`,\n`/codex:status`, `/codex:result`, and `/codex:cancel` are user-invoked and you\ncannot call them. Suggest one when a second pass or a Codex handoff would help,\nand relay what it returns faithfully before adding your own read.\n","AGENTS.md":"# Epicenter\n\nLocal-first personal data platform. Monorepo with Yjs CRDTs and Svelte UI.\n\nStructure: `apps/whispering/` (browser-hostable transcription SPA), `apps/epicenter/` (Tauri host for trusted app surfaces, including Whispering), `apps/tab-manager/` (Chrome extension), `apps/api/` (hosted personal Cloud Worker: `worker/` + `ui/`), `apps/self-host/` (self-hosted single-partition instance reference; Bun or Cloudflare), `packages/server/` (shared Hono library that both deployables consume; deployments differ by principal resolver), `packages/data/` (the Epicenter replica: Lenses, rows, values, row documents), `packages/ui/` (shadcn-svelte components), `specs/` (planning docs), `docs/` (reference materials).\n\nPlanning docs and decisions: Authoritative sources, in order, are `docs/adr/` (durable decisions and their rationale), `docs/CONTEXT.md` (shared vocabulary), package READMEs for package-owned current behavior, and the code. Specs in any `specs/` directory (top-level and per-app or per-package) are in-flight design scaffolding, not current truth; the two-state lifecycle and hygiene gate govern all of them repo-wide. `docs/spec-history.md` is a dated index of past specs and is history, not truth. When a spec conflicts with an ADR or the code, the ADR and code win. A spec has only two states, `Draft` and `In Progress`; \"done\" is deletion, not a terminal status, so a spec still in the tree declaring `Implemented`/`Superseded` is a hygiene smell (`scripts/check-doc-hygiene.ts` flags it). When a design pass settles a durable decision, record it as an ADR (see `docs/adr/README.md`) and delete the now-spent spec; git keeps the body recoverable.\n\nDeployment seam: One library (`packages/server`), two deployables (`apps/api` = hosted personal cloud, `apps/self-host` = self-hosted single-partition instance reference). Multi-tenancy (many principals, OAuth, billing) is Cloud-only; an instance resolves every valid bearer to the literal `instance` principal (ADR-0075, amended by ADR-0092). Billing (catalog, routes, Autumn) lives in `apps/api/worker/billing/` and is hosted-only; never extract it back to a shared package. The self-hosted instance deployable is community-supported, not Epicenter-operated.\n\nLicense boundary: apps and `packages/server` are AGPL; the embeddable toolkit packages are MIT (decision procedure in `docs/licensing/licensing-strategy.md`). Moving or copying code from an AGPL package into an MIT one is a relicensing act; `bun run check:licenses` guards dependency edges only and cannot see copied source.\n\nAlways use bun: Prefer `bun` over npm, yarn, pnpm, and node. Use `bun run`, `bun test`, `bun install`, and `bun x` (instead of npx).\n\nLocal dev: start apps from the repo root with `bun dev:<app>`; it runs every process the app needs, including the hosted API on `localhost:8787` for apps that talk to it. `bun dev:<app>:ui` is the frontend alone when that split exists; `bun dev:api` is the backend alone. Do not cd into an app to start it. Details in the `monorepo` skill.\n\nAgent instruction files: Treat `AGENTS.md` as the canonical shared instructions file. `CLAUDE.md` files are compatibility shims for Claude Code and should only import a sibling `AGENTS.md` with `@AGENTS.md`, plus rare Claude-specific notes if needed. When adding a nested `AGENTS.md`, add a sibling `CLAUDE.md` shim. Do not create orphan `CLAUDE.md` files.\n\nDestructive actions need approval: Force pushes, hard resets (`--hard`), branch deletions.\n\nExternal grounding: When external library behavior affects correctness, verify against DeepWiki, official docs, or local installed types before changing code. Skip this for stable basics and repo-local patterns already documented in skills.\n\nGit hygiene: Stage specific files only. Never use `git add .` or `git add -A`. Do not include AI or tool attribution in commits.\n\nReview posture: Be direct about flawed assumptions, weak designs, and regressions. Do not agree just to be agreeable.\n\nCoherent edits: Do not default to the smallest local patch. Before changing code, prose, or agent instructions, identify the largest relevant unit whose shape controls the problem, then reconsider that unit as if the new context had always been known. The correct result may still be a small diff, but minimizing the diff is not the goal.\n\nScript suffix convention: `:local` suffix scripts work on a fresh clone without Infisical login (they read committed config like `wrangler.jsonc`). `:remote` suffix scripts wrap with `infisical run --env=prod` and require Infisical authentication; treat them as production admin operations.\n\nLibrary logging: Do not use direct `console.*` in library code. Use `wellcrafted/logger`, except in CLIs, tests, and benchmarks.\n\nWriting conventions: Avoid en dash characters (`U+2013`). Prefer colon, comma, semicolon, parenthesis, or sentence break over em dash characters (`U+2014`), especially in UI strings, docs, comments, JSDoc, and commit messages. Keep user-facing text direct and concrete. Load `writing-voice` for substantial prose or explicit tone/rewrite work.\n\nReview routing: For substantial implementations, public API changes, refactors, multi-file changes, or user requests to challenge, simplify, clean up, greenfield, or make a clean break, load `post-implementation-review` before final handoff or staging. Load `collapse-pass` directly for continuous indirection-reduction work. During review, escalate to `greenfield-clean-breaks` for ownership, lifecycle, API, package-boundary, clean-break, compatibility-refusal, or asymmetric-win decisions. After a substantive multi-file wave, consider `fresh-context-review` when an independent challenge could catch ownership, lifecycle, or type-shape mistakes; it delegates review, never execution. Keep procedures in skills; keep `AGENTS.md` to routing.\n"},"files":{"CLAUDE.md":"@AGENTS.md\n\n# Claude-specific notes\n\nClaude leads the mission: make the in-scope calls, choose what evidence is\nenough, and decide how to verify the result. Codex is an optional second agent,\nreached through the literal `/codex:rescue` command (the\n`openai/codex-plugin-cc` plugin is installed). Use it when a bounded search,\ndiff or history read, focused edit, verification pass, or independent check\nwould help. Give it one job and the inputs it needs.\n\nWhat comes back is evidence, not a verdict. Read it against the code and use\nyour judgment: a confident Codex answer that conflicts with what you have seen\nis a reason to look again, not a reason to defer.\n\n`/codex:review`, `/codex:adversarial-review`, `/codex:transfer`,\n`/codex:status`, `/codex:result`, and `/codex:cancel` are user-invoked and you\ncannot call them. Suggest one when a second pass or a Codex handoff would help,\nand relay what it returns faithfully before adding your own read.\n","AGENTS.md":"# Epicenter\n\nLocal-first personal data platform. Monorepo with Yjs CRDTs and Svelte UI.\n\nStructure: `apps/whispering/` (browser-hostable transcription SPA), `apps/epicenter/` (Tauri host for trusted app surfaces, including Whispering), `apps/tab-manager/` (Chrome extension), `apps/api/` (hosted personal Cloud Worker: `worker/` + `ui/`), `apps/self-host/` (self-hosted single-partition instance reference; Bun or Cloudflare), `packages/server/` (shared Hono library that both deployables consume; deployments differ by principal resolver), `packages/data/` (the Epicenter replica: Lenses, rows, values, row documents), `packages/ui/` (shadcn-svelte components), `specs/` (planning docs), `docs/` (reference materials).\n\nPlanning docs and decisions: Authoritative sources, in order, are `docs/adr/` (durable decisions and their rationale), `docs/CONTEXT.md` (shared vocabulary), package READMEs for package-owned current behavior, and the code. Specs in any `specs/` directory (top-level and per-app or per-package) are in-flight design scaffolding, not current truth; the two-state lifecycle and hygiene gate govern all of them repo-wide. `docs/spec-history.md` is a dated index of past specs and is history, not truth. When a spec conflicts with an ADR or the code, the ADR and code win. A spec has only two states, `Draft` and `In Progress`; \"done\" is deletion, not a terminal status, so a spec still in the tree declaring `Implemented`/`Superseded` is a hygiene smell (`scripts/check-doc-hygiene.ts` flags it). When a design pass settles a durable decision, record it as an ADR (see `docs/adr/README.md`) and delete the now-spent spec; git keeps the body recoverable.\n\nDeployment seam: One library (`packages/server`), two deployables (`apps/api` = hosted personal cloud, `apps/self-host` = self-hosted single-partition instance reference). Multi-tenancy (many principals, OAuth, billing) is Cloud-only; an instance resolves every valid bearer to the literal `instance` principal (ADR-0075, amended by ADR-0092). Billing (catalog, routes, Autumn) lives in `apps/api/worker/billing/` and is hosted-only; never extract it back to a shared package. The self-hosted instance deployable is community-supported, not Epicenter-operated.\n\nLicense boundary: apps and `packages/server` are AGPL; the embeddable toolkit packages are MIT (decision procedure in `docs/licensing/licensing-strategy.md`). Moving or copying code from an AGPL package into an MIT one is a relicensing act; `bun run check:licenses` guards dependency edges only and cannot see copied source.\n\nAlways use bun: Prefer `bun` over npm, yarn, pnpm, and node. Use `bun run`, `bun test`, `bun install`, and `bun x` (instead of npx).\n\nLocal dev: start apps from the repo root with `bun dev:<app>`; it runs every process the app needs, including the hosted API on `localhost:8787` for apps that talk to it. `bun dev:<app>:ui` is the frontend alone when that split exists; `bun dev:api` is the backend alone. Do not cd into an app to start it. Details in the `monorepo` skill.\n\nAgent instruction files: Treat `AGENTS.md` as the canonical shared instructions file. `CLAUDE.md` files are compatibility shims for Claude Code and should only import a sibling `AGENTS.md` with `@AGENTS.md`, plus rare Claude-specific notes if needed. When adding a nested `AGENTS.md`, add a sibling `CLAUDE.md` shim. Do not create orphan `CLAUDE.md` files.\n\nDestructive actions need approval: Force pushes, hard resets (`--hard`), branch deletions.\n\nExternal grounding: When external library behavior affects correctness, verify against DeepWiki, official docs, or local installed types before changing code. Skip this for stable basics and repo-local patterns already documented in skills.\n\nGit hygiene: Stage specific files only. Never use `git add .` or `git add -A`. Do not include AI or tool attribution in commits.\n\nReview posture: Be direct about flawed assumptions, weak designs, and regressions. Do not agree just to be agreeable.\n\nCoherent edits: Do not default to the smallest local patch. Before changing code, prose, or agent instructions, identify the largest relevant unit whose shape controls the problem, then reconsider that unit as if the new context had always been known. The correct result may still be a small diff, but minimizing the diff is not the goal.\n\nScript suffix convention: `:local` suffix scripts work on a fresh clone without Infisical login (they read committed config like `wrangler.jsonc`). `:remote` suffix scripts wrap with `infisical run --env=prod` and require Infisical authentication; treat them as production admin operations.\n\nLibrary logging: Do not use direct `console.*` in library code. Use `wellcrafted/logger`, except in CLIs, tests, and benchmarks.\n\nWriting conventions: Avoid en dash characters (`U+2013`). Prefer colon, comma, semicolon, parenthesis, or sentence break over em dash characters (`U+2014`), especially in UI strings, docs, comments, JSDoc, and commit messages. Keep user-facing text direct and concrete. Load `writing-voice` for substantial prose or explicit tone/rewrite work.\n\nReview routing: For substantial implementations, public API changes, refactors, multi-file changes, or user requests to challenge, simplify, clean up, greenfield, or make a clean break, load `post-implementation-review` before final handoff or staging. Load `collapse-pass` directly for continuous indirection-reduction work. During review, escalate to `greenfield-clean-breaks` for ownership, lifecycle, API, package-boundary, clean-break, compatibility-refusal, or asymmetric-win decisions. After a substantive multi-file wave, consider `fresh-context-review` when an independent challenge could catch ownership, lifecycle, or type-shape mistakes; it delegates review, never execution. Keep procedures in skills; keep `AGENTS.md` to routing.\n"},"items":[{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"@AGENTS.md\n\n# Claude-specific notes\n\nClaude leads the mission: make the in-scope calls, choose what evidence is\nenough, and decide how to verify the result. Codex is an optional second agent,\nreached through the literal `/codex:rescue` command (the\n`openai/codex-plugin-cc` plugin is installed). Use it when a bounded search,\ndiff or history read, focused edit, verification pass, or independent check\nwould help. Give it one job and the inputs it needs.\n\nWhat comes back is evidence, not a verdict. Read it against the code and use\nyour judgment: a confident Codex answer that conflicts with what you have seen\nis a reason to look again, not a reason to defer.\n\n`/codex:review`, `/codex:adversarial-review`, `/codex:transfer`,\n`/codex:status`, `/codex:result`, and `/codex:cancel` are user-invoked and you\ncannot call them. Suggest one when a second pass or a Codex handoff would help,\nand relay what it returns faithfully before adding your own read.\n","category":"root","tokens":239},{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Epicenter\n\nLocal-first personal data platform. Monorepo with Yjs CRDTs and Svelte UI.\n\nStructure: `apps/whispering/` (browser-hostable transcription SPA), `apps/epicenter/` (Tauri host for trusted app surfaces, including Whispering), `apps/tab-manager/` (Chrome extension), `apps/api/` (hosted personal Cloud Worker: `worker/` + `ui/`), `apps/self-host/` (self-hosted single-partition instance reference; Bun or Cloudflare), `packages/server/` (shared Hono library that both deployables consume; deployments differ by principal resolver), `packages/data/` (the Epicenter replica: Lenses, rows, values, row documents), `packages/ui/` (shadcn-svelte components), `specs/` (planning docs), `docs/` (reference materials).\n\nPlanning docs and decisions: Authoritative sources, in order, are `docs/adr/` (durable decisions and their rationale), `docs/CONTEXT.md` (shared vocabulary), package READMEs for package-owned current behavior, and the code. Specs in any `specs/` directory (top-level and per-app or per-package) are in-flight design scaffolding, not current truth; the two-state lifecycle and hygiene gate govern all of them repo-wide. `docs/spec-history.md` is a dated index of past specs and is history, not truth. When a spec conflicts with an ADR or the code, the ADR and code win. A spec has only two states, `Draft` and `In Progress`; \"done\" is deletion, not a terminal status, so a spec still in the tree declaring `Implemented`/`Superseded` is a hygiene smell (`scripts/check-doc-hygiene.ts` flags it). When a design pass settles a durable decision, record it as an ADR (see `docs/adr/README.md`) and delete the now-spent spec; git keeps the body recoverable.\n\nDeployment seam: One library (`packages/server`), two deployables (`apps/api` = hosted personal cloud, `apps/self-host` = self-hosted single-partition instance reference). Multi-tenancy (many principals, OAuth, billing) is Cloud-only; an instance resolves every valid bearer to the literal `instance` principal (ADR-0075, amended by ADR-0092). Billing (catalog, routes, Autumn) lives in `apps/api/worker/billing/` and is hosted-only; never extract it back to a shared package. The self-hosted instance deployable is community-supported, not Epicenter-operated.\n\nLicense boundary: apps and `packages/server` are AGPL; the embeddable toolkit packages are MIT (decision procedure in `docs/licensing/licensing-strategy.md`). Moving or copying code from an AGPL package into an MIT one is a relicensing act; `bun run check:licenses` guards dependency edges only and cannot see copied source.\n\nAlways use bun: Prefer `bun` over npm, yarn, pnpm, and node. Use `bun run`, `bun test`, `bun install`, and `bun x` (instead of npx).\n\nLocal dev: start apps from the repo root with `bun dev:<app>`; it runs every process the app needs, including the hosted API on `localhost:8787` for apps that talk to it. `bun dev:<app>:ui` is the frontend alone when that split exists; `bun dev:api` is the backend alone. Do not cd into an app to start it. Details in the `monorepo` skill.\n\nAgent instruction files: Treat `AGENTS.md` as the canonical shared instructions file. `CLAUDE.md` files are compatibility shims for Claude Code and should only import a sibling `AGENTS.md` with `@AGENTS.md`, plus rare Claude-specific notes if needed. When adding a nested `AGENTS.md`, add a sibling `CLAUDE.md` shim. Do not create orphan `CLAUDE.md` files.\n\nDestructive actions need approval: Force pushes, hard resets (`--hard`), branch deletions.\n\nExternal grounding: When external library behavior affects correctness, verify against DeepWiki, official docs, or local installed types before changing code. Skip this for stable basics and repo-local patterns already documented in skills.\n\nGit hygiene: Stage specific files only. Never use `git add .` or `git add -A`. Do not include AI or tool attribution in commits.\n\nReview posture: Be direct about flawed assumptions, weak designs, and regressions. Do not agree just to be agreeable.\n\nCoherent edits: Do not default to the smallest local patch. Before changing code, prose, or agent instructions, identify the largest relevant unit whose shape controls the problem, then reconsider that unit as if the new context had always been known. The correct result may still be a small diff, but minimizing the diff is not the goal.\n\nScript suffix convention: `:local` suffix scripts work on a fresh clone without Infisical login (they read committed config like `wrangler.jsonc`). `:remote` suffix scripts wrap with `infisical run --env=prod` and require Infisical authentication; treat them as production admin operations.\n\nLibrary logging: Do not use direct `console.*` in library code. Use `wellcrafted/logger`, except in CLIs, tests, and benchmarks.\n\nWriting conventions: Avoid en dash characters (`U+2013`). Prefer colon, comma, semicolon, parenthesis, or sentence break over em dash characters (`U+2014`), especially in UI strings, docs, comments, JSDoc, and commit messages. Keep user-facing text direct and concrete. Load `writing-voice` for substantial prose or explicit tone/rewrite work.\n\nReview routing: For substantial implementations, public API changes, refactors, multi-file changes, or user requests to challenge, simplify, clean up, greenfield, or make a clean break, load `post-implementation-review` before final handoff or staging. Load `collapse-pass` directly for continuous indirection-reduction work. During review, escalate to `greenfield-clean-breaks` for ownership, lifecycle, API, package-boundary, clean-break, compatibility-refusal, or asymmetric-win decisions. After a substantive multi-file wave, consider `fresh-context-review` when an independent challenge could catch ownership, lifecycle, or type-shape mistakes; it delegates review, never execution. Keep procedures in skills; keep `AGENTS.md` to routing.\n","category":"root","tokens":1457}]}