tegwick
1ac4f56783
Scaffold the repository to the repo-manager standard and establish its governance surface: INTENT declaring the Taxonomy-layer claim and boundary against NetKingdom, flex-auth, key-cape, OpenBao and whitehat-security; GOAL with migration invariants and success gates; SCOPE listing the extraction candidates and the unresolved boundary questions; AGENTS repo identity; repo classification. Add SECURITY-WP-0001 covering registration, the disposition review of InfoTechCanon's security material, the reference-impact survey, the federation interface card, and the handoff to a migration workplan. No canon content is moved yet — the migration waits on the reviewed disposition. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AUkN13CAqtXWPXuEiEtmJj Assistant: claude-code Assistant-Model: opus Assistant-Process: 36656@bnt-lap001 Assistant-Session: 66d6eece-d245-43ca-85e8-68a1b5970a67
49 lines
2.1 KiB
Markdown
49 lines
2.1 KiB
Markdown
---
|
|
repo: security-canon
|
|
repo_flavor: project
|
|
project_status: draft
|
|
started: "2026-09-20"
|
|
---
|
|
|
|
# Goal — security-canon
|
|
|
|
## Outcome
|
|
|
|
InfoTechCanon's IT-security material lives in SecurityCanon as a coherent,
|
|
independently reviewable canon: security terminology, the CARING access
|
|
governance standard and its Kubernetes RBAC benchmark, published with declared
|
|
imports from InfoTechCanon, a federation interface card, and preserved
|
|
provenance — while InfoTechCanon retains only the shared roots those artifacts
|
|
import and carries no dangling references.
|
|
|
|
## Invariants
|
|
|
|
- InfoTechCanon remains valid at every step: `make check` passes and its
|
|
validation reports zero errors before and after each migration slice.
|
|
- Migrated artifacts keep their provenance and their InfoTechCanon history;
|
|
extraction is a move with recorded lineage, not a rewrite.
|
|
- Concepts are imported from their owning canon, never redefined on both sides.
|
|
- No concept is left unowned, and no concept is claimed by two canons.
|
|
- The State Hub stays a read model: workplan files here are authoritative and
|
|
are registered by `fix-consistency`, never by hand.
|
|
|
|
## Success gates
|
|
|
|
1. Repository registered in the State Hub with a topic, classification, and
|
|
federation interface card; reciprocal navigation with InfoTechCanon passes
|
|
the canon-federation validator.
|
|
2. A reviewed disposition record naming, for every security artifact in
|
|
InfoTechCanon, whether it moves, stays, or splits — with rationale.
|
|
3. Migration complete: the artifacts dispositioned as `move` are present here
|
|
with provenance, and absent from InfoTechCanon.
|
|
4. Both canons validate clean after migration, with no unresolved cross-canon
|
|
references in either direction.
|
|
5. At least one worked profile or benchmark demonstrates the canon is usable by
|
|
a consumer, and its scope statement is reviewed against intent.
|
|
|
|
## Project retirement
|
|
|
|
Archive this repository only if the extraction is abandoned and the material
|
|
returns to InfoTechCanon. On success this repository does not retire — it
|
|
becomes a standing canon and its project flavor is reconsidered, as
|
|
CommerceCanon and InterfaceCanon were.
|