Some checks failed
		
		
	
	Docs CI / lint-and-preview (push) Has been cancelled
				
			- Introduced guild charters for Scanner Deno, PHP, Ruby, Native, WebService, Java, Surface.Env, Surface.FS, Surface.Secrets, Surface.Validation, UI, Zastava Observer, Zastava Webhook, Zastava Core, and Plugin Platform. - Each charter outlines the mission, scope, required reading, and working agreements for the respective guilds. - Created task boards for Surface.Env, Surface.FS, Surface.Secrets, Surface.Validation, and Zastava components to track progress and dependencies. - Ensured all documents emphasize determinism, offline readiness, security, and integration with shared Surface libraries.
		
			
				
	
	
		
			35 lines
		
	
	
		
			2.0 KiB
		
	
	
	
		
			Markdown
		
	
	
	
	
	
			
		
		
	
	
			35 lines
		
	
	
		
			2.0 KiB
		
	
	
	
		
			Markdown
		
	
	
	
	
	
# 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.
 | 
						|
 | 
						|
## Required Reading
 | 
						|
- `docs/README.md`
 | 
						|
- `docs/07_HIGH_LEVEL_ARCHITECTURE.md`
 | 
						|
- `docs/modules/platform/architecture-overview.md`
 | 
						|
- `docs/dev/31_AUTHORITY_PLUGIN_DEVELOPER_GUIDE.md`
 | 
						|
- Module-specific README and architecture dossiers for the area you are updating (for example, `docs/modules/concelier/README.md` and `docs/modules/concelier/architecture.md`)
 | 
						|
 | 
						|
## Working Agreement
 | 
						|
- 1. Update task status to `DOING`/`DONE` in both `docs/implplan/SPRINTS.md` and the local `TASKS.md` when you start or finish work.
 | 
						|
- 2. Review this charter and the Required Reading documents before coding; confirm prerequisites are met.
 | 
						|
- 3. Keep changes deterministic (stable ordering, timestamps, hashes) and align with offline/air-gap expectations.
 | 
						|
- 4. Coordinate doc updates, tests, and cross-guild communication whenever contracts or workflows change.
 | 
						|
- 5. Revert to `TODO` if you pause the task without shipping changes; leave notes in commit/PR descriptions for context.
 |