feat: Add guild charters and task boards for various components
Some checks failed
Docs CI / lint-and-preview (push) Has been cancelled
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:
@@ -1,15 +1,26 @@
|
||||
# Attestation Envelope Guild Charter
|
||||
|
||||
## Mission
|
||||
Provide deterministic DSSE envelope handling with multi-signature support, canonical serialization, hashing, and integrity safeguards for all Stella attestations.
|
||||
|
||||
## Scope
|
||||
- DSSE encoding/decoding, canonical JSON handling, and detached payload support.
|
||||
- Multi-signature verification, key identification, and cryptographic primitives.
|
||||
- Integration with KMS drivers and transparency log witness utilities.
|
||||
- Fuzz and property testing for envelope parsing and normalization.
|
||||
|
||||
## Definition of Done
|
||||
- Envelope APIs produce canonical payloads and support multiple signatures deterministically.
|
||||
- Verification detects tampering, mismatched subjects, and unsupported algorithms.
|
||||
- Property and fuzz tests cover canonicalization and signature edge cases.
|
||||
# Attestation Envelope Guild Charter
|
||||
|
||||
## Mission
|
||||
Provide deterministic DSSE envelope handling with multi-signature support, canonical serialization, hashing, and integrity safeguards for all Stella attestations.
|
||||
|
||||
## Scope
|
||||
- DSSE encoding/decoding, canonical JSON handling, and detached payload support.
|
||||
- Multi-signature verification, key identification, and cryptographic primitives.
|
||||
- Integration with KMS drivers and transparency log witness utilities.
|
||||
- Fuzz and property testing for envelope parsing and normalization.
|
||||
|
||||
## Definition of Done
|
||||
- Envelope APIs produce canonical payloads and support multiple signatures deterministically.
|
||||
- Verification detects tampering, mismatched subjects, and unsupported algorithms.
|
||||
- Property and fuzz tests cover canonicalization and signature edge cases.
|
||||
|
||||
## Required Reading
|
||||
- `docs/modules/attestor/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.
|
||||
|
||||
@@ -1,14 +1,25 @@
|
||||
# Attestation Payloads Guild Charter
|
||||
|
||||
## Mission
|
||||
Define strongly typed, versioned schemas for all attestation payloads and provide validation utilities for generating and verifying evidence.
|
||||
|
||||
## Scope
|
||||
- JSON Schemas, code generation, and documentation for each attestation type.
|
||||
- Normalization and validation logic shared across services, CLI, and SDKs.
|
||||
- Sample payloads and golden fixtures used in contract tests and docs.
|
||||
|
||||
## Definition of Done
|
||||
- Payload types compiled into Go/TypeScript models with validation helpers.
|
||||
- Schemas published with semantic versioning and change logs.
|
||||
- Golden samples maintained with acceptance tests and doc integration.
|
||||
# Attestation Payloads Guild Charter
|
||||
|
||||
## Mission
|
||||
Define strongly typed, versioned schemas for all attestation payloads and provide validation utilities for generating and verifying evidence.
|
||||
|
||||
## Scope
|
||||
- JSON Schemas, code generation, and documentation for each attestation type.
|
||||
- Normalization and validation logic shared across services, CLI, and SDKs.
|
||||
- Sample payloads and golden fixtures used in contract tests and docs.
|
||||
|
||||
## Definition of Done
|
||||
- Payload types compiled into Go/TypeScript models with validation helpers.
|
||||
- Schemas published with semantic versioning and change logs.
|
||||
- Golden samples maintained with acceptance tests and doc integration.
|
||||
|
||||
## Required Reading
|
||||
- `docs/modules/attestor/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.
|
||||
|
||||
@@ -1,14 +1,25 @@
|
||||
# Attestation Verification Guild Charter
|
||||
|
||||
## Mission
|
||||
Implement the verification engine that enforces attestation policies, issuer trust, transparency requirements, and produces audit-ready reports.
|
||||
|
||||
## Scope
|
||||
- Verification pipeline integrating DSSE validation, issuer/key trust, Policy Studio rules, freshness checks, and transparency proofs.
|
||||
- Caching and reporting for verification results.
|
||||
- Error codes and explainability artifacts for UI/CLI consumption.
|
||||
|
||||
## Definition of Done
|
||||
- Verification passes/fails deterministically with detailed report structures.
|
||||
- Caching improves performance without sacrificing correctness.
|
||||
- Policies enforce scope-based rules and waivers, with unit/integration coverage.
|
||||
# Attestation Verification Guild Charter
|
||||
|
||||
## Mission
|
||||
Implement the verification engine that enforces attestation policies, issuer trust, transparency requirements, and produces audit-ready reports.
|
||||
|
||||
## Scope
|
||||
- Verification pipeline integrating DSSE validation, issuer/key trust, Policy Studio rules, freshness checks, and transparency proofs.
|
||||
- Caching and reporting for verification results.
|
||||
- Error codes and explainability artifacts for UI/CLI consumption.
|
||||
|
||||
## Definition of Done
|
||||
- Verification passes/fails deterministically with detailed report structures.
|
||||
- Caching improves performance without sacrificing correctness.
|
||||
- Policies enforce scope-based rules and waivers, with unit/integration coverage.
|
||||
|
||||
## Required Reading
|
||||
- `docs/modules/attestor/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.
|
||||
|
||||
@@ -37,3 +37,14 @@ Deliver the API, workers, and storage that power signing, verification, and life
|
||||
- Signing and verification APIs operate deterministically with full explainability.
|
||||
- Policy enforcement integrated with Authority & Tenancy scopes.
|
||||
- Transparency proof handling, key rotation, and revocation workflows implemented.
|
||||
|
||||
## Required Reading
|
||||
- `docs/modules/attestor/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.
|
||||
|
||||
Reference in New Issue
Block a user