Repository navigation
overview purpose
Canonical: docs/architecture/MONOREPO_PURPOSE.md.
Let a single human Chief operate many software projects through autonomous AI engineering with minimal manual work.
The desired operator experience:
Chief gives an objective. The system determines project context, routes work, executes, retries, verifies, and returns a concise result.
Project discovery, agent orchestration, task routing, policy enforcement, risk classification, health reporting, verification, evidence, release coordination, templates, optional generated-asset sync, portfolio observability.
These operate on projects. They must not become hidden runtime or build requirements of projects.
Every directory under projects/<domain>/<capsule>/ is a sovereign capsule. It owns source, manifests, lock state, runtime versions, configuration, environment contract, local first-party packages, tests, schemas, migrations, infrastructure, build, deployment, and operational documentation as applicable.
A capsule may depend on declared external systems or versioned artifacts. It must not depend on the Monorepo root merely because it currently lives inside the Monorepo.
| ID | Rule |
|---|---|
| I-01 | Project sovereignty — install, build, test, run, package, deploy-dry-run after extraction |
| I-02 | Root optionality — deleting root access must not break an extracted project |
| I-03 | No hidden parent dependency — no required resolve above the capsule root |
| I-04 | Human governs, agents execute |
| I-05 | Machine handles deterministic governance |
| I-06 | Executable evidence beats assumption — extraction test is decisive |
| I-07 | Existing mistakes do not redefine purpose |
| I-08 | Simplicity is a control |
| I-09 | Autonomy inside isolation |
| I-10 | State-of-the-art without churn |
When evaluating any implementation, ask:
- Does this reduce Chief's manual operational burden?
- Does this increase agent end-to-end execution capability?
- Does this preserve project sovereignty?
- Does this keep root optional?
- Can the rule be machine-enforced?
- Does it create human interruption for a deterministic outcome?
- Does it improve reliability without unnecessary complexity?
- Can the claim be proven by executable evidence?
Root-coupled projects are defects pending remediation, not precedents.
Named legacy demonstrator: projects/internal/golden-path/apps/web. It consumes @safrs/* from the root workspace. ADR 0006 records this as planned capsule migration.
projects/internal/control-center also consumes @sentra/token and @safrs/config from the root workspace. It is a local operator surface, not a product template.
Do not copy those patterns into new capsules.
- Architecture
- Capsule sovereignty
- Project capsules
- ADR 0006 —
docs/adrs/0006-standalone-project-capsules.md
SAFRS — the Sentra Agent-First Repository Standard — defines how a software repository should be structured, governed, and enforced when autonomous Artificial Intelligence agents perform a substantial share of engineering work by Sentra Artificial Intelligence.
SAFRS v1.1 addresses that problem through five coupled mechanisms:
- a six-layer repository architecture from Trust Boundary to Human Authority;
- a role-based permission model in which capability never implies trust;
- a four-tier risk model with cumulative mandatory controls;
- a multi-agent execution protocol with explicit task states and one mutation owner per bounded scope;
- a knowledge governance model that distinguishes current architecture, historical decisions, execution plans, Git history, and running code.
Built in Indonesia as part of the Sentra Artificial Intelligence ecosystem.
Sentra Artificial Intelligence · Source Repository · Official Website
Dr Ferdi Iskandar — Creator & Maintainer
LinkedIn ·
ORCID ·
Hugging Face ·
Kaggle ·
Medium ·
Substack ·
X ·
Threads
MyPrompt · Sentra Artificial Intelligence · Indonesia