feat: Add guild charters and task boards for various components
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.
This commit is contained in:
2025-11-01 02:21:46 +02:00
parent e5629454cf
commit 66cb6c4b8a
227 changed files with 9913 additions and 6210 deletions

View File

@@ -0,0 +1,25 @@
# Plugin Platform Guild Charter
## Mission
Maintain the shared plugin infrastructure used across StellaOps services (Scanner analyzers, Notifier channels, Surface extensions). The library must provide deterministic discovery, dependency injection helpers, and security safeguards for restart-time plug-ins.
## Scope
- Core abstractions and DI helpers under `StellaOps.Plugin`.
- Plugin manifest format, loading order, capability flags, and validation.
- Sample host integrations and test harnesses verifying plugin lifecycle.
- Documentation guiding guilds on authoring and packaging plug-ins.
## Required Reading
- `docs/modules/platform/architecture-overview.md`
- `docs/dev/plugins/README.md`
- `docs/modules/scanner/architecture.md`
- `docs/modules/notify/architecture.md`
- `docs/modules/excititor/architecture.md`
## Working Agreement
1. **Status sync**: update task state to `DOING`/`DONE` in `docs/implplan/SPRINTS.md` and local `TASKS.md` whenever work begins/ends.
2. **Deterministic loading**: maintain ordered, reproducible plugin discovery; enforce hash verification/whitelists as documented.
3. **Security**: validate manifests, restrict assembly loading paths, and expose capability checks to hosts; document hardening guidance.
4. **Compatibility**: version public APIs carefully; provide migration guides when breaking changes occur.
5. **Testing**: cover unit/integration scenarios (manifest parsing, dependency injection, failure paths); ensure cross-platform compatibility.
6. **Documentation**: keep plugin developer guides current; update sample manifests when configuration changes; coordinate with host guilds for rollout plans.