coulomb/security-canon
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Fold GOAL.md into INTENT.md for prj-flavor conformance

Browse source 
fix-consistency C-35 flags shipping both INTENT.md and GOAL.md under the
project flavor. The sibling canons (CommerceCanon, InterfaceCanon) ship
INTENT.md only, and the repository owner asked for INTENT.md, so the outcome,
invariants, success gates and retirement condition move into INTENT.md and
GOAL.md is removed. References in README, AGENTS and SECURITY-WP-0001 updated.

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
This commit is contained in:
tegwick 2026-09-20 20:33:56 +02:00
parent 04b836cac1
commit 95267b137d
6 changed files with 66 additions and 52 deletions
Download patch file Download diff file Expand all files Collapse all files

2
AGENTS.md
View file

@ -10,7 +10,7 @@
**Workplan prefix:** `SECURITY-WP-`
**Upstream canon:** info-tech-canon
Orient: INTENT.md → GOAL.md → SCOPE.md → workplans/.
Orient: INTENT.md → SCOPE.md → workplans/.
## State Hub Integration

49
GOAL.md
View file

@ -1,49 +0,0 @@
---
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.

41
INTENT.md
View file

@ -88,3 +88,44 @@ The repository should initially establish the canon skeleton and federation
interface, then receive the security material extracted from InfoTechCanon with
its provenance intact, then publish mappings and at least one worked profile.
Stable promotion requires reviewed mappings and concrete consumer evidence.
## 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.

2
README.md
View file

@ -16,7 +16,7 @@ access governance standard, and the CARING Kubernetes RBAC benchmark.
| **Workplan prefix** | `SECURITY-WP-` |
| **Upstream canon** | [InfoTechCanon](../info-tech-canon) |
Start with [INTENT.md](INTENT.md), [GOAL.md](GOAL.md), and [SCOPE.md](SCOPE.md).
Start with [INTENT.md](INTENT.md) and [SCOPE.md](SCOPE.md).
Agent instructions are in [AGENTS.md](AGENTS.md); active work is in
[workplans/](workplans/).

16
WORK-RECORDS.md Normal file
View file

@ -0,0 +1,16 @@
# Work Records — security-canon
> Generated by `statehub fix-consistency` (CUST-WP-0061-T04, work-record
> stage 3). Do not edit by hand — edit the source file/block listed for
> each record and re-run fix-consistency to refresh this index. Archived
> workplans are omitted; closed decisions/intakes/engagements stay listed
> so recently-resolved work is still visible. [auto]
| Kind | ID | Status | Lane | Source |
| --- | --- | --- | --- | --- |
| workplan | SECURITY-WP-0001 | active | — | workplans/SECURITY-WP-0001-bootstrap-and-extraction-plan.md |
| task | SECURITY-WP-0001-T01 | done | — | workplans/SECURITY-WP-0001-bootstrap-and-extraction-plan.md |
| task | SECURITY-WP-0001-T02 | todo | — | workplans/SECURITY-WP-0001-bootstrap-and-extraction-plan.md |
| task | SECURITY-WP-0001-T03 | todo | — | workplans/SECURITY-WP-0001-bootstrap-and-extraction-plan.md |
| task | SECURITY-WP-0001-T04 | todo | — | workplans/SECURITY-WP-0001-bootstrap-and-extraction-plan.md |
| task | SECURITY-WP-0001-T05 | wait | — | workplans/SECURITY-WP-0001-bootstrap-and-extraction-plan.md |

8
workplans/SECURITY-WP-0001-bootstrap-and-extraction-plan.md
View file

@ -9,6 +9,7 @@ owner: claude
topic_slug: security-canon
created: "2026-09-20"
updated: "2026-09-20"
state_hub_workstream_id: "72c0e8f7-c904-59bd-9a7f-55d6de8ac715"
---
# Bootstrap and extraction plan
@ -21,7 +22,7 @@ disposition that the migration itself will follow.
Scope is bootstrap and planning. The migration of artifacts is deliberately not
in this workplan: it depends on the disposition review in T02 and gets its own
workplan once the boundary is settled. See [INTENT.md](../INTENT.md) for the
layer claim and [GOAL.md](../GOAL.md) for the success gates.
layer claim and [INTENT.md](../INTENT.md) for the success gates.
## Establish repository governance and registration
@ -29,6 +30,7 @@ layer claim and [GOAL.md](../GOAL.md) for the success gates.
id: SECURITY-WP-0001-T01
status: done
priority: high
state_hub_task_id: "9eabbe55-3529-5821-a248-d05c57a3556f"
```
Clone the Forgejo stub to the workstation, scaffold the repository to the
@ -43,6 +45,7 @@ running `statehub fix-consistency` — never by hand.
id: SECURITY-WP-0001-T02
status: todo
priority: high
state_hub_task_id: "8b9e4cd0-9905-5ae8-9a23-8957110d72e4"
```
Produce a reviewed disposition record naming, for every security artifact in
@ -63,6 +66,7 @@ answers as a decision, since they bind both canons.
id: SECURITY-WP-0001-T03
status: todo
priority: medium
state_hub_task_id: "dd8bc579-6a89-5b77-bfd8-3acdb4a4f472"
```
Enumerate every inbound reference to the extraction candidates — InfoTechCanon
@ -77,6 +81,7 @@ validating clean after each slice.
id: SECURITY-WP-0001-T04
status: todo
priority: medium
state_hub_task_id: "a844ccdc-f75d-53b6-858e-c92f30aad7ce"
```
Publish SecurityCanon's interface card with actual imports, available exports,
@ -91,6 +96,7 @@ prj-canon-federation rather than amending federation governance here.
id: SECURITY-WP-0001-T05
status: wait
priority: medium
state_hub_task_id: "387bfae1-c7a1-5826-856e-f5364121f849"
```
With the disposition (T02) and reference survey (T03) reviewed, draft the