Skip to content

Known Limitations

Aggregated directly from the "MVP Limitations" sections of each architecture document — nothing below is invented for this page. Follow the links for full context.

Execution

  • Execution is synchronous and single-process; the model field for "parallel" execution exists conceptually in the stage list but has no parallel implementation.
  • No retry/backoff policy is implemented beyond the retry_count field existing on AgentRunResult; retries default to zero and are not yet exposed via CLI.
  • There is no persisted "project-level default risk policy" — risk level is set per mission at creation time.

(Mission Orchestrator, Adapter Architecture)

Roles

  • The 27 built-in roles are fixed at this MVP stage; there is no CLI command yet to add or edit a custom role (assync role list/show/validate are read-only).
  • default_adapter is currently informational only — the orchestrator requires an explicit run-config entry per selected role.

(Role Pool)

Authorization

  • There is no authorization renewal flow yet — an expired authorization must be re-issued from scratch (via a new human decision).
  • Scoping authorization to a specific target_run_id is modeled but not yet enforced beyond target_mission_id matching.

(Authorization Model)

Decisions

  • There is no mission-side automatic re-evaluation after a decision resolves — a rejected risk-acceptance decision requires a separate, explicit assync mission abort call, rather than an automatic mission-state transition. Approving a decision does not, by itself, move the mission out of WAITING_FOR_AUTHORIZATION either — see the Quick Start.
  • required_authority is currently a free-text field (default "governance_authority"), not yet cross-checked against the role registry's non-executable Human Governance Authority entry.

(Decision Queue)

Synthesis

  • Evidence-classification precedence is currently applied per-finding, not used to resolve two findings that directly contradict each other with different evidence strength — synthesis currently surfaces this via conflicts rather than auto-resolving it (see the contradiction mock scenario).

(Synthesis Engine)

Storage

  • No schema-migration tooling exists yet; a schema_version bump would currently require a manual, out-of-band migration.
  • The cross-project registry store and a project's own runtime store are both FilesystemStore instances but are never the same instance — there is no automated check today that a registry root and a project's own runtime root can never accidentally coincide, beyond the nested-path rejection in projects/service.py::register_project.

(Runtime Storage)

Security

  • No production credentials, autonomous production actions, or release execution exist anywhere in this codebase — by omission, not by a runtime guard that could be bypassed.
  • The credential-redaction regex in the local-command adapter is a defense-in-depth measure, not a guarantee — callers must still avoid passing secrets into adapter input in the first place.
  • No sandboxing (containers, seccomp, etc.) is applied to the local command adapter beyond the executable allowlist, timeout, and output-cap controls.
  • The local command adapter's subcommand denylist currently only covers git; a real provider-CLI integration would need its own equivalent review before being added.

(Security Model, Adapter Architecture)

Not implemented at all

These are documented extension points, not partially-built features — implementing any of them was explicitly out of scope for this MVP:

  • Remote provider adapters (Claude Code, ChatGPT/OpenAI, Antigravity, local model) — only the deterministic mock adapter and the restricted local-command adapter exist today.
  • A ReviewPublisher (GitHub Checks / draft PR publisher) — no GitHub API is called anywhere in this codebase.
  • A webhook receiver, web application API, worker queue, or containerized execution.
  • A published PyPI package.

(Adapter Architecture — Future Integration Interfaces)