stella-ops.org/git.stella-ops.org
1
0
Fork 0
Code Issues Pull Requests Actions 12 Releases Wiki Activity

feat: Add guild charters and task boards for various components
Some checks failed
Docs CI / lint-and-preview (push) Has been cancelled
Details

Browse Source 
- 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:
master
2025-11-01 02:21:46 +02:00
parent e5629454cf
commit 66cb6c4b8a
227 changed files with 9913 additions and 6210 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
src/__Libraries/StellaOps.Cryptography.Kms/AGENTS.md
View File

@@ -1,14 +1,24 @@
# KMS & Key Management Guild Charter
## Mission
Provide key management abstractions and drivers (file, cloud KMS, HSM, FIDO2) for signing and verification workflows.
## Scope
- Key store interfaces, secure configuration loading, and audit logging.
- Drivers for file-based development keys, cloud KMS providers, PKCS#11 HSMs, and FIDO2 devices.
- Key rotation, revocation, and attestation for keys used in signing.
## Definition of Done
- KMS API supports signing, verification, key metadata, rotation, and revocation.
- Drivers pass integration tests and security review.
- CLI/Console can manage keys using these abstractions.
# KMS & Key Management Guild Charter
## Mission
Provide key management abstractions and drivers (file, cloud KMS, HSM, FIDO2) for signing and verification workflows.
## Scope
- Key store interfaces, secure configuration loading, and audit logging.
- Drivers for file-based development keys, cloud KMS providers, PKCS#11 HSMs, and FIDO2 devices.
- Key rotation, revocation, and attestation for keys used in signing.
## Definition of Done
- KMS API supports signing, verification, key metadata, rotation, and revocation.
- Drivers pass integration tests and security review.
- CLI/Console can manage keys using these abstractions.
## Required Reading
- `docs/modules/platform/architecture-overview.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.

10
src/__Libraries/StellaOps.Cryptography/AGENTS.md
View File

@@ -20,3 +20,13 @@ Team 8 owns the end-to-end security posture for StellaOps Authority and its cons
- Maintain `docs/security/authority-threat-model.md` and ensure mitigations are tracked.
- All crypto consumption flows through `StellaOps.Cryptography` abstractions to enable sovereign crypto providers.
- Every new cryptographic algorithm, dependency, or acceleration path ships as an `ICryptoProvider` plug-in under `StellaOps.Cryptography.*`; feature code must never bind directly to third-party crypto libraries.
## Required Reading
- `docs/modules/platform/architecture-overview.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.

25
src/__Libraries/StellaOps.Plugin/AGENTS.md Normal file
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.