feat(docs): Add comprehensive documentation for Vexer, Vulnerability Explorer, and Zastava modules
- Introduced AGENTS.md, README.md, TASKS.md, and implementation_plan.md for Vexer, detailing mission, responsibilities, key components, and operational notes. - Established similar documentation structure for Vulnerability Explorer and Zastava modules, including their respective workflows, integrations, and observability notes. - Created risk scoring profiles documentation outlining the core workflow, factor model, governance, and deliverables. - Ensured all modules adhere to the Aggregation-Only Contract and maintain determinism and provenance in outputs.
This commit is contained in:
		| @@ -1,20 +1,20 @@ | ||||
| # Docs & Enablement Guild | ||||
|  | ||||
| ## Mission | ||||
| Produce and maintain offline-friendly documentation for StellaOps modules, covering architecture, configuration, operator workflows, and developer onboarding. | ||||
|  | ||||
| ## Scope Highlights | ||||
| - Authority docs (`docs/dev/31_AUTHORITY_PLUGIN_DEVELOPER_GUIDE.md`, upcoming `docs/11_AUTHORITY.md`). | ||||
| - Concelier quickstarts, CLI guides, Offline Kit manuals. | ||||
| - Release notes and migration playbooks. | ||||
|  | ||||
| ## Operating Principles | ||||
| - Keep guides deterministic and in sync with shipped configuration samples. | ||||
| - Prefer tables/checklists for operator steps; flag security-sensitive actions. | ||||
| - When work involves a specific `StellaOps.<Component>` project, consult both `docs/07_HIGH_LEVEL_ARCHITECTURE.md` and the matching dossier `docs/ARCHITECTURE_<COMPONENT>.md` before drafting or editing content. | ||||
| - Update `docs/TASKS.md` whenever work items change status (TODO/DOING/REVIEW/DONE/BLOCKED). | ||||
|  | ||||
| ## Coordination | ||||
| - Authority Core & Plugin teams for auth-related changes. | ||||
| - Security Guild for threat-model outputs and mitigations. | ||||
| - DevEx for tooling diagrams and documentation pipeline. | ||||
| # Docs & Enablement Guild | ||||
|  | ||||
| ## Mission | ||||
| Produce and maintain offline-friendly documentation for StellaOps modules, covering architecture, configuration, operator workflows, and developer onboarding. | ||||
|  | ||||
| ## Scope Highlights | ||||
| - Authority docs (`docs/dev/31_AUTHORITY_PLUGIN_DEVELOPER_GUIDE.md`, upcoming `docs/11_AUTHORITY.md`). | ||||
| - Concelier quickstarts, CLI guides, Offline Kit manuals. | ||||
| - Release notes and migration playbooks. | ||||
|  | ||||
| ## Operating Principles | ||||
| - Keep guides deterministic and in sync with shipped configuration samples. | ||||
| - Prefer tables/checklists for operator steps; flag security-sensitive actions. | ||||
| - When work involves a specific `StellaOps.<Component>` project, consult both `docs/07_HIGH_LEVEL_ARCHITECTURE.md` and the matching dossier `docs/modules/<component>/architecture.md` before drafting or editing content. | ||||
| - Update `docs/TASKS.md` whenever work items change status (TODO/DOING/REVIEW/DONE/BLOCKED). | ||||
|  | ||||
| ## Coordination | ||||
| - Authority Core & Plugin teams for auth-related changes. | ||||
| - Security Guild for threat-model outputs and mitigations. | ||||
| - DevEx for tooling diagrams and documentation pipeline. | ||||
|   | ||||
		Reference in New Issue
	
	Block a user