coulomb/key-cape
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

repo.work.create_intake KEY-IN-0001

Browse source 
correlation_id: 699a27b1-b998-4e47-801a-3cb1efe093de
reason: Request own-voice layer declaration under §11
source: repo-manager

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2564823@bnt-lap001
Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9
This commit is contained in:
repo-manager 2026-08-28 23:01:53 +02:00
parent 892149a7b5
commit 608c5d20cf
1 changed files with 38 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

38
intakes/intakes.md Normal file
View file

@ -0,0 +1,38 @@
# Intake records
## KEY-IN-0001 — Declaration requested: state this repository's layer in INTENT.md (security layer model §11)
```yaml
id: KEY-IN-0001
kind: intake
title: 'Declaration requested: state this repository''s layer in INTENT.md (security
layer model §11)'
status: open
origin: cross-repo
origin_ref: net-kingdom security-layer-model_v0.4 §11
priority: low
owner: key-cape
requested_by: gate-house
proposed_layer: Tooling
description: 'A conformance sweep on 2026-08-28 found this repository has no layer
declaration of its own. It carries a layering review note gate-house wrote into
the top of its INTENT.md on 2026-08-24, and that note names a layer — but the words
are gate-house''s, sitting above a line admitting the body is unadapted. Section
11 has since been amended to say so explicitly: a layer stated about a repository
by another repository is not a declaration; only the repository''s own file, in
its own voice, conforms. Seven of fifteen estate-authored repositories have declared;
this is one of the eight that have not, and the standard does not claim adoption
on the basis of notes gate-house wrote. REQUESTED: state the layer in INTENT.md
in your own voice, or contest it. PROPOSED LAYER: Tooling. Packaged identity tooling
(authelia, lldap, privacy-idea) behind a versioned IAM profile; authentication only.
Worth stating explicitly that key-cape is not an authorization decision point, since
''auth'' is ambiguous across the estate and access-engine owns the decision. Note
also that the components key-cape packages are not catalogued individually — if
you think they should be, say so. Contesting is a real option and costs nothing
— the three repositories that reviewed this model each returned a correction, two
of which changed the standard. If the proposed layer is wrong for what this repository
actually does, that is more useful to us than a label added to close a checkbox.
Standard: net-kingdom/canon/standards/security-layer-model_v0.4.md.'
created: '2026-08-28T21:01:53.604723Z'
updated: '2026-08-28T21:01:53.604723Z'
```