coulomb/security-canon
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
security-canon/GOAL.md
tegwick 1ac4f56783 Bootstrap security-canon governance and extraction plan 
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
2026-09-20 20:32:05 +02:00

2.1 KiB
Raw Blame History

repo repo_flavor project_status started
security-canon project draft 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.