---
name: author-sonar-workflows
description: Use as Astrix when no catalog workflow fits and a complete bounded workflow document must be authored and structurally validated before durable recon execution.
category: pull
---

# Author a bounded workflow document

This is authoring guidance, not scan control. Produce one complete document and use structural
validation to iterate. Do not mutate, import, launch, stop, or delete anything from this profile.

## Document contract

Include every schema field required by the current validator: identity and description, steps,
dependencies, input source, output contract, declared parameters and controlled secret references,
policy metadata, routing, limits, and version fields. The document must have an explicit required
target parameter and a typed target-manifest channel. Match-all or an implicit current-inventory
query is not an acceptable substitute for a bounded manifest.

Canonicalize the executable document with the declared canonicalization schema. The canonical
content hash includes every execution-affecting field and excludes audit associations such as the
request, author, CVE, and import time. Treat the resulting content hash and immutable version
reference as lineage; edits create a new version and never rewrite an existing one.

## Safety and policy fields

Declare per-step timeouts, an overall deadline, step and scan concurrency, target caps, approved
worker image/tag routing, result schema/version, and the expected per-target provenance fields.
Input SQL must use a genuinely read-only database identity and transaction against approved
schemas or views. SQL text-prefix checks are not a permission boundary. Reference controlled
secrets by name only: never embed credentials in documents, parameters, logs, or result bodies.

Structural validation checks schema, graph, expressions, SQL shape, routing, timeouts, caps, and
the output contract. Execution validation additionally checks accepted request context, immutable
target manifest, policy bounds, and current policy/version. A structural receipt is not execution
authorization; a validation receipt is not a launch receipt.

## Failure and rollout runbook

- **Ambiguous scope or no targets:** ask for a narrower explicit scope or reject; never invent or
  expand a target set.
- **Policy rejection:** read every stable field/step error, revise the document or narrow the
  request, then validate again. Do not override policy in prose.
- **Partial, inconclusive, or denied capability:** preserve the error and provenance, distinguish
  execution failure from a vulnerability conclusion, and return the request to clarification or
  the control-plane operator.
- **Narrow trial:** validate a small document and expected manifest first. Any execution is a
  separate authorized control-plane decision; this authoring profile does not execute it.
