@workflow-cannon/workspace-kit 0.7.0 → 0.9.0

package/src/modules/documentation/schemas/documentation-schema.md

@@ -0,0 +1,54 @@
+meta|v=1|doc=<manifest|rules|runbook|workbook|map|workflows|commands|decisions|glossary|observed|planned|checks>|truth=<canonical|observed|planned>|st=<active|deprecated|draft>
+
+syntax|rec=one_per_line|sep=||kv==|list=,|seq=>|all=+|bool=true,false
+ids|rule=R[0-9]{3,}|wf=W[0-9]{3,}|cmd=C[0-9]{3,}|decision=D[0-9]{3,}|observed=O[0-9]{3,}|planned=P[0-9]{3,}|check=K[0-9]{3,}
+sem|lvl=must,must_not,should,may|risk=low,medium,high,critical|ap=none,prompt,required|act=auto,warn,prompt,stop
+author|meta_first_once=true|one_fact_per_record=true|exceptions_inline=true|no_vague_directives=true|observed_ne_rule=true|planned_ne_rule=true|stable_order=true
+
+project|name=<name>|type=<type>|scope=<scope>
+stack|<key=value>...
+prio|<p1>><p2>><p3>...
+truth|order=<t1>><t2>><t3>><t4>
+ref|name=<name>|path=<path>
+
+rule|<RID>|<lvl>|<scope>|<directive>|unless=<cond>|also=<list>|risk=<risk>|ap=<ap>|ov=<act>|st=<st>|refs=<list>
+path|<path>|role=<role>|has=<list>|xhas=<list>|deps=<list>|xdeps=<list>|check=<list>|st=<st>|refs=<list>
+module|<name>|role=<role>|owns=<list>|deps=<list>|xdeps=<list>|entry=<list>|tests=<list>|st=<st>|refs=<list>
+
+runbook|<name>|<scope>|<owner>
+workbook|<name>|<phase>|<status>
+intent|<fact_or_guidance>
+chain|<step>|<command>|expect_exit=<code>
+artifact|path=<path>|schema=<schema_path>
+state|name=<name>|dist_tag=<tag>|intent=<intent>
+transition|from=<from>|to=<to>|requires=<list>
+promotion|from=<from>|to=<to>|requires=<list>
+rollback|strategy=<strategy>|note=<note>
+command|name=<name>|purpose=<purpose>|sensitivity=<non_sensitive|policy_sensitive>
+config|key=<key>|default=<value>
+cadence|rule=<rule>
+guardrail|<GID>|<lvl>|<directive>|st=<st>
+
+wf|<WID>|name=<name>|when=<trigger>|do=<s1>><s2>><s3>|done=<d1>+<d2>|forbid=<list>|ask_if=<cond>|halt_if=<cond>|ap=<ap>|risk=<risk>|st=<st>|refs=<list>
+cmd|<CID>|name=<name>|use=<command>|scope=<scope>|expect=<result>|risk=<risk>|st=<st>
+decision|<DID>|topic=<topic>|choice=<choice>|why=<reason>|then=<consequence>|st=<st>|refs=<list>
+term|<name>|def=<definition>|st=<st>
+
+observed|<OID>|scope=<scope>|fact=<fact>|evidence=<evidence>|risk=<risk>|st=observed|refs=<list>
+planned|<PID>|scope=<scope>|target=<target>|why=<reason>|st=planned|refs=<list>
+check|<KID>|scope=<scope>|assert=<assertion>|when=<cond>|on_fail=<act>|st=<st>|refs=<list>
+
+order|manifest=meta,project,stack,prio,truth,ref
+order|rules=global,risky,scoped,workflow,style
+order|map=roots,major,special,legacy
+order|workflows=common,risky,edge,clarify
+
+defaults|omit_optional=true|omit_empty=true|lvl_explicit=true|scope_explicit=true|directive_explicit=true
+stop|critical_secret_risk=true|destructive_unapproved=true|policy_conflict_unresolved=true
+prompt|multi_valid_interpretations=true|required_approval_missing=true
+warn|should_violation=true|low_risk_uncertainty=true
+
+directive|good=add_migration,preserve_backward_compatibility,contain_business_logic,commit_secrets,manual_edit
+directive|bad=best_practices,clean_code,good_design,keep_it_simple,do_the_right_thing
+scope|good=repo,src/api,src/domain,public_api,schema_changes,behavior_change
+scope|bad=general,misc,various,important_stuff

package/src/modules/documentation/state.md

@@ -0,0 +1,8 @@
+# Documentation Module State
+
+Tracks current module runtime state and generation metadata.
+
+- `lastRunAt`: last successful generation timestamp
+- `lastRunInputs`: summary of source inputs and command arguments
+- `lastRunOutputs`: generated file list and checks
+- `lastRunStatus`: `ok` or `failed`

package/src/modules/documentation/templates/AGENTS.md

@@ -0,0 +1,84 @@
+{{{AI Documentation Directive}}}
+
+# AGENTS
+
+Basic operating guidance for AI agents working in this repository.
+
+## Source-of-truth order
+
+{{{
+Generate a ranked source-of-truth list by discovering governance and execution documents in this repository.
+Method:
+1) Read the canonical principles/rules file under `/.ai` first to establish decision priority and approval gates.
+2) Read module-development governance under `/.ai` next to capture implementation constraints.
+3) Read maintainership planning docs under `docs/maintainers/` to determine strategy (`ROADMAP`), execution queue (`TASKS`), and release process (`RELEASING`).
+4) Read terminology/glossary docs to normalize language used in the section.
+5) Include any direct human companion doc for module governance as the last authority tier.
+Output format:
+- Numbered list in descending precedence.
+- Each line includes a path and a short "what this controls" phrase.
+Validation:
+- Confirm each referenced file exists before emitting.
+- Ensure higher-ranked docs can override lower-ranked docs.
+}}}
+
+## Core expectations
+
+{{{
+Generate behavioral expectations for agents by extracting normative statements (`must`, `must_not`, `should`) from the top-ranked governance docs.
+Method:
+1) Pull autonomy posture and conflict-handling behavior from principles/rules docs.
+2) Pull approval-gated action categories from release/policy guidance.
+3) Pull implementation posture from module build guidance (reversible, evidence-backed, deterministic).
+Output format:
+- 4-6 concise bullets in imperative style.
+- One nested bullet group may be used for approval-gated action categories.
+Validation:
+- Do not invent expectations not present in source docs.
+- Prioritize clarity over verbosity.
+}}}
+
+## Working rules
+
+{{{
+Generate repository working rules by mapping responsibilities to the correct document surfaces.
+Method:
+1) Identify which file governs strategy, which governs execution queue, and which governs release operations.
+2) Add a synchronization rule requiring related docs to be updated in the same change set when scope changes.
+3) Add a compatibility/determinism rule derived from principles and release guidance.
+Output format:
+- 3-5 bullets, each phrased as an enforceable rule.
+Validation:
+- Rules must reference real file paths.
+- Avoid duplicating deep procedure content; keep this section as operating constraints.
+}}}
+
+## Task execution
+
+{{{
+Generate task-execution directives from the active task-tracking format.
+Method:
+1) Inspect task metadata fields used for ordering and completion criteria.
+2) Derive execution order behavior from dependency fields.
+3) Derive implementation constraints from task detail fields (approach/scope/acceptance).
+4) Include a task-splitting rule for oversized work items.
+Output format:
+- 3-4 short action bullets.
+Validation:
+- Instructions must align with the current task schema and status markers.
+- Do not include project-specific task IDs in this section.
+}}}
+
+## Documentation generation
+
+{{{
+Describe how agents should use the documentation module when generating or syncing maintainer docs.
+Method:
+1) Read `src/modules/documentation/RULES.md` for precedence and validation behavior.
+2) Read `src/modules/documentation/instructions/document-project.md` (Inputs) and `src/modules/documentation/README.md` for callable commands and shipped `documentType` / template filenames.
+3) State that `document-project` and `generate-document` are the command entrypoints when wired in the module router.
+Output format:
+- 2-3 short bullets or one tight paragraph.
+Validation:
+- Paths must exist in the repository; do not invent extra commands.
+}}}

package/src/modules/documentation/templates/ARCHITECTURE.md

@@ -0,0 +1,71 @@
+{{{AI Documentation Directive}}}
+
+# Architecture Overview
+
+This document provides a high-level architecture map for Workflow Cannon.
+
+## System intent
+
+{{{
+Describe the system intent in 2-4 sentences by reading `README.md`, `docs/maintainers/ROADMAP.md`, and `.ai/PRINCIPLES.md`.
+Method:
+1) Extract what the product is for and what it is not for from README and roadmap scope sections.
+2) Align with modular workflow, safety, and traceability themes from principles.
+Output format:
+- One short paragraph; no bullet list unless the source docs use bullets for intent.
+Validation:
+- Do not invent features not implied by the repository sources.
+- If scope is ambiguous, state assumptions explicitly in one clause.
+}}}
+
+## Core architectural directions
+
+{{{
+Produce 5-7 bullet points describing stable architectural directions (not implementation detail).
+Method:
+1) Derive from roadmap phase descriptions, ARCHITECTURE-related task references, and module/registry language in code comments or `docs/maintainers/ARCHITECTURE.md` if present.
+2) Include modularity, task/planning, policy, improvement loop, and observability only when supported by sources.
+Output format:
+- Markdown bullet list; each bullet starts with a noun phrase or short clause.
+Validation:
+- Avoid version numbers and task IDs in this section.
+}}}
+
+## Key building blocks
+
+{{{
+List the major logical components and how they relate at a high level.
+Method:
+1) Inspect `docs/maintainers/ARCHITECTURE.md`, module layout under `src/`, and roadmap phase outcomes.
+2) Name blocks as they appear in maintainer docs (e.g. Task Engine, registry, documentation module) when those names exist.
+Output format:
+- Bullet list of building blocks; optional one-line parenthetical per item for responsibility.
+Validation:
+- Do not name internal file paths unless they are already cited as public extension points in maintainer docs.
+}}}
+
+## Foundational design principles
+
+{{{
+Summarize design principles that bridge architecture and implementation norms.
+Method:
+1) Pull safety, determinism, explainability, migration, and doc/runtime boundary rules from `.ai/PRINCIPLES.md` and human principles companion.
+2) Prefer imperative, testable statements over slogans.
+Output format:
+- 4-6 bullets; parallel structure.
+Validation:
+- Must not contradict the decision priority order in principles docs.
+}}}
+
+## Related docs
+
+{{{
+Emit cross-links to planning and execution surfaces.
+Method:
+1) Confirm paths exist: `docs/maintainers/ROADMAP.md`, `.workspace-kit/tasks/state.json`, and `docs/maintainers/RELEASING.md` when release behavior is architecture-relevant.
+2) Add `.ai/PRINCIPLES.md` or module-build references only if cited elsewhere in this doc set.
+Output format:
+- Bulleted list of paths with a short “what this covers” fragment after each.
+Validation:
+- Every path listed must exist in the workspace.
+}}}

package/src/modules/documentation/templates/PRINCIPLES.md

@@ -0,0 +1,122 @@
+{{{AI Documentation Directive}}}
+
+# Workflow Cannon Principles (Human-Readable)
+
+This document is the human-readable companion to `.ai/PRINCIPLES.md` (canonical rules format).  
+If there is any conflict, `.ai/PRINCIPLES.md` is authoritative.
+
+## Purpose
+
+{{{
+State the purpose of this human-readable principles doc in 2-3 sentences.
+Method:
+1) Read `.ai/PRINCIPLES.md` and `README.md` for stated goals.
+2) Clarify that this file is for humans and agents; canonical machine-oriented rules live under `/.ai`.
+Output format:
+- Short paragraph.
+Validation:
+- Do not duplicate long lists from the canonical file; summarize only.
+}}}
+
+## Decision Priority Order
+
+{{{
+Reproduce the trade-off priority list exactly as defined in `.ai/PRINCIPLES.md`.
+Method:
+1) Open `.ai/PRINCIPLES.md` and copy the ordered list verbatim.
+2) If the canonical file uses different wording, the canonical file wins—update this section to match.
+Output format:
+- Numbered list 1..n in the canonical order.
+Validation:
+- Order must match `.ai/PRINCIPLES.md` byte-for-byte on list items.
+}}}
+
+## Source of Truth Order
+
+{{{
+Describe precedence when sources disagree, aligned with `.ai/PRINCIPLES.md` and `docs/maintainers/TERMS.md` if present.
+Method:
+1) Prefer explicit precedence from `.ai/PRINCIPLES.md`.
+2) Use TERMS glossary for “canonical glossary” vs narrative docs if needed.
+Output format:
+- Numbered list from highest to lowest precedence.
+Validation:
+- Must not contradict `.ai/PRINCIPLES.md`.
+}}}
+
+## Core Principles
+
+{{{
+Expand core principles as concise bullets drawn from `.ai/PRINCIPLES.md` and this file’s prior content if present.
+Method:
+1) Extract normative statements (must/should) and decision rules.
+2) Merge duplicates; keep 8-12 bullets maximum.
+Output format:
+- Markdown bullet list.
+Validation:
+- Each bullet should be testable or clearly actionable.
+}}}
+
+## Required Human Approval
+
+{{{
+List categories of work that require explicit human approval before execution.
+Method:
+1) Take approval categories from `.ai/PRINCIPLES.md` and `docs/maintainers/RELEASING.md`.
+2) Add stop conditions for irreversible harm or secret exposure if stated in principles.
+Output format:
+- Intro sentence followed by bullet list of approval-gated categories.
+Validation:
+- Do not remove an approval category that appears in the canonical principles file.
+}}}
+
+## Conflict and Override Handling
+
+{{{
+Describe soft-gate behavior and where to record overrides.
+Method:
+1) Use principles and `docs/maintainers/DECISIONS.md` purpose.
+2) Reference `.workspace-kit/tasks/state.json` for execution tracking of overrides.
+Output format:
+- 2-4 bullets.
+Validation:
+- Include at least one path for recording rationale (`TASKS` or `DECISIONS`).
+}}}
+
+## Documentation Boundaries
+
+{{{
+State which topics belong in ROADMAP vs TASKS vs RELEASING.
+Method:
+1) Read `docs/maintainers/TERMS.md` for “directive”, “workflow”, and documentation boundary language if helpful.
+2) Align with existing README/workflow contract rules in the repo.
+Output format:
+- One short paragraph plus 3 bullets mapping strategy / execution / release to files.
+Validation:
+- Paths must be `docs/maintainers/ROADMAP.md`, `.workspace-kit/tasks/state.json`, `docs/maintainers/RELEASING.md`.
+}}}
+
+## Validation Gates
+
+{{{
+Summarize gates before merge/release: release readiness, compatibility, policy-sensitive work.
+Method:
+1) Pull gate names from `.ai/PRINCIPLES.md`, `docs/maintainers/RELEASING.md`, and this document’s prior version if present.
+Output format:
+- Short intro then bullet list with bold gate labels.
+Validation:
+- Each gate must reference what evidence or approval satisfies it.
+}}}
+
+## Related References
+
+{{{
+List related docs with paths.
+Method:
+1) Verify existence of each file in the workspace.
+2) Include `.ai/PRINCIPLES.md`, `docs/maintainers/ROADMAP.md`, `.workspace-kit/tasks/state.json`, `docs/maintainers/DECISIONS.md`, `docs/maintainers/RELEASING.md`, `docs/maintainers/CHANGELOG.md` when present.
+Output format:
+- Bulleted list of paths.
+Validation:
+- No broken paths.
+}}}

package/src/modules/documentation/templates/RELEASING.md

@@ -0,0 +1,96 @@
+{{{AI Documentation Directive}}}
+
+# Releasing
+
+Canonical release process for `@workflow-cannon/workspace-kit`.
+
+This document defines how releases are planned, validated, published, and reviewed in Phase 0.
+
+## Release intent
+
+{{{
+List what every release must achieve (predictability, compatibility, evidence, feedback loop).
+Method:
+1) Read `docs/maintainers/RELEASING.md` if present, `package.json` name field, and `README.md` for release posture.
+2) Align bullets with principles: evidence, safety, human review for risky changes.
+Output format:
+- 4-6 bullets starting with verbs or noun phrases; parallel structure.
+Validation:
+- Mention packaged-artifact validation if the roadmap or tasks require it for the current phase.
+}}}
+
+## Release principles
+
+{{{
+State named principles (e.g. package-first truth, evidence over assumption).
+Method:
+1) Extract from current `docs/maintainers/RELEASING.md` and team norms in `.ai/PRINCIPLES.md`.
+2) Use bold labels for principle names when the source uses them.
+Output format:
+- Bullet list with optional **bold** lead-in per item.
+Validation:
+- Do not promise automation steps that are not implemented; describe intent-level principles only.
+}}}
+
+## Release readiness gates
+
+{{{
+Enumerate gates that must pass before publish.
+Method:
+1) Merge checklist items from `docs/maintainers/RELEASING.md`, `.workspace-kit/tasks/state.json` release-related tasks, and CI/workflow names under `.github/workflows/` if discoverable.
+2) Include changelog, tests, consumer parity, migration review, and security review when applicable to the phase.
+Output format:
+- Numbered list; each item is one gate; sub-bullets only for clarifying checks.
+Validation:
+- If a gate depends on a doc path, name the path explicitly.
+}}}
+
+## Release procedure
+
+{{{
+Document a numbered procedure from scope definition through consumer verification.
+Method:
+1) Follow structure of existing `docs/maintainers/RELEASING.md` (define scope → prepare artifacts → validate → publish → verify).
+2) Insert concrete commands only if they appear in `package.json` scripts or maintainer docs.
+Output format:
+- Numbered phases; use nested bullets for steps; use `##`-level subheadings only if the human doc already uses them.
+Validation:
+- Include explicit “do not publish if gate fails” behavior.
+}}}
+
+## Required release evidence
+
+{{{
+List artifacts and references that must be captured for auditability.
+Method:
+1) Use RELEASING docs and task evidence language from `.workspace-kit/tasks/state.json`.
+2) Include version, tag, workflow run links, npm reference, migration notes, risks.
+Output format:
+- Bullet list; group related items if needed.
+Validation:
+- State that evidence must be sufficient for another maintainer to reconstruct confidence.
+}}}
+
+## Post-release workflow
+
+{{{
+Describe follow-up after publish: monitoring, triage, friction capture, task/roadmap updates.
+Method:
+1) Align with `docs/maintainers/ROADMAP.md` improvement/roadmap language.
+Output format:
+- Numbered list for main sequence; bullets for feedback loops.
+Validation:
+- Link follow-up work to `TASKS` and `ROADMAP` paths.
+}}}
+
+## Related documents
+
+{{{
+Cross-link README, principles, roadmap, tasks, security.
+Method:
+1) Verify each path exists.
+Output format:
+- Bullet list with path and one-line description.
+Validation:
+- Include `docs/maintainers/SECURITY.md` for vulnerability handling expectations.
+}}}

package/src/modules/documentation/templates/ROADMAP.md

@@ -0,0 +1,131 @@
+{{{AI Documentation Directive}}}
+
+# Workflow Cannon Roadmap
+
+Long-range plan and decision log for the Workflow Cannon package and maintainer workflow.
+
+## Scope
+
+{{{
+State repository scope and relationship to external consumers or legacy repos.
+Method:
+1) Read `docs/maintainers/ROADMAP.md`, `README.md`, and any extraction/split notes in maintainer docs.
+2) Clarify canonical home vs external consumer/parity fixture language if present.
+Output format:
+- 2-4 bullets or one short paragraph plus bullets.
+Validation:
+- Do not invent consumer names; use only what appears in docs.
+}}}
+
+## Current state
+
+{{{
+Summarize current execution phase, completed task slices, and active queue.
+Method:
+1) Read `.workspace-kit/tasks/state.json` for execution state, current phase, ready queue, and completed markers.
+2) Read `docs/maintainers/ROADMAP.md` for milestone wording.
+Output format:
+- Short bullets: phase name, completed work summary, active queue references (task IDs allowed here).
+Validation:
+- Task IDs must match `.workspace-kit/tasks/state.json` at generation time.
+}}}
+
+## Phase plan and release cadence
+
+{{{
+Introduce the rule that each phase ends with a GitHub release and phases are sequential unless replanned.
+Method:
+1) Copy cadence rules from `docs/maintainers/ROADMAP.md` if present.
+Output format:
+- One short paragraph.
+Validation:
+- Do not add phases not listed in maintainer roadmap unless the user explicitly expands scope.
+}}}
+
+### Phase 0 - Foundation hardening -> GitHub release `v0.2.0`
+
+{{{
+Document Phase 0 scope, outcome, and exit signals.
+Method:
+1) Read `.workspace-kit/tasks/state.json` and `docs/maintainers/ROADMAP.md` for Phase 0 task ranges and release target.
+Output format:
+- Bullets for primary scope, outcome, exit signals.
+Validation:
+- Release version string must match `ROADMAP.md` for Phase 0.
+}}}
+
+### Phase 1 - Task Engine core -> GitHub release `v0.3.0`
+
+{{{
+Document Phase 1 scope, outcome, and exit signals from maintainer roadmap.
+Output format:
+- Bullets for primary scope, outcome, exit signals.
+Validation:
+- Align task IDs with `.workspace-kit/tasks/state.json`.
+}}}
+
+### Phase 2 - Configuration and policy base -> GitHub release `v0.4.0`
+
+{{{
+Document Phase 2 scope, outcome, and exit signals.
+Output format:
+- Bullets for primary scope, outcome, exit signals.
+Validation:
+- Align task IDs with `.workspace-kit/tasks/state.json`.
+}}}
+
+### Phase 2b - Config policy hardening + UX / exposure -> GitHub release `v0.4.1`
+
+{{{
+Document Phase 2b scope, outcome, and exit signals (policy hardening `T219`–`T220` and config UX `T228`–`T237`; see `.workspace-kit/tasks/state.json` for the draft-ID mapping note).
+Output format:
+- Bullets for primary scope, outcome, exit signals.
+Validation:
+- Align task IDs with `.workspace-kit/tasks/state.json`.
+}}}
+
+### Phase 3 - Enhancement loop MVP -> GitHub release `v0.5.0`
+
+{{{
+Document Phase 3 scope, outcome, and exit signals.
+Output format:
+- Bullets for primary scope, outcome, exit signals.
+Validation:
+- Align task IDs with `.workspace-kit/tasks/state.json`.
+}}}
+
+### Phase 4 - Runtime scale and ecosystem -> GitHub release `v0.6.0`
+
+{{{
+Document Phase 4 scope, outcome, and exit signals.
+Output format:
+- Bullets for primary scope, outcome, exit signals.
+Validation:
+- Align task IDs with `.workspace-kit/tasks/state.json`.
+}}}
+
+## Recorded decisions
+
+{{{
+Maintain a decision log table for major irreversible choices.
+Method:
+1) Preserve existing rows from `docs/maintainers/ROADMAP.md` when updating.
+2) Add new rows only when `docs/maintainers/DECISIONS.md` or `.workspace-kit/tasks/state.json` records a new decision worth surfacing here.
+Output format:
+- Markdown table with columns: Decision | Choice
+Validation:
+- Do not remove historical decisions; append or mark superseded if the repo uses that convention.
+}}}
+
+## Execution evidence snapshot
+
+{{{
+Record provenance for extraction split and first publish when applicable.
+Method:
+1) Read freeze SHA, split SHA, workflow run URLs, and npm links from `docs/maintainers/ROADMAP.md` or linked evidence.
+2) If SHAs are not in repo, leave explicit placeholders or omit if instructed by user.
+Output format:
+- Bullets: freeze commit, split commit, workflow run link, npm package link.
+Validation:
+- Prefer exact strings from existing maintainer docs over invention.
+}}}

package/src/modules/documentation/templates/SECURITY.md

@@ -0,0 +1,53 @@
+{{{AI Documentation Directive}}}
+
+# Security Policy
+
+## Reporting a vulnerability
+
+{{{
+Describe how to report security issues privately and why public disclosure is discouraged before coordination.
+Method:
+1) Read `docs/maintainers/SECURITY.md` and `README.md` / `docs/maintainers/SUPPORT.md` for contact paths.
+2) If no private contact is listed, instruct to use GitHub security advisories or maintainer email if documented.
+Output format:
+- 2-4 sentences; imperative and clear.
+Validation:
+- Do not invent email addresses; use only public repo contact mechanisms.
+}}}
+
+## What to include
+
+{{{
+List information reporters should provide for effective triage.
+Method:
+1) Align with `docs/maintainers/SECURITY.md` and common vulnerability reporting practice.
+Output format:
+- Bullet list: description, versions, repro, impact, suggested fix.
+Validation:
+- Keep items parallel (noun-led or short phrases).
+}}}
+
+## Response expectations
+
+{{{
+Set SLA-style expectations for acknowledgement and triage.
+Method:
+1) Preserve numeric targets from existing `docs/maintainers/SECURITY.md` if present.
+2) State business-day semantics if used.
+Output format:
+- Short bullets for acknowledgement, triage, coordinated disclosure.
+Validation:
+- If no SLA exists in source, say “targets” not “guarantees” unless the org wants guarantees.
+}}}
+
+## Scope highlights
+
+{{{
+Enumerate security-sensitive areas relevant to this project (secrets, policy bypass, workspace mutation, privacy).
+Method:
+1) Derive from `docs/maintainers/ARCHITECTURE.md`, `docs/maintainers/RELEASING.md`, and security-related tasks.
+Output format:
+- Bullet list with bold labels optional.
+Validation:
+- Tie each area to project-specific behavior when possible.
+}}}

package/src/modules/documentation/templates/SUPPORT.md

@@ -0,0 +1,40 @@
+{{{AI Documentation Directive}}}
+
+# Support
+
+## Getting help
+
+{{{
+Describe channels for help: issues, features, security escalation path.
+Method:
+1) Read `docs/maintainers/SUPPORT.md` and `README.md` for issue templates or contribution paths.
+2) Cross-reference `docs/maintainers/SECURITY.md` for security-sensitive reports.
+Output format:
+- Bullet list with one line per channel.
+Validation:
+- Use relative paths to maintainer docs in this repo.
+}}}
+
+## What to include
+
+{{{
+List information reporters should attach for reproducible issues.
+Method:
+1) Align with `docs/maintainers/SUPPORT.md` and any issue template under `.github/ISSUE_TEMPLATE/`.
+Output format:
+- Bullet list: version/SHA, environment, commands, expected vs actual, logs.
+Validation:
+- Mention OS/runtime when relevant to the project stack.
+}}}
+
+## Response expectations
+
+{{{
+Set triage expectations and how priority is determined.
+Method:
+1) Preserve numbers from existing `docs/maintainers/SUPPORT.md` when present.
+Output format:
+- 2-3 short bullets.
+Validation:
+- Avoid legal guarantees; use “target” language unless the source doc says otherwise.
+}}}