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

@@ -1,23 +1,34 @@
# AGENTS
## Role
Centralizes policy configuration, provider trust weights, and justification guardrails applied to Excititor consensus decisions.
## Scope
- Policy models for tier weighting, provider overrides, justification allowlists, and conflict escalation.
- Configuration binding helpers (YAML/JSON) and validation of operator-supplied policy bundles.
- Evaluation services that expose policy revisions and change tracking to WebService/Worker.
- Documentation anchors for policy schema and upgrade guidance.
## Participants
- WebService consumes policy bindings to authorize ingest/export operations and to recompute consensus.
- Worker schedules reconciliation runs using policy revisions from this module.
- CLI exposes policy inspection commands based on exported descriptors.
## Interfaces & contracts
- `IVexPolicyProvider`, `IVexPolicyEvaluator`, and immutable policy snapshot value objects.
- Validation diagnostics APIs surfacing structured errors and warnings for operators.
## In/Out of scope
In: policy schema definition, binding/validation, evaluation utilities, audit logging helpers.
Out: persistence/migrations, HTTP exposure, connector-specific trust logic (lives in Core/Connectors).
## Observability & security expectations
- Emit structured events on policy load/update with revision IDs, but do not log full sensitive policy documents.
- Maintain deterministic error ordering for reproducible diagnostics.
## Tests
- Policy fixtures and regression coverage will live in `../StellaOps.Excititor.Policy.Tests` once scaffolded; leverage snapshot comparisons for YAML bindings.
# AGENTS
## Role
Centralizes policy configuration, provider trust weights, and justification guardrails applied to Excititor consensus decisions.
## Scope
- Policy models for tier weighting, provider overrides, justification allowlists, and conflict escalation.
- Configuration binding helpers (YAML/JSON) and validation of operator-supplied policy bundles.
- Evaluation services that expose policy revisions and change tracking to WebService/Worker.
- Documentation anchors for policy schema and upgrade guidance.
## Participants
- WebService consumes policy bindings to authorize ingest/export operations and to recompute consensus.
- Worker schedules reconciliation runs using policy revisions from this module.
- CLI exposes policy inspection commands based on exported descriptors.
## Interfaces & contracts
- `IVexPolicyProvider`, `IVexPolicyEvaluator`, and immutable policy snapshot value objects.
- Validation diagnostics APIs surfacing structured errors and warnings for operators.
## In/Out of scope
In: policy schema definition, binding/validation, evaluation utilities, audit logging helpers.
Out: persistence/migrations, HTTP exposure, connector-specific trust logic (lives in Core/Connectors).
## Observability & security expectations
- Emit structured events on policy load/update with revision IDs, but do not log full sensitive policy documents.
- Maintain deterministic error ordering for reproducible diagnostics.
## Tests
- Policy fixtures and regression coverage will live in `../StellaOps.Excititor.Policy.Tests` once scaffolded; leverage snapshot comparisons for YAML bindings.
## Required Reading
- `docs/modules/excititor/architecture.md`
- `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.