ACE CLI

Secure, profile-aware operations for ACE on macOS, Windows, and Linux.

Workspace contract portfolios can be inspected with ace portfolios list --json (paged response; --search, --skip, and --take supported). Use the returned portfolio UUID with ace contracts list --portfolio <uuid> --json to filter the contract register on the server. ace portfolios list --contract <identifier> --json includes containsContract for each portfolio. Portfolio creation and membership editing currently use the web app's Contracts workflow.

Customers install the official CLI from npm, then authorize it in the browser:

npm install -g @cadenceintelligence/ace-cli
ace version --json
ace skill sync --json
ace onboard

ace version compares the installed package with the versions advertised by the selected ACE API. Install @latest only when the command reports an older CLI (or when an older CLI does not recognize ace version). ace skill sync installs or updates the canonical ace-operations skill and verifies its SHA-256 revision before writing it.

After capability discovery, agents can inspect contracts, download reviewed source documents, and submit an explicitly approved Services Agreement draft:

ace capabilities --json
ace context search "<contract-number-or-topic>" --json
ace contracts context <ace-id> --json
ace contracts financials <ace-id> --total-value <amount> \
  --fully-executed-subk <amount> --invoiced <amount> --expensed <amount> \
  --yes --json
ace context link-inbox <message-id> --contract <ace-id> --role <role> --yes --json
ace intake create --program "<intake label>" \
  --approval-note "<authorization basis>" --yes --json
ace documents upload <source-file> --contract <ace-id> --document-type <code> \
  [--vendor <name-or-id>] [--action <base|mod-label|action-id>] \
  --relationship-role <role> --approval-note "<authorization basis>" --yes --json
ace documents list --contract <contract-number-or-ace-id> --json
ace documents download <document-id> --output <source-file>
ace vendors search "<vendor name or UEI>" --json
ace milestones input-template
ace milestones list <contract> --include-rejected --json
ace milestones preview <contract> --input <milestone.json> --json
ace milestones add <contract> --input <milestone.json> \
  --expected-preview-hash <preview-hash> \
  --approval-note "Approved exact source-backed proposal." --yes --json
ace milestones draft <contract>/<milestone-number> --file <pre-invoice.pdf> \
  --approval-note "Reviewed the prepared Government pre-invoice." --yes --json
ace milestones schedule <contract>/<milestone-number> --date <YYYY-MM-DD> \
  --date-basis "Acceptance memo dated 2026-08-14; month 12 is the later trigger." \
  --approval-note "Contingency resolved; scheduling the operative date." --yes --json
ace layflat input-template
ace layflat preview <contract> --input <layflat.json> --json
ace layflat apply <contract> --input <layflat.json> \
  --expected-preview-hash <preview-hash> \
  --approval-note "Reviewed exact action and SubK allocations." --yes --json
ace burndown input-template
ace burndown show <contract> --json
ace burndown preview <contract> --input <burndown.json> --json
ace burndown apply <contract> --input <burndown.json> \
  --expected-preview-hash <preview-hash> \
  --approval-note "Reviewed manual vendor, CLIN, obligation, and invoice entries." --yes --json
ace generations manifest-template
ace generations reconcile <contract> --input <flowdown.json> --json
ace generations readiness <contract> --vendor <name-or-id> --action <base-or-mod> --json
ace generations modification-readiness <contract> \
  --vendor <name-or-id> --action <modification> --json
ace generations readiness <contract> --manifest <manifest.json> --json
ace generations request <contract> --manifest <manifest.json> \
  --expected-manifest-hash <readiness-hash> --approval-note "<review basis>" --yes --json
ace generations runs <contract> --json
ace generations status <contract> <run-id> --json
ace generations review <contract> <run-id> --json
ace generations advice-review <contract> <run-id> --json
ace generations advice-approve <contract> <run-id> \
  --expected-advice-hash <advice-hash> --approval-note "<review basis>" --yes --json
ace generations source-manifest <contract> <run-id> --format docx \
  --output Source-Manifest-For-Reference-<vendor>-ACE.docx
ace generations source-manifest <contract> <run-id> --format json \
  --output Source-Manifest-For-Reference-<vendor>-ACE.json
ace generations render-preview <contract> <run-id> --output <review.docx> --json
ace generations diff <contract> <successor-run-id> --json
ace generations render <contract> <run-id> --expected-artifact-hash <render-hash> \
  --approval-note "Reviewed deterministic render." --yes --json
ace generations preview <contract> --file <draft.docx> --manifest <manifest.json> \
  --vendor <vendor-name-or-id> --action <base-or-mod-reference> \
  --allocation-line <line-id-or-reference-if-needed> --json
ace generations submit <contract> --file <draft.docx> --manifest <manifest.json> \
  --vendor <vendor-name-or-id> --action <base-or-mod-reference> \
  --allocation-line <line-id-or-reference-if-needed> \
  --expected-manifest-hash <preview-hash> --approval-note "<review basis>" --yes --json
ace templates list --json
ace frfs list --take 50 --json
ace frfs show <frf-id> --json
ace marketplace list --take 50 --json
ace platform templates preview --document <document-id> --version <version> \
  --family <services_agreement_base|services_agreement_modification> \
  --bindings <binding-schema.json> --activate --json
ace platform templates register --document <document-id> --version <version> \
  --family <services_agreement_base|services_agreement_modification> \
  --bindings <binding-schema.json> --activate --expected-preview-hash <preview-hash> \
  --approval-note "Approved exact template and complete highlighted binding map." --yes --json

Registry commands use server-side pagination and search. Contract, vendor, contact, FRF, and marketplace JSON output remains an array of the returned page's items; documents return { items, totalCount } and accept --skip with --limit.

ace templates list and ace templates show are read-only inputs to generation. SF-26 generation resolves the base family; SF-30 generation resolves the modification family. The selected action, not contentMode, controls that choice, and readiness reports the frozen instrument, family, version, and binding-schema hash. Registry preview and registration are platform operations: the API requires the system-level platform_admin role, which workspace administrators cannot grant or inherit.

For normal deterministic drafts, use generations generate <contract> --manifest manifest.json --expected-manifest-hash SHA256 --approval-note TEXT. After reviewing the readiness result and confirming the operation, ACE saves the draft and its agreement/funding records together. A failure rolls those records back. Retry the same inputs after an uncertain response; the API returns an already saved draft without duplicating it. The CLI verifies the returned document against its run.

The advanced generations request, render-preview, and render workflow remains for staged work, including explicit modification-advice approval. Optional missing source tasks do not block otherwise renderable review drafts. Status output includes the agreement reference and selected funding; legacy advisory-only runs may use the existing hash-bound render commands after backend revalidation.

Generation storage is always review-gated. It does not execute, file, send, or advance the contract workflow.

Payment milestone activation is hash-bound. A local agent may inspect downloaded, hash-verified ACE evidence and prepare one JSON proposal per milestone. milestones preview resolves every citation inside the selected contract, calculates a Government invoice target only from an exact evidence-backed date, and binds the result to a preview hash. milestones add re-previews, requires that exact hash and explicit human authorization, activates the row, and verifies the stored result. That confirmation is the approval event; ACE does not create a redundant second review task or invent a date from a relative source phrase.

An activated milestone then leaves AwaitingContingency one of two ways, and both refuse to run unless the row's own read model says they apply (canDraftInvoice and canScheduleContingency). milestones draft is for "the condition is met and the invoice goes out now": ACE does not generate the pre-invoice, so the command requires exactly one of --file or --document-id. New files use the normal SHA-256 upload handshake; an existing document must already be classified as INVOICE, filed to the same contract, and have stored bytes matching its recorded SHA-256. The command advances the row to PreInvoiceDrafted. A milestone that has no source date is dated to the day it was drafted and carries no pre-invoice lead, so a row that was just worked never reads as overdue. milestones schedule is for "the condition is settled but the date is still ahead" — the common shape when a contingency reads "on acceptance, or end of month 12, whichever is later". It records the resolved date with its basis, moves the row to NeedsPreInvoice, and uses up to the standard 45-day lead based on the runway remaining so ACE surfaces it in time instead of the reviewer holding the date in their head. Neither command has a server-side preview route, so both print a before/after diff of status, milestone date, Government invoice target, and lead days, and require a typed confirmation before mutating. Both requests are bound to the reviewed milestone revision; concurrent changes return a conflict, and an exact retry is a no-op.

Lay-flat updates are also hash-bound. The input identifies stable allocation lines and Government-action cells rather than aggregate vendor totals. One line may span several action columns, and one vendor may have several lines. Actual Services Agreements remain distinct draftId lineages in the vendor workspace.

Services Agreement registration accepts Draft, InReview, PendingSignature, PartiallyExecuted, and FullyExecuted. Historical VendorRedline and ReadyForSignature codes remain accepted. Fully executed registration defaults to the selected cell's SubK amount; --fully-executed-amount is an optional override. Review the preview: a non-executed successor removes that cell's contribution from the fully executed total. Direct lay-flat status/amount edits also synchronize the contract total. Existing-version stage changes are currently available through the web row selector, not a CLI mutation. Use actionEdits to correct an existing action's SF-26/SF-30 kind, modification reference, source document, or display order. The server requires an SF-26 source for the base action and an SF-30 source for a modification, prevents duplicate positions and source links, and includes every before/after metadata change in the hash-bound preview. Negative allocation adjustments are accepted only for SF-30 modifications so de-obligations remain in the action column where they occurred. ACE still refuses to replace a human-entered action, fee, or allocation by default. A reviewed correction must set overrideHumanValue: true on the affected edit; the hash-bound preview and confirmed apply are the human approval. An overrideReason is optional when extra context would improve the audit record. layflat apply re-previews, requires the exact reviewed hash and approval note, writes one audited revision with the signed-in person plus ace_engine origin, and reads the contract back to verify it. Inputs may add allocation lines with a linked vendor, a free-text provisional vendor label, or no vendor yet. Search workspace vendors first with ace vendors search. Use a reviewed vendorId for an existing match. When no match exists, an explicitly reviewed vendorLabel plus createVendor: true creates the minimal workspace vendor, participation, and tab as part of the hash-bound preview. A label without that flag remains provisional and creates no vendor tab. Use rowVendorEdits with the stable contractAllocationLineId to assign an existing provisional row to a verified vendor ID or an explicitly created vendor without replacing the row's amounts or history. Direct edits in the web lay-flat may also create or reuse a workspace vendor from an explicitly entered name. rowRemovals deletes an erroneous, unexecuted allocation line and all of its action cells in the same hash-bound revision. ACE refuses the removal when the row anchors a document, payment milestone, contract note, generation run, or fully executed Services Agreement amount. To consolidate duplicate rows, update the surviving row's cells and remove the duplicate in one preview so the before/after totals remain explicit. An ACE agent must set overrideHumanValue: true when the row contains human-entered values. actionFeeEdits records the one ONI Fee and one Rapid Capabilities Fee value for each SF-26/SF-30 action; fees are never assigned to vendor rows. Provide ratePercent from 0 through 10 in 0.5% increments to calculate against the action's post-edit SubK total, or leave the rate null and provide a manual amount override. rowEdits stores an optional note on one stable allocation line, and allocation status accepts drafting, in_review, or fully_executed. Status is a manual operational flag for now; it is not derived from a document ID or document status. ACE may populate empty or ACE-owned cells and notes, but the server rejects any attempt by ACE automation to overwrite a human-entered value.

Inbox context linking keeps the preserved email canonical in ACE and adds a hash-bound, audited relationship to an ACE ID. Unresolved correspondence may inform a marked review draft, but it is excluded from signature context until a human resolves the Inbox review state.

Active inbox context can be removed without deleting provenance:

ace context unlink-inbox <message-id> --contract <ace-id> --yes --json

ACE previews the exact relationship before removing it. The inactive link remains visible as history and may later be restored through the ordinary link preview flow.

If an ACE operation fails, ace support report collects allowlisted diagnostics, shows a server-sanitized preview, and requires explicit approval before sending. It can use a rate-limited anonymous lane when authentication itself is broken; it never accepts passwords, tokens, cookies, attachments, or browser sessions.

generations reconcile is a read-only ONI-prime financial check. It verifies the exact ACE document IDs and hashes behind the upstream CLIN/SLIN total and named ONI Operations and Rapid Capabilities deductions, calculates the vendor amount, and routes missing, provisional, low-confidence, non-binding, or conflicting evidence to bounded agent tasks or human decisions. A proposal variance permits only a not-for-signature draft until a human resolves it.

When attribution is not yet clear, documents upload can use --create-ace-id --program "<intake label>" to allocate a minimal Intake record and link the source in one guarded operation. An ACE ID does not assert a contract number or execution state. The CLI refuses to guess between an existing ACE ID, a new provisional ACE ID, and explicitly approved --unassigned workspace staging.

Generic source uploads store the reviewed --document-type as confirmed; OTHER is a valid intentional choice and does not create an automatic review task. Vendor documents (PROPOSAL, REPS_CERTS, W9) accept --vendor; action documents (SF26, MOD_REQ, SF30) accept --action; and Services Agreements or updated proposals require both --vendor and --action. The contract action is the base award or a specific modification, not an allocation line. An SF26 or SF30 uploaded with --action becomes that action's controlling lay-flat source document. Linking a later file replaces the clickable source in the contract matrix while retaining earlier files in the workspace Documents library and audit history. Contract-bucket confirmation and Services Agreement review remain separate lifecycle gates. ace generations submit is the validated SubK storage command. External-agent preview and submit resolve and hash-bind a real linked vendor, a stable allocation line, and its SF-26/SF-30 action. Submit creates an immutable external_agent Services Agreement run and associates the document with that scope, so it appears in the vendor's Services Agreements history. Omit --allocation-line only when the vendor has exactly one line; use --supersedes-run-id only for the next version of the same agreement.

generations request creates an immutable server-generation record. It accepts only the active registered template version and freezes the template, binding-schema, source-manifest, and field-ledger hashes. Deterministically ready SF-30 modifications render without an LLM by default. Add --request-modification-draft-advice only when the operator explicitly wants Bedrock to propose source-cited narrative sections; that opt-in run pauses for exact-hash human approval before rendering. render-preview --output deterministically substitutes evidence-backed values, downloads the exact transient DOCX, and verifies its SHA-256 against the preview; render stores only that exact reviewed hash as a NeedsReview draft. Updating a draft creates a new immutable version in the same draft lineage and supersedes the previous run only after the new artifact is stored. generations diff compares completed same-lineage versions by exact artifact hash, Word package parts, and aligned reviewer-visible text.

Generation automatically appends to the Services Agreement history selected by contract, vendor, and contract action. The allocation line remains attached to the individual version for financial evidence but does not split the history. --draft-id, --supersedes-run-id, and --supersedes-document-id are optional assertions that protect automation from stale state; they do not choose whether a new history is created. Do not overwrite or re-upload a prior artifact. The server assigns the next version and preserves every prior document.

Template registration is preview- and approval-gated. Every highlighted text surface must be explicitly bound, and a binding that also matches non-highlighted text is rejected. Missing field values become work items; ACE never supplies a plausible value merely to complete the document.

ACE developers use the checked-out repository instead of installing the public package:

npm install
npm run ace-dev -- onboard

After onboarding, verify the connected identity and environment:

ace auth whoami --json
ace doctor
ace capabilities

ace defaults a first-time user to production. Developers opt into the development environment with ace-dev or --profile development. Guided onboarding opens ACE sign-in, stores the rotating session in the native credential store, verifies capabilities, and prints the matching authenticated agent-management URL:

ace onboard                    # https://ace.cadenceintel.ai
npm run ace-dev -- onboard     # https://ace-dev.cadenceintel.ai

The CLI uses the operating system's native credential store, restricts remote APIs to built-in ACE profiles, refreshes sessions automatically, and applies additional confirmation to production mutations. It never extracts browser credentials or stores tokens in plaintext. ace capabilities authenticates to the active profile and reports the commands supported by both that environment and the installed CLI, plus CLI and local skill revision compatibility. The API keeps reads available for diagnosis but rejects mutations from unsupported CLI versions or an explicitly reported stale skill revision.

See the repository's ACE CLI Access and Automation guide for setup, commands, approval gates, and platform requirements.

Review a purchase request

In an environment with PR intake deployed, use the revision ID from prs list. Several PRs may belong to one permanent ACE record. Inspect source context and existing-record suggestions before proposing a new effort. prs list/show retain recommendationSummary and each candidate's strengthLabel, isRecommended, and evidence (document ID/hash, filename, physical PDF page, PR number, optional line, source snippet, and text/OCR label). Exact PR references in linked SF-26/SF-30 sources can suggest an existing record even when the incoming PR says TBD. Conflicts and incomplete award inspection suppress a single recommendation. Download cited evidence with ace documents download <document-id> --output <path> and verify OCR against the PDF before proposing a link. A recommendation never changes a relationship or financial totals by itself.

ace --profile development prs list --take 25 --json
ace --profile development prs show <revision-id> --json
ace --profile development prs preview <revision-id> --action create_intake --program "Example pilot" --review-version <reviewVersion> --note "Confirmed a new effort" --json
ace --profile development prs apply <revision-id> --action create_intake --program "Example pilot" --review-version <reviewVersion> --note "Confirmed a new effort" --expected-preview-hash <previewHash> --yes --json

Use attach_existing --contract <ace-id|uuid|number> to link an existing record, disregard to resolve the shared proposal while retaining evidence, or leave_unresolved to save a note and leave it pending. All actions require an administrator, the reviewed version/hash, and prior explicit human approval. Production retains its confirmation guard. Apply verifies final state; do not automatically approve a refreshed version after a stale-preview error.

Receipt never creates a contract. Confirmed creation starts in Intake with a permanent ACE ID, no government number, and zero financial totals. Linking changes no existing totals, lifecycle, or next action. PR funding is anticipated. Initial extraction supports the supplied DAI UPR format, not generic MIPRs or scans. Until a public CLI release includes these commands, use this repository's npm run ace-dev -- prs ... against an updated development environment.

Review an FRF relationship

A request may precede award and have no government contract number. The ACE ID persists from Intake through execution. Review the source and search existing ACE records before recommending a new effort.

ace --profile development frfs show <frf-id> --json
ace --profile development frfs preview <frf-id> --action create_intake --program "Example pilot" --note "Confirmed this is a new pre-award effort" --json
ace --profile development frfs apply <frf-id> --action create_intake --program "Example pilot" --note "Confirmed this is a new pre-award effort" --expected-preview-hash <hash> --yes --json

Use attach_existing --contract <ace-id|uuid|number> to confirm an existing record, or leave_unresolved to save the note and keep the decision pending. Use exactly the same choice and note at confirmation as in the reviewed preview. An administrator must confirm; --yes requires prior explicit human approval. Production additionally requires the existing production confirmation guard. The apply command re-fetches the FRF to verify the final state.

Confirmation records the relationship and audit trail. It does not move an existing record's lifecycle or next action, and it does not change Total Value, Obligated, Invoiced, or Paid. A new Intake record starts with zero totals and an unassigned government number. The source document still requires its own review. A changed FRF, source, decision, or target requires a new preview. If a response is lost, retry the identical choice and hash to retrieve its durable receipt; do not create a second Intake record independently.

Stored document context

ace documents context <document-id> --json returns the stored summary, cited facts/passages, coverage warnings, and recent extraction history. Use --version-id <uuid> only when intentionally inspecting historical evidence; check isCurrent before using context for a recommendation.

Search bounded context summaries with ace documents search-context --contract <ace-id> --search <keywords> --json, or exact references with --reference-kind purchase_request --reference <pr-number>. Coverage counts describe the requested workspace/contract scope. Missing matches do not establish a new initiative when coverage is incomplete. These read-only commands do not run OCR, create context, approve a link, or change contract totals. Generic summaries are labeled source excerpts; embeddings and Ask ACE are separate follow-on features.

Review document context

ace documents context <document-id> --json includes original machine context, reviewed values, current revision, and recent correction history. Workspace administrators can correct a summary or fact after reviewing its source:

ace documents preview-context-correction DOCUMENT_UUID --input correction.json --json
ace documents correct-context DOCUMENT_UUID --input correction.json --expected-preview-hash HASH --request-id UUID --yes --json

The JSON input contains versionId, expectedRevision, fieldKey (summary or an existing fact key), value, and reason. A null value explicitly restores or acknowledges the machine assertion. Save only with authorization for the exact preview; production also requires its confirmation. Reuse the request UUID and unchanged input after an uncertain response. The CLI verifies the saved receipt. Corrections never rewrite machine extractions or change contract finances/state. Source changes require reviewing corrections again. See architecture and migration.

Context processing can report Needs source review after a known inspection limit or exhausted retries. The source remains preserved, but no complete context is implied. Read the returned message and original document; the read/search commands do not retry processing. Genuine source replacement can queue new work. See document processing operations.

New vendor agreements funded by prime modifications

ace generations prepare <contract> --vendor <vendor> --action P00012 --instrument base_award --agreement-identifier CU-new --funding-allocations <cell-id>,<cell-id> --output manifest.json

--agreement-identifier is optional for a new base: omit it for a unique server-generated ACE reference, or supply your own readable label (up to 100 characters, unique within the contract). The reference is preserved in the prepared manifest and subsequent agreement history; it does not set the printed Services Agreement number.

The cell IDs come from the contract's allocation-line actions. Preparation freezes both funding lines, their sources and the independent agreement type without creating a run. Review the manifest, then use the existing generations readiness --manifest, request, render-preview and render flow. The new base uses the active base template and excludes unrelated vendor history. For an existing identified agreement, list generations agreements <contract> --vendor <vendor> and prepare with --instrument modification --agreement-id <id> --vendor-modification <number>. Prime and vendor modification numbers are separate.

Regenerate an existing Services Agreement

Use ace generations prepare <contract> --from-run <current-run-id> --output revision.json to prepare the next version. Base agreements refresh fields and attachments from currently linked evidence, preserving agreement identity, selected funding lines, template, printed agreement number, and effective date. Missing or unprocessed information remains marked for review. Other manual manifest edits must be reviewed and reapplied to the rebuilt inputs. Modification revisions retain their frozen inputs. Review with generations readiness, then use generations generate --manifest revision.json with the returned --expected-manifest-hash, matching --supersedes-run-id, and an approval note. Inputs do not need to change: intentional regeneration creates a new immutable version, while retrying the same revision returns the saved version. The prior document is preserved. Do not mix --from-run with new-agreement selection flags.

Generation run/status JSON includes frozen funding lines and their source document IDs, hashes, locators, and attributed amounts. Funding provenance is retained in ACE; new Word drafts do not append a funding-source schedule.

Generated document summaries

ace documents context <document-id> --json includes generatedSummary status, model provenance, coverage and claim evidence when available. Use review.effectiveSummary for the reviewed/generated/fallback value. The original context remains immutable machine extraction. These read-only commands never invoke a model; exact PR matching still uses structured references, not generated prose.

Upload an edited or vendor-returned Services Agreement

Use ace services-agreements preview <contract> --file <path> --vendor <vendor> --action <funding-action> --allocation-line <line> --supersedes-document-id <current-document-id> --stage Draft --json, then repeat those selectors with services-agreements add and --expected-preview-hash <reviewed-hash> --yes. Use the normal profile and production confirmation controls. --document <id> can replace --file for an unregistered file already in ACE. The explicit predecessor selects the existing independent agreement and preserves its label, funding cells, and version history. It is required for replacing an agreement created with selected funding lines. Use VendorRedline for In review; only select FullyExecuted when signature status is confirmed. The web equivalent is Upload version on the current row. Regenerate rebuilds from source evidence and does not import Word edits.

Generated agreement review

ace generations review <contract> <run-id> --json returns typed frozen field values, sources, binding labels, and a simplified anchored preview for a saved server-generated base agreement. It is read-only and does not regenerate or re-extract documents. Missing legacy excerpts stay explicitly unavailable. Provenance belongs to generatedDocumentId, not subsequent uploaded edits. See frontend integration.

Regeneration after an uploaded successor: prepare with --from-run naming the nearest prior generated run in the same agreement history. The prepared manifest freezes the current uploaded document separately from the configuration run. generations generate infers its predecessor from that manifest; no predecessor flag is needed. Explicit overrides must agree with the reviewed manifest. This creates the next version from source evidence and does not import manual Word edits. A newer upload after preparation requires refreshing/reviewing inputs.

The original /source-review contract remains available through ace generations source-review <contract> <run-id> --json. The styled web review and ace generations review use /review, including frozen financial reconciliation, conflicts and review gates.

Document generation register and queue

ace docgen reads and appends the workspace-level generation register and the generation queue. It is distinct from ace generations, which works on one contract's Services Agreement runs.

ace docgen register list --take 50 --json
ace docgen register list --status NeedsReview --json
ace docgen runs list --take 50 --json

Both responses are paged; advance --skip by --take. Each run carries a handle such as GEN-004 alongside its number, and a statusLabel for display beside the stable status code.

Both ace docgen register list and ace docgen runs list report statusCounts — one entry per status, counted across the whole workspace rather than the current page, with empty buckets present as zero. The table view prints the non-empty ones as a Workspace totals: line under the page.

Narrow the queue with --status:

ace docgen runs list --status NeedsReview --json

It matches a status name case-insensitively and rejects anything else, including the statusLabel display form — filter on NeedsReview, not "Needs review". The totals ignore the filter on purpose, so a narrowed response still shows where the rest of the work sits.

The reporting screen now shows only the registry. Its create/edit dropdown uses NeedsInputs, Queued (default), Generating, NeedsReview, Failed, and Completed. Registry filtering accepts an exact stored status, including historical text such as --status "ACE Draft sent to Scott". Existing custom statuses remain intact and get their own count/filter; do not guess how to map FE, PE, or other historical values to a generation stage. The API/CLI retain custom status text for compatibility. Queue API/CLI commands remain available for existing callers and data; this change does not move queue rows into the registry or start document generation.

Appending identifies the contract and vendor either by id or by free text, never both. A linked id records that row's current contract number or vendor name, which is why the command prints the resolved row before writing:

ace docgen register add --contract <uuid> --vendor <uuid> \
  --document "SubK Base Agreement" --status "ACE Draft sent to Scott" \
  [--action-needed "<next step>"] [--improvement-notes "<what ACE could do better>"] \
  --current-owner "<name>" --original-owner "<name>" \
  --approval-note "<authorization basis>" --json

ace docgen runs add --contract-number "<number ACE has no record of>" \
  --description "SubK Base Agreement" --sources "PR 4410, FRF-221" \
  --owner "<name>" --approval-note "<authorization basis>" --json

Use --vendor-name "Multiple" when one register line covers several vendors, --action-needed when the row is waiting on someone, and --improvement-notes to record what ACE could have done better on the document. Both notes are optional and print as — when absent. A run's --status defaults to Queued; the accepted values are NeedsInputs, Queued, Generating, NeedsReview, Failed, and Completed. Both commands require --approval-note, prompt for a typed confirmation phrase unless --yes is passed, add the production warning under the production profile, and verify the appended row by reading it back.

Registry rows can also be inspected, edited, or removed by their entry UUID:

ace docgen register get <entry-uuid> --json
ace docgen register edit <entry-uuid> --status "FE" \
  --action-needed "" --improvement-notes "Corrected after review" \
  --approval-note "Owner approved this correction" --json
ace docgen register remove <entry-uuid> --json

Editing preserves omitted fields and existing contract/vendor links. Use the same contract/vendor selectors as register add to replace a reference. An empty string clears --action-needed or --improvement-notes; the other fields remain required. Creation time is preserved and last-updated time advances automatically; historical dates cannot be supplied through these commands.

Edits require a nonblank approval note; removals need no reason. Both show the current row and proposed change and prompt for typed confirmation (or an explicitly authorized --yes). Production additionally requires --confirm-production. A stale revision returns a conflict: read the latest row, review the change again, and only then retry. Edits verify the resulting fields; removal succeeds only after a read of that exact entry returns 404. Both changes commit atomically with an audit snapshot, including the removed row's contents and the editing reason. Removing a registry row does not delete generated documents or generation runs.