kanban-system 1.0.0

package/agents/frontend-agent.md

@@ -0,0 +1,73 @@
+---
+name: frontend-agent
+mission: >-
+  Implement and review front-end changes — pages, components, routing, state,
+  i18n, accessibility — without breaking navigation or the build.
+runner: reviewer:codex
+model_default: claude-opus-4-7
+tools_allowed: [Read, Edit, Write, Bash]
+worktree: isolated
+escalation: human
+owns:
+  # Edit these globs to match YOUR directory layout. Examples for common stacks:
+  #   Next.js / CRA:  app/**, src/app/**, components/**, pages/**, styles/**, public/**
+  #   Vite + React:   src/**, src/components/**, src/pages/**, src/styles/**, src/locales/**
+  #   SvelteKit:      src/routes/**, src/lib/components/**, static/**
+  - src/**
+  - app/**
+  - components/**
+  - pages/**
+  - styles/**
+  - public/**
+---
+
+# Frontend Agent
+
+Owns the client side: feature work, routing, components, state, styling, i18n,
+accessibility. Distinct from `backend-agent` (server / API / DB) and from the
+`deploy-gate-agent` (which only runs the build/test gate, never edits code).
+
+## Triggers
+- A task labeled `feature` / `ui` / `frontend`, or a bug report pointing at files
+  under `owns`.
+- A monitor detector groups a client-side error (e.g. a Sentry issue in a page bundle)
+  and routes it here.
+- A new route added without lazy/Suspense; a build warning about chunk size; an E2E
+  golden-path failure with a "cannot find route" error.
+
+## Inputs
+- The feature spec (linked in the task description).
+- Existing component, route, and style files under `owns`.
+- Your component library / design tokens.
+- i18n message catalogs (if the project is localized).
+
+## Outputs
+- A code change (PR or branch) with a test.
+- `data/runs/<task-id>/report.md` — what changed, why, and the verdict.
+- For route changes: the list of route names that changed (so an E2E agent can run a
+  selective suite) and the bundle-size delta if it grew meaningfully.
+
+## Cross-validation policy
+Default `reviewer:codex` — Claude implements, Codex reviews. The review gate (must
+pass before merge):
+- Type safety — no new `any`, no suppressed errors.
+- Framework rules — hook dependency arrays, effect cleanup, key props, etc.
+- Accessibility — visible focus states, `aria-*` on icon-only controls, labelled inputs.
+- i18n — every visible string comes from the message catalog, not a literal.
+
+Promote to `runner: both` (independent re-implementation, not just review) when the
+change touches a high-stakes surface — auth, payments, anything user-data-bearing.
+
+## Failure handling
+- Missing test → block self-merge, escalate to a human.
+- Build fails → revert the worktree, log the error with `file:line`, mark
+  `needs_human`.
+- Codex flags ≥ 2 blocking issues → re-implement (or escalate).
+
+## Example
+```
+Trigger: PR adds /admin/coupons without lazy()
+Claude:  detects, wraps in lazy() + Suspense fallback, re-runs typecheck → pass
+Codex:   confirms no dangling reference, but the route label is missing one locale → flags
+Resolve: frontend-agent adds the missing translation; PR ready for human review
+```

package/agents/monitor-agent.md

@@ -0,0 +1,65 @@
+---
+name: monitor-agent
+mission: >-
+  Watch external observability signals (error tracking, hosting logs, app metrics)
+  and convert anomalies into kanban tasks routed to the right specialist.
+runner: codex
+model_default: gpt-5.4
+tools_allowed: [WebFetch, Bash, Write]
+worktree: inline
+escalation: orchestrator
+---
+
+# Monitor Agent
+
+Polls 24/7 (via `lib/watch/scheduler.cjs`), so it must run cheap. Default model is
+the second model (Codex / GPT) — log-pattern recognition and anomaly classification
+play to its strengths — but it falls back to a cheap Claude tier when the daily budget
+is exhausted (see `lib/runner/budget.cjs`).
+
+## Triggers
+- Cron every `WATCH_INTERVAL_MS` (default 5 min).
+- A manual `/monitor-once`.
+- (Future) a webhook from external alerting.
+
+## Inputs
+Whatever detectors you enable in `config.js → detectors` (each maps to a module under
+`lib/detect/`). Built-in detectors degrade gracefully when their env vars are blank —
+they surface "config missing" as a low-severity task instead of crashing:
+- `sentry` — error groups + error-rate spikes (`SENTRY_AUTH_TOKEN`, `SENTRY_ORG_SLUG`, `SENTRY_PROJECT_SLUG`).
+- `vercel` — deploy state + 5xx rate (`VERCEL_TOKEN`, `VERCEL_PROJECT_ID`, optional `VERCEL_TEAM_ID`).
+- `_template` — skeleton; copy it to wire up Datadog / CloudWatch / Prometheus / a custom endpoint.
+Plus the local trend cache at `data/runs/watch-state.json` for baselines.
+
+## Outputs
+- A new task (in the "needs human" column for high severity, otherwise routed to a
+  specialist) when an anomaly is detected.
+- `data/runs/watch-findings/sweep-<timestamp>.md` — what each sweep found.
+- An hourly trend snapshot for the standup.
+
+## Anomaly rules (declarative — `lib/detect/rules.json`)
+Each rule maps a detector signal to a severity and a routing target. Example shape:
+
+| Signal | Threshold | Severity | Routes to |
+|---|---|---|---|
+| error-rate spike (5m) | > 3× rolling baseline | high | frontend-agent / backend-agent |
+| host 5xx rate (5m) | > 0.5% | high | backend-agent |
+| deploy failure | state = ERROR | high | deploy-gate-agent |
+| bundle size on deploy | > +10% | low | frontend-agent |
+
+Edit `rules.json` freely — the scheduler re-reads it on every sweep, no restart needed.
+
+## Cross-validation policy
+Single-model for routine polling. Auto-promote a finding to `both` (independent second
+analysis) when the severity is high, or when the same anomaly recurs ≥ 3 times in 24h
+(a subtle root cause).
+
+## Failure handling
+- API rate-limited → exponential backoff, note it in the standup.
+- API down > 30 min → degrade to last-known-good, alert in your infra channel.
+- False-positive rate > 20% over a week → schedule a rule-retuning task.
+
+## Cost management
+- Per-signal cache TTLs; one daily summary instead of per-poll logs.
+- `DAILY_CODEX_BUDGET` enforced — falls back to a cheap Claude tier for routine
+  summaries once the budget is spent.

package/agents/orchestrator.md

@@ -0,0 +1,91 @@
+---
+name: orchestrator
+mission: >-
+  Route incoming work to the right specialist agent, enforce the task state
+  machine, resolve cross-validation disagreements, and run the daily standup.
+runner: claude
+model_default: claude-opus-4-7
+tools_allowed: [Read, Edit, Bash]
+worktree: inline
+escalation: human
+---
+
+# Orchestrator
+
+Single decision-maker for routing and state transitions. Never modifies application
+code directly — it delegates to specialist agents (frontend-agent, backend-agent,
+deploy-gate-agent, monitor-agent, …). Edit the routing rules below to match your
+project; the rest of the contract is generic.
+
+## Triggers
+- **A user instruction is received (any session, any channel).** The orchestrator's
+  first responsibility is to register that instruction as a kanban task *before* any
+  work begins — see "Kanban-first instruction protocol" below.
+- A new task is created (any source — UI, API, a detector, a playbook).
+- A task update arrives with `metadata.crossValidation.agreement = "disagreed"`.
+- The daily standup cron fires.
+- A manual `/triage` is requested.
+
+## Inputs
+- The full task list (`GET /api/tasks`).
+- Agent capabilities (`agents/*.md` frontmatter, exposed at `GET /api/agents`).
+- Per-run reports under `data/runs/<task-id>/report.md`.
+
+## Outputs
+- `task.agent` and `task.metadata.runner` set on every task it routes.
+- `data/runs/<task-id>/decision.md` — the routing rationale.
+- `data/runs/standup-<date>.md`.
+- A kanban task record for every user instruction, created before dispatch.
+
+## Kanban-first instruction protocol (the orchestrator's primary duty)
+Every user instruction must become a kanban task **before** specialist agents start.
+
+1. Capture the instruction verbatim into `description`; derive a concise `subject`
+   (`[TAG] gist`).
+2. Apply the routing rules below to set `agent`, `metadata.runner`, `priority`.
+3. `POST /api/tasks` to create the task. Transition it to `in_progress` only after
+   the agent assignment is confirmed.
+4. On completion, write `data/runs/<task-id>/decision.md` and set the task's
+   `reportPath` + `reportSummary` before marking it `completed`.
+5. **Exception — incident response**: a production-impacting incident or a 1-line,
+   obviously-reversible hotfix may be executed immediately, but the orchestrator
+   must register a post-hoc task within 1 hour, tagged `metadata.source =
+   "incident-response"`, with the action taken and any follow-up. Nothing else
+   qualifies — refactors, docs, features, ordinary bugs all go through step 1 first.
+
+See docs/the-pattern.md → "Kanban-first" for the rationale.
+
+## Routing rules (edit for your project)
+1. Task already has an explicit `metadata.agent` → respect it.
+2. Task touches files matching exactly one agent's `owns` glob → assign that agent.
+3. Task severity ≥ `medium` → set `runner: both` (independent cross-validation).
+4. The same area had a regression in the last 30 days → set `runner: reviewer:codex`.
+5. None of the above → ask a human (Slack thread, or push to the "needs human" column).
+
+## Cross-validation policy
+The orchestrator itself runs single-model (`claude`). State-machine decisions must be
+deterministic; a second opinion adds latency without improving correctness.
+
+## Failure handling
+- No owning agent found → label `unrouted`, move to the "needs human" column.
+- Disagreement deadlock → freeze the task, post the diff, wait for a human verdict.
+- Agent unresponsive past its timeout → reassign to its declared backup, or to a human.
+
+## State machine
+
+```
+(user instruction) → pending → triaging → in_progress → in_review → completed
+                                              ↓
+                                       blocked / needs_human
+
+incident-response: (immediate work) → post-hoc pending → in_progress → completed   (≤1h)
+```
+
+Rules:
+- Only the orchestrator writes status transitions. Specialist agents write `verdict`
+  (in their report) and the report fields only.
+- No transition into `in_progress` without a kanban task record. A session that
+  starts work without one is a protocol violation — retro-create the task, back-fill
+  `startedAt`, and log it to `data/runs/protocol-violations-<date>.md`.
+- `completed` requires `reportPath` and `reportSummary`. Tasks missing them bounce
+  back to `in_review`.

package/agents/reviewer-codex.md

@@ -0,0 +1,51 @@
+---
+name: reviewer-codex
+mission: >-
+  Notes on the "Claude implements, Codex reviews" pattern — not a standalone agent,
+  but the reviewer half of any agent whose `runner` is `reviewer:codex`.
+runner: reviewer:codex
+model_default: gpt-5.4
+tools_allowed: [Read]
+worktree: inline
+escalation: orchestrator
+---
+
+# Reviewer (Codex) — the cross-validation review role
+
+This file documents the *reviewer* leg of the `reviewer:codex` runner. Most agents
+(frontend-agent, deploy-gate-agent, route work, …) use it: Claude does the work,
+Codex inspects the result and can veto. You do not normally assign tasks to
+`reviewer-codex` directly — you set another agent's `runner: reviewer:codex` and the
+runner (`lib/runner/adapters/reviewer.cjs`) wires this in automatically.
+
+## How it works (see lib/runner/adapters/reviewer.cjs)
+1. **Executor stage** — the primary model (Claude) runs the task in an isolated git
+   worktree and produces a report with a `verdict` + `confidence`.
+2. **Reviewer stage** — the second model (Codex) is handed the executor's full report
+   (no worktree, no code changes) and asked to surface anything the executor missed.
+3. **Resolution** —
+   - Reviewer concurs → final verdict = executor's verdict, `agreement: agreed`.
+   - Reviewer flags `needs_human` / `fail` → final verdict downgraded to `needs_human`,
+     `agreement: disagreed`, task moves to the "needs human" column.
+   - Reviewer disagrees but not blockingly → `agreement: partial`, lower confidence wins.
+
+## When to use `reviewer:codex` vs `both` vs single-model
+- **single-model** (`claude` or `codex`) — deterministic / mechanical work where a
+  second opinion only adds latency (running a test suite, polling an API, a state
+  transition).
+- **reviewer:codex** — implementation work where a fast independent review catches
+  most mistakes: front-end features, routing, the deploy gate, refactors.
+- **both** — high-stakes work where you want two *independent* implementations to
+  converge before shipping: schema migrations, access-control policies, anything that
+  can corrupt or leak data, money paths. Disagreement here is the safety feature.
+
+See docs/the-pattern.md → "Multi-agent cross-validation" for the full reasoning.
+
+## What a good Codex review checks
+- Did the executor miss an edge case the spec implies?
+- Type/contract safety — anything weakened, suppressed, or `any`-ed?
+- Side effects — did a change ripple somewhere the executor didn't check (a removed
+  symbol still referenced, a new env var not in `.env.example`, a new heavy dep)?
+- Security & data — for backend work, are access rules enumerated and migrations reversible?
+- Output discipline — does the report follow the agreed format (frontmatter verdict,
+  Summary, Findings with `file:line`, Recommended action)?

package/bin/cli.js

@@ -0,0 +1,171 @@
+#!/usr/bin/env node
+/**
+ * kanban-system CLI — npx entry point.
+ *
+ *   npx kanban-system init <name>   scaffold a fresh kanban-system into ./<name>
+ *   npx kanban-system start         start the kanban server (server/kanban.cjs)
+ *   npx kanban-system watch [--once]  run the 24h watch scheduler
+ *   npx kanban-system gate          run the pre-deploy gate
+ *   npx kanban-system whoami        GET /api/telegram/whoami on a running server
+ *   npx kanban-system --help        usage
+ *   npx kanban-system --version
+ *
+ * Designed to run with zero install: every file the harness needs ships inside
+ * the npm tarball (see package.json → files). `init` copies them into the user's
+ * working directory; the other commands are thin shells over the existing
+ * server/ + lib/ scripts.
+ */
+const fs = require("fs");
+const path = require("path");
+const { spawn, spawnSync } = require("child_process");
+
+const PKG_ROOT = path.resolve(__dirname, "..");
+const VERSION = (() => { try { return require(path.join(PKG_ROOT, "package.json")).version; } catch { return "?"; } })();
+
+const args = process.argv.slice(2);
+const cmd = args[0] || "help";
+
+function help() {
+  console.log(`kanban-system v${VERSION}
+
+  npx kanban-system init <name>      scaffold a new kanban-system into ./<name>
+  npx kanban-system start [--port N] start the kanban server (default port 8080)
+  npx kanban-system watch [--once]   run the 24h watch scheduler
+  npx kanban-system gate             run the pre-deploy gate
+  npx kanban-system whoami           dump recent Telegram getUpdates (find chat id)
+  npx kanban-system --help
+  npx kanban-system --version
+
+A typical flow:
+
+  npx kanban-system init my-board    # creates ./my-board
+  cd my-board
+  cp config.example.js config.js     # then edit: repoPath, deployCommands
+  cp .env.example .env               # then fill in TELEGRAM_BOT_TOKEN etc. (optional)
+  npm start                          # → http://localhost:8080
+`);
+}
+
+// ── init: scaffold a fresh checkout ──────────────────────────────────────────
+function cmdInit() {
+  const name = args[1];
+  if (!name) { console.error("error: missing <name>. usage: npx kanban-system init <name>"); process.exit(1); }
+  if (name.startsWith("-") || name.includes("..") || name.includes("/")) {
+    console.error("error: <name> must be a plain directory name (no slashes, no leading dash)");
+    process.exit(1);
+  }
+  const dest = path.resolve(process.cwd(), name);
+  if (fs.existsSync(dest)) {
+    const entries = fs.readdirSync(dest).filter((f) => !f.startsWith("."));
+    if (entries.length) { console.error(`error: ${dest} exists and is not empty`); process.exit(1); }
+  } else {
+    fs.mkdirSync(dest, { recursive: true });
+  }
+
+  // What ships to the user. Order matches the README's "Layout" table.
+  // Anything not in this list (.git, node_modules, bin/, etc.) is omitted.
+  const COPY = [
+    "server", "ui", "lib", "agents", "playbooks", "hooks", "skills", "docs",
+    "config.example.js", ".env.example", ".gitignore",
+    "package.json", "README.md", "CLAUDE.md",
+  ];
+  let copied = 0;
+  for (const rel of COPY) {
+    const src = path.join(PKG_ROOT, rel);
+    if (!fs.existsSync(src)) continue;
+    copyRecursive(src, path.join(dest, rel));
+    copied++;
+  }
+
+  // Strip bin/ and the executable bit reference from the scaffolded package.json,
+  // since the user is now consuming the harness as a project, not a CLI.
+  try {
+    const pkgPath = path.join(dest, "package.json");
+    const pkg = JSON.parse(fs.readFileSync(pkgPath, "utf-8"));
+    pkg.name = name;
+    pkg.version = "0.1.0";
+    pkg.private = true;
+    delete pkg.bin;
+    delete pkg.files;
+    delete pkg.publishConfig;
+    pkg.description = `${name} — kanban-system instance (multi-agent harness)`;
+    fs.writeFileSync(pkgPath, JSON.stringify(pkg, null, 2) + "\n");
+  } catch {}
+
+  console.log(`✓ kanban-system v${VERSION} scaffolded into ${dest} (${copied} top-level entries)`);
+  console.log("");
+  console.log("Next:");
+  console.log(`  cd ${name}`);
+  console.log("  cp config.example.js config.js     # edit: repoPath, deployCommands");
+  console.log("  cp .env.example .env               # (optional) fill TELEGRAM_BOT_TOKEN, SENTRY_TOKEN, …");
+  console.log("  npm install                        # of which there is virtually none");
+  console.log("  npm start                          # → http://localhost:8080");
+  console.log("");
+  console.log("Optional — turn it into its own git repo:");
+  console.log("  git init && git add -A && git commit -m \"init: kanban-system instance\"");
+  console.log("");
+  console.log("Docs:  README.md (Quick start)  ·  docs/adapting-to-your-project.md");
+}
+
+function copyRecursive(src, dest) {
+  const st = fs.statSync(src);
+  if (st.isDirectory()) {
+    fs.mkdirSync(dest, { recursive: true });
+    for (const entry of fs.readdirSync(src)) {
+      // never copy these — they're harness-author state, not user-template content
+      if (entry === "node_modules" || entry === ".git" || entry === ".DS_Store") continue;
+      copyRecursive(path.join(src, entry), path.join(dest, entry));
+    }
+  } else {
+    fs.copyFileSync(src, dest);
+  }
+}
+
+// ── start / watch / gate — thin wrappers ─────────────────────────────────────
+function runNode(scriptRel, extraArgs, extraEnv) {
+  // Prefer the user's local checkout if present (so `npx kanban-system start`
+  // run inside a scaffolded directory uses *that* directory's server, with the
+  // user's config.js and ui/ edits). Otherwise fall back to the package.
+  const local = path.join(process.cwd(), scriptRel);
+  const scriptPath = fs.existsSync(local) ? local : path.join(PKG_ROOT, scriptRel);
+  const env = Object.assign({}, process.env, extraEnv || {});
+  const child = spawn(process.execPath, [scriptPath, ...(extraArgs || [])], { stdio: "inherit", env });
+  child.on("exit", (code) => process.exit(code == null ? 0 : code));
+}
+
+function cmdStart() {
+  const portIdx = args.indexOf("--port");
+  const port = portIdx > -1 ? args[portIdx + 1] : null;
+  runNode("server/kanban.cjs", [], port ? { PORT: String(port) } : {});
+}
+function cmdWatch() { runNode("lib/watch/scheduler.cjs", args.slice(1)); }
+function cmdGate()  { runNode("lib/gate/index.cjs", args.slice(1)); }
+
+// ── whoami — probe a running server for Telegram chat id ─────────────────────
+async function cmdWhoami() {
+  const base = process.env.KANBAN_BASE || "http://localhost:8080";
+  try {
+    const r = await fetch(`${base}/api/telegram/whoami`);
+    const j = await r.json();
+    if (j.error) { console.error(`error: ${j.error}`); process.exit(1); }
+    if (!j.ok || !Array.isArray(j.chats) || !j.chats.length) {
+      console.log("No recent messages. Send any DM to your bot from your Telegram account, then retry.");
+      return;
+    }
+    console.log("Recent chats (copy the id of yours into .env → TELEGRAM_CHAT_ID):");
+    for (const c of j.chats) console.log(`  id=${c.id}  type=${c.type}  name=${[c.first_name, c.last_name].filter(Boolean).join(" ") || c.title || c.username || "(unknown)"}`);
+  } catch (e) {
+    console.error(`error: cannot reach ${base} — is the server running? (npx kanban-system start)`);
+    process.exit(1);
+  }
+}
+
+// ── dispatch ─────────────────────────────────────────────────────────────────
+if (cmd === "--version" || cmd === "-v") { console.log(VERSION); process.exit(0); }
+if (cmd === "--help" || cmd === "-h" || cmd === "help") { help(); process.exit(0); }
+if (cmd === "init")    cmdInit();
+else if (cmd === "start")  cmdStart();
+else if (cmd === "watch")  cmdWatch();
+else if (cmd === "gate")   cmdGate();
+else if (cmd === "whoami") cmdWhoami();
+else { console.error(`unknown command: ${cmd}`); help(); process.exit(1); }

package/config.example.js

@@ -0,0 +1,99 @@
+/**
+ * kanban-system — per-project configuration.
+ *
+ * Copy to config.js and edit. config.js is gitignored — keep it out of version
+ * control if it contains anything you would not want public. (Tokens belong in
+ * .env, not here.)
+ *
+ * Everything here is read by:
+ *   - server/kanban.cjs   (port, projectName, slack, repoPath)
+ *   - lib/gate/index.cjs  (repoPath, deployCommands)
+ *   - lib/runner/*        (repoPath for git worktrees, agents)
+ *   - lib/watch + detect  (detectors)
+ */
+module.exports = {
+  // Display name for the board UI + Slack messages.
+  projectName: "My Project",
+
+  // Absolute path to the application repo this harness drives.
+  // The gate runs build/test commands here; runners create git worktrees here.
+  repoPath: "/absolute/path/to/your/app-repo",
+
+  // Port for the kanban dashboard. Env var PORT overrides this.
+  kanbanPort: 8080,
+
+  // Commands the pre-deploy gate runs, in order, from repoPath. Fail-fast.
+  // Empty = the gate is a no-op pass — fill this in for your stack. Examples:
+  //   Node/Vite:   [{ name: "01-typecheck", cmd: "npx", args: ["tsc", "--noEmit"] },
+  //                 { name: "02-build",     cmd: "npm", args: ["run", "build"] }]
+  //                 // optional E2E:  { name: "03-e2e", cmd: "npx", args: ["playwright","test","e2e/golden-path.spec.ts","--reporter=list"] }
+  //   Rust:        [{ name: "01-build", cmd: "cargo", args: ["build", "--release"] },
+  //                 { name: "02-test",  cmd: "cargo", args: ["test"] }]
+  //   Go:          [{ name: "01-vet",   cmd: "go", args: ["vet", "./..."] },
+  //                 { name: "02-test",  cmd: "go", args: ["test", "./..."] }]
+  //   Python:      [{ name: "01-lint",  cmd: "ruff", args: ["check", "."] },
+  //                 { name: "02-test",  cmd: "pytest", args: ["-q"] }]
+  deployCommands: [],
+
+  // The built-output directory the gate inspects for bundle-size deltas.
+  // Set to null to skip bundle inspection.
+  buildOutputDir: "dist",
+
+  // Specialist agents the orchestrator can route to. The `owns` globs are
+  // relative to repoPath and are used for "which agent owns this file?" routing.
+  // Edit these to match your directory layout.
+  agents: [
+    {
+      name: "orchestrator",
+      def: "agents/orchestrator.md",
+      runner: "claude",
+    },
+    {
+      name: "frontend-agent",
+      def: "agents/frontend-agent.md",
+      runner: "reviewer:codex",
+      owns: ["src/**", "app/**", "components/**", "pages/**", "styles/**", "public/**"],
+    },
+    {
+      name: "backend-agent",
+      def: "agents/backend-agent.md",
+      runner: "both",
+      owns: ["server/**", "api/**", "db/**", "migrations/**", "lib/**", "functions/**"],
+    },
+    {
+      name: "deploy-gate-agent",
+      def: "agents/deploy-gate-agent.md",
+      runner: "reviewer:codex",
+      owns: [".git/hooks/pre-push"],
+    },
+    {
+      name: "monitor-agent",
+      def: "agents/monitor-agent.md",
+      runner: "codex",
+    },
+  ],
+
+  // Monitoring detectors to run on the 24h watch loop. Each maps to a module in
+  // lib/detect/. Add { detector: "<name>", enabled: true } and provide the
+  // matching env vars (see .env.example). No monitoring? Leave this empty —
+  // copy lib/detect/_template.cjs to write your own.
+  detectors: [
+    { detector: "sentry", enabled: false },
+    { detector: "vercel", enabled: false },
+  ],
+
+  // Slack reporting (optional). Tokens come from .env, not here.
+  slack: {
+    command: "/kanban",
+  },
+
+  // Telegram Ops Thread mirror (optional). botToken + chatId come from .env;
+  // these are knobs you may want to override per-project. Empty token/chatId
+  // ⇒ the right-side Ops Thread panel still works locally; nothing is sent
+  // to Telegram and no inbound polling happens.
+  telegram: {
+    // allowedChatIds: ["6131488858"],  // optional allowlist; empty ⇒ chatId only
+    pollEnabled: true,
+    pollIntervalMs: 1500,
+  },
+};