Scenario 02: Run a bounded security audit

Use this scenario to inspect a defined workspace or change set for structural and security-relevant findings. The output is an evidence package for triage; AppSec, QA, and release owners record their decisions separately.

Choose the right entry point

OpenCode audit of the current workspace

Run the installed command:

/audit

The workflow first checks project and CPG readiness. For a ready workspace it can preview the current diff, run structural checks, and request revision-bound review packages. If readiness is stale, locked, sync-pending, or graph-only, it returns a bounded deferral or degraded-mode report instead of pretending coverage is complete.

Deterministic CLI report

Use an explicit, registered CPG database:

python -m src.cli audit --db PATH --format json --skip-llm-conclusion --skip-persistence

--db is mandatory for the audit command. The database must map to a configured project with an existing source directory. --skip-llm-conclusion removes the generated conclusion, and --skip-persistence prevents finding projection and audit/dashboard snapshot persistence.

The CLI still checks graph freshness. A stale graph can trigger a CPG refresh, which updates the configured CPG database before analysis. Therefore --skip-persistence persists no audit results while the freshness check may update the configured graph database.

Useful optional controls are --source-path, --profile, --scopes, --language, --timeout, and --output. Check python -m src.cli audit --help in the installed release before scripting them.

What the OpenCode flow uses

The maintained /audit command is bounded by these surfaces:

1. codegraph_project_context_status establishes context and CPG readiness.
2. codegraph_context_retrieval_diff_preview establishes a revision-bound change scope when a diff is available.
3. codegraph_quality_structural_test_run executes structured checks against accepted native inputs.
4. codegraph_digital_employee_code_quality_review_report provides a code-quality review package when that lane is in scope.
5. codegraph_digital_employee_architecture_impact_review_report provides an architecture-impact package when that lane is in scope.

Only the smallest relevant source slices should be read to explain each finding.

Review the evidence and finding count

For every finding, retain:

• the accepted scope and revision;
• severity and rule or check identifier;
• source location and evidence reference;
• known coverage gaps;
• a reproducible next check;
• disposition: confirmed, rejected, needs review, or deferred.

An empty finding list records the result for the configured scope. Confirm that the intended languages, paths, generated code, dependencies, and runtime boundaries were in scope before recording the security decision.

Authority boundary

Automated analysis can identify and prioritize risks. Only the accountable AppSec lane can issue an AppSec verdict. Architecture, QA, release, and financial closure remain separate evidence lanes. Never turn a command exit code or a Markdown/JSON report into a missing lane decision.

For generated patch suggestions, continue with Security Audit Autofix. Those suggestions are previews and require review and tests.

Common failures

• audit commands require explicit --db: pass the configured database path.
• Project/source context cannot be resolved: register or repair the project binding before retrying.
• Graph remains stale after refresh: report the freshness reason and rerun after the graph is current.
• Readiness is locked or sync-pending: keep the bounded deferral and the server-provided next action.

Maintained source contracts

• OpenCode workflow: .opencode/commands/audit.md
• CLI registration and behavior: src/cli/analysis_commands/audit_commands.py
• AppSec role policy: src/digital_employees/runtime/scenarios/employee_scenario_invocation.py