ACC 1.0.0

CLI Reference

Use the command surface shipped by ACC 1.0.0, understand how it boots and routes work, and preserve command results as operational evidence.

Source of truth

CLI overview

The installed acc command resolves the release root, loads the unified gateway, completes manifest validation and runtime loading, then dispatches through the central command router.

This reference describes the public surface exposed by acc help and the routed subcommand help in version 1.0.0. The executable and its help output remain authoritative; check them again after changing releases.

acc version
acc help
Routing

Command model

Commands use a top-level verb, optionally followed by a group action and positional or named arguments.

acc <COMMAND> [SUBCOMMAND] [ARGUMENTS]

Direct commands

Commands such as version, status, and doctor route directly to one ACC view or operation.

Command groups

Groups such as docs, modules, and runtime route a second token to a focused operation. Required values are shown in angle brackets; optional values are shown in square brackets.

Some runtime commands create immutable records and later commands consume their IDs. Follow that chain in order; a *-latest convenience command resolves the latest eligible record for a module, while a *-read command retrieves a specific record.

Syntax

Global usage

ACC 1.0.0 exposes help entrypoints, but no global flags that apply across every command.

acc help
acc -h
acc --help
acc docs --help
acc release verify --help

The three top-level help forms print the complete command catalog. Python-backed groups including action, docs, release, andarchitecture also expose scoped -h and --help. Options belong to their specific subcommands; do not place them before the top-level command.

Public surface

Core command groups

These families organize the commands published by the version 1.0.0 help surface without creating a second command catalog.

Platform

info · stats · version · status · doctor

Inspect ACC identity, repository statistics, platform state, and diagnostics.

Controlled actions

action

List or run the health, marker-write, cache-reset, and migration actions.

Project governance

docs · release · architecture

Build documentation, validate releases, and evaluate architecture contracts.

Modules and runtime

modules · runtime

Inspect module lifecycle and use the state-only, governed runtime workflow.

Operations

service · config · registry · history

Inspect service, configuration, registry, and transaction-history state.

Evidence and assurance

security · event · evidence · audit · test

Validate controls, query evidence, inspect audit history, and run registered tests.

Run acc help for the canonical command-by-command syntax. For groups with scoped help, run acc <GROUP> --help. The runtime and modules routers print their accepted usage when an unknown group action is supplied.

Interpretation

Status and output conventions

Treat terminal output and persisted IDs as evidence, and use process status separately for automation decisions.

Boot first

Most commands perform the full manifest boot before dispatch. Action, docs, release, and architecture keep the same validation while suppressing successful boot detail.

Human-readable views

Core shell commands render labeled terminal views. Do not treat their presentation as a stable machine-readable schema.

Persisted identifiers

Governed runtime commands print identifiers such as decision, plan, approval, and evidence IDs for later read or latest commands.

Usage and diagnostics

Argument failures may write usage or diagnostic text to standard error; capture both streams when preserving failure evidence.

Commands that validate, build, package, mutate, or advance runtime state are not equivalent to read-only views. Review the scoped help and the intended target before running them.

Shell contract

Exit-code behavior

Use the actual command status, but account for the version 1.0.0 router behavior documented here.

0 — completed

Help and successfully completed commands return zero. In 1.0.0, an unknown top-level command also prints the full help and returns zero; its text must not be interpreted as successful command execution.

1 — rejected or failed

Boot failures, missing required arguments in guarded routes, and unknownmodules or runtime actions return one. Routed Python commands propagate their own non-zero failure status.

if acc release validate; then
  printf '%s\n' 'release validation passed'
else
  printf '%s\n' 'release validation failed' >&2
fi

Do not infer a richer, universal exit-code taxonomy for this release. When automating an unknown top-level input check, validate the command against the published help surface as well as checking $?.

Verified paths

Accurate examples

Start with read-only discovery, then use scoped help before entering build, mutation, or governed runtime flows.

Confirm identity and platform state

acc version
acc status
acc doctor

Discover controlled actions without running one

acc action list
acc action health --help

Inspect project governance interfaces

acc docs list
acc release --help
acc architecture status

Inspect modules and the latest runtime summary

acc modules list
acc modules dependencies list
acc runtime report
Continue

Install or return to the guide

Use the installation guide for a verified CLI, or return to Getting Started for the shortest operational path.