feat: Add guild charters and task boards for various components

- 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.

docs/modules/vexer/AGENTS.md

@@ -1,22 +1,34 @@
-# Vexer agent guide
-
-## Mission
-Vexer computes deterministic consensus across VEX claims, preserving conflicts and producing attestable evidence for policy suppression.
-
-## Key docs
-- [Module README](./README.md)
-- [Architecture](./architecture.md)
-- [Implementation plan](./implementation_plan.md)
-- [Task board](./TASKS.md)
-
-## How to get started
-1. Open ../../implplan/SPRINTS.md and locate the stories referencing this module.
-2. Review ./TASKS.md for local follow-ups and confirm status transitions (TODO → DOING → DONE/BLOCKED).
-3. Read the architecture and README for domain context before editing code or docs.
-4. Coordinate cross-module changes in the main /AGENTS.md description and through the sprint plan.
-
-## Guardrails
-- Honour the Aggregation-Only Contract where applicable (see ../../ingestion/aggregation-only-contract.md).
-- Preserve determinism: sort outputs, normalise timestamps (UTC ISO-8601), and avoid machine-specific artefacts.
-- Keep Offline Kit parity in mind—document air-gapped workflows for any new feature.
-- Update runbooks/observability assets when operational characteristics change.
+# Vexer agent guide
+
+## Mission
+Vexer computes deterministic consensus across VEX claims, preserving conflicts and producing attestable evidence for policy suppression.
+
+## Key docs
+- [Module README](./README.md)
+- [Architecture](./architecture.md)
+- [Implementation plan](./implementation_plan.md)
+- [Task board](./TASKS.md)
+
+## How to get started
+1. Open ../../implplan/SPRINTS.md and locate the stories referencing this module.
+2. Review ./TASKS.md for local follow-ups and confirm status transitions (TODO → DOING → DONE/BLOCKED).
+3. Read the architecture and README for domain context before editing code or docs.
+4. Coordinate cross-module changes in the main /AGENTS.md description and through the sprint plan.
+
+## Guardrails
+- Honour the Aggregation-Only Contract where applicable (see ../../ingestion/aggregation-only-contract.md).
+- Preserve determinism: sort outputs, normalise timestamps (UTC ISO-8601), and avoid machine-specific artefacts.
+- Keep Offline Kit parity in mind—document air-gapped workflows for any new feature.
+- Update runbooks/observability assets when operational characteristics change.
+## Required Reading
+- `docs/modules/vexer/README.md`
+- `docs/modules/vexer/architecture.md`
+- `docs/modules/vexer/implementation_plan.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.