/coach-render-package

The plugin’s one render / redact / package engine: the primitive every outbound document package passes through on its way out of Canvas. It takes the assembled markdown sections a covering workflow has composed and turns them into a distributable bundle: it renders them to .docx + .pdf via pandoc, runs a mandatory redaction gate, the canvas-redactor agent in block policy, that hard-halts on any needs_user flag, packages the cleared artifacts, and hands the distribution list to /coach-notify. It renders; it does not compose: what the sections say is decided upstream in the covering workflow. And it is package-only by construction: it produces the package and the distribution roster, never a signature and never a sent email: signing and sending happen offline, human-driven.

When to use

When a covering workflow’s compose step has assembled the sections for a high-stakes outbound package, a quarterly board report, a regulator attestation, a Section 302/906 certification package, or a final audit report, and you need to render, redact, and package them for distribution.

• To draft or send the stakeholder emails themselves, or to build just a distribution list, use /coach-notify: this engine delegates its distribution step there.
• For a one-off redaction pass over a directory you staged yourself, use /coach-redact: this engine runs that same gate as a non-negotiable stage of the build.
• When the package needs a supporting-evidence attachment bundle gathered from Canvas, compose with /coach-export-package.

Inputs

Flag	Required	Notes
--in <path>	Yes	The assembled markdown sections to render: the handoff artifact from the covering workflow’s compose step.
--label <string>	Yes	Names the package and its output directory, e.g. 2026-Q3-board-report, 302-906-2026-Q2.
--out-dir <path>	No	Where the package lands. Defaults to .coworkcanvas/packages/<label>/.
--dl <spec>	No	Distribution spec passed straight to /coach-notify (e.g. board, or a custom role list). Its semantics are coach-notify’s, not this engine’s.
--cite	No	Bind every claim to its live Canvas source record and mark gaps. Requires a Canvas connection; the base path is pure local rendering.

Example

/coach-render-package --in board-sections.md --label 2026-Q3-board-report --dl board --cite binds each claim in the sections to its live Canvas source record, renders the cited markdown to .docx + .pdf, runs the redaction gate over the staged output, packages the cleared artifacts under .coworkcanvas/packages/2026-Q3-board-report/, and hands the board distribution list to coach-notify. It ends with the package path (annotated 3 NEEDS INFO markers to resolve if the citation pass found gaps) and the DL path: nothing else. If the redactor returns needs_user, the build halts before packaging until you resolve the flagged items.

Good to know

• The redaction gate is non-negotiable. The block-policy canvas-redactor pass hard-halts on any needs_user flag: any unresolved [REVIEW: ...] or coaching-note flag stops the build, and the engine never proceeds to distribution while a flag is open. These are the highest-stakes artifacts the org produces, so they must be clean before they leave.
• It renders, it does not compose. What sections a package contains, what data feeds them, and the synthesis that writes them all live in the covering workflows on assureswarm.com/workflows: grc-quarterly-board-audit-committee-reporting, reg-compliance-attestation-cycle, sox-subcertification-cascade, and audit-report-drafting. The engine never re-derives section content or period deltas.
• --cite binds claims to live records. Each claim gets an inline [source: workstep:WS-NNN, issue:I-NNN, evidence:DOC-NNN] reference, the id itself, never a prose pointer, so a reader can click through to the live audit, issue, workflow Step, or document. Facts the Canvas context cannot support become [NEEDS INFO: <question>] markers rather than invented values. A cited render is a starting point, not a finished deliverable, while NEEDS INFO markers remain.
• Distribution is drafts-only. The engine produces the package and the deduplicated roster; coach-notify composes drafts and never auto-sends. The signature and the sent email are always yours.
• The base path (no --cite) is pure local rendering and needs no Canvas connection. --cite reads live Canvas data and expects the shared core starter pack: run /coach-starter-pack if its pre-flight fails.

Related

• /coach-notify: the outbound-comms primitive this engine hands its distribution step to.
• /coach-export-package: compose with it when the package needs a supporting-evidence attachment bundle.
• /coach-redact: the standalone version of the redaction gate this engine runs internally.
• get_step_context: how --cite pulls the workflow Steps and their attached evidence documents.