Skip to main content

Engineering Practice & Continuity

The question this page answers directly: "What happens to ChimeraMiND if something happens to the founder?"

The short answer is that continuity does not rest on one person's memory. It rests on four things that exist independently of any individual: a written architecture, an enforced test/CI gate, an internal knowledge base large enough to onboard a new engineer without a walkthrough, and an AI-agent-driven development process that already operates from those documents rather than from conversations.

1. The knowledge base is comprehensive and current​

The internal engineering wiki (chimera-dev-brain) holds 244 pages across 25 categories, covering every backend route group, core runtime module, ML model, service, and integration in the codebase. Every page carries a last_verified date and is re-verified on touch — pages that fall out of date are flagged (#stale, #drift, #gap) rather than silently trusted. This is not a stale onboarding doc; it is the working reference the codebase itself is developed against.

2. Development already runs on documented process, not memory​

ChimeraMiND's day-to-day engineering — including this documentation site — is produced through an AI-agent-driven workflow governed by a written operating contract (15 immutable rules covering verification-before-fix, root-cause-before-symptom, no-shortcuts, and mandatory documentation sync on every change). A dedicated patrol agent runs scheduled system health sweeps against a documented runbook, independent of any one person initiating it.

This means the process that built and maintains the platform is already reproducible by design — it does not require a specific individual to execute it, only access to the repository and the same operating contract.

3. Every change is gated, not vibes-based​

  • 13 GitHub Actions workflows enforce lint, type-check, security scanning, and end-to-end (Playwright) tests before code reaches production, across backend, desktop, web, admin, and mobile.
  • 477 test files with an enforced minimum coverage gate on every pull request — a change that drops coverage below the floor fails CI, it does not get a human judgment call.
  • Deploys are git push-triggered through CI, not manual server access — there is no "only the founder knows the deploy steps" failure mode.

4. Decisions are recorded, not remembered​

See the Decision Log — every non-trivial architectural choice is a dated, reasoned, numbered entry. A successor engineer reconstructs why the system is shaped the way it is from that log, not from a handoff meeting.

What this adds up to​

None of this claims the system runs itself with zero human input — it requires an engineer. What it establishes is that the required engineer does not have to be a specific person: the architecture is written down, the quality bar is enforced by CI rather than review discipline alone, and the process for extending the system is itself documented and repeatable. That is the concrete answer to the bus-factor question, not a promise.