Skip to main content
Syndicate Code home
Download + Run
Version:

Changelog

About this changelog

This changelog documents normative decisions, specification changes, and architectural commitments for Syndicate Code. Each entry maps to a resolved open decision or a specification revision.

2026-04-10

Governance and approval scope

  • OD-035 DECIDED — Checkpoint approvals support explicit scope: once, session, and policy. Reusable grants write authoritative session_grant, session_grant_ref, and invalidation records instead of relying on implicit permit reuse.
  • OD-036 DECIDED — Headless mode is modeled as governance-suspended mode. --no-tui is an alias for --governance-suspended --governance-suspended-reason "headless_mode_implicit".
  • OD-037 DECIDED — Governance-suspended sessions still run policy evaluation, permit issuance, and audit writes; they suppress interactive checkpoints only.
  • OD-038 DECIDED — Governance-suspended mode can be prohibited or tier-gated per workspace by governance_mode_policy; rejected starts emit session.governance.rejected and exit code 4.
  • OD-039 DECIDED — Policy bundles may create policy_session_grant records at session open for governance-suspended / CI runs when policy_session_grant_rule matches workspace and trust tier.
  • OD-040 DECIDED — Auto-permit rules are deterministic policy-sourced approvals recorded as auto_permit before execution, with condition evaluation tied to canonical request data and active trust tier.

2026-03-27

Core architecture decisions

  • OD-003 DECIDED — Audit events are HMAC-signed using an installation-local key derived from a first-run installation secret. Legacy rows without signatures remain verifiable for chain integrity.
  • OD-004 DECIDED — Session namespacing: shared control plane, single policy version, and isolated proposal/permit scopes per session.
  • OD-005 DECIDED — Cross-session trust is opt-in; explicit operator grant with TTL required for trust carry-over between sessions.
  • OD-006 DECIDED — Audit chain is segmented per session. Each session starts with a genesis event linked to the prior session terminal hash.

Autonomy and specialist orchestration

  • OD-013 DECIDED — Default delegation depth is 2 hops; deeper delegation requires explicit policy override.
  • OD-028 DECIDED — Default maximum parallel specialists is set to 3.
  • OD-029 DECIDED — Specialist registry is API-first with canonical storage in the database; YAML is an import format.
  • OD-030 DECIDED — Specialist reuse follows declared scope: session_scoped or invocation_scoped.

Canonicalization and approval

  • OD-014 DECIDED — Trust transitions use a normative evidence-class structure with policy-configurable numeric thresholds and conservative defaults.
  • OD-015 DECIDED — Repository-state binding is policy-configurable and enabled by default in governed/enterprise posture.
  • OD-016 DECIDED — Model family is binding in governed/enterprise mode; individual mode binds at provider class.
  • OD-017 DECIDED — Shell canonicalization captures a policy-defined set of environment variables, including PATH by default.
  • OD-018 DECIDED — Default permits are bounded multi-use within an approved envelope, with one-time permits available by policy.

Audit and evidence

  • OD-019 DECIDED — Session genesis includes prior session terminal hash to preserve cross-session integrity without external checkpoint storage.
  • OD-020 DECIDED — Audit export uses full hash-chain export and chain verification (no separate signed manifest in v1).
  • OD-021 DECIDED — Older payloads may be compressed when deterministically decompressible; hash verification is always against decompressed payload.

Provider routing

  • OD-022 DECIDED — local provider class is host-local only in v1; remote operator-managed inference is treated as hosted/custom.
  • OD-023 DECIDED — Evidence fidelity is dimensioned; missing token accounting is represented as not_available without collapsing all fidelity dimensions.
  • OD-024 DECIDED — System prompt capture is policy-configurable: hash+reference in individual mode, full capture in enterprise/regulated mode.

Context provenance

  • OD-025 DECIDED — Context truncation uses policy-defined priority classes with recency tie-breakers.
  • OD-026 DECIDED — Cross-session memory is pre-approved at write time and revalidated for policy compatibility at inclusion time.
  • OD-027 DECIDED — Redaction strategy is policy-configurable per data class with conservative defaults.

Policy versioning

  • OD-031 DECIDED — Dual authorization remains policy-configurable for enterprise/governed deployments and defaults off in v1 single-operator mode.
  • OD-032 DECIDED — Policy dry-run is supported as offline evaluation against recent historical events, reporting invalidated permits/approvals before activation.
  • OD-033 DECIDED — Compatibility window uses both constraints: max version distance and max age, whichever expires first.

Observability

  • OD-034 DECIDED — Telemetry is consent-gated and pluggable: local metrics are always available; remote export is opt-in and can target Syndicate endpoint (individual) or operator endpoint (enterprise).

2026-03-25

Core architecture decisions

  • OD-001 DECIDED — v1 is single-user with multi-tenancy seams built in from the start. tenant_id columns on all key tables; v1 always uses 'default'.
  • OD-002 DECIDED — Control plane is gRPC-first. The syndicate binary supports two topologies (local embedded and remote endpoint) sharing a single gRPC service definition.

Multi-user seams adopted

  • tenant_id TEXT NOT NULL DEFAULT 'default' on audit_events, sessions, workspace_bindings, secrets, policies
  • Operator identity record structured as (tenant_id, operator_id) tuple; in v1 tenant_id = 'default'
  • Workspace binding key is (tenant_id, workspace_path)
  • gRPC metadata reserves x-syndicate-tenant header; v1 ignores it
  • All queries include WHERE tenant_id = ? even in v1

Open decisions

The following decisions remain open and are documented in the Open Decisions Log:

  • OD-008 — Default policy bundles for enterprise vs individual (Option C recommended)
  • OD-009 — Capability granularity for UI automation vs shell execution (Option B recommended)
  • OD-010 — Should read-only operations require permits? (Option C recommended)
  • OD-011 — Should provider invocation always be governed? (Option A recommended)
  • OD-012 — Canonical format for policy rules (Option A recommended)