Headless multi-application, multi-tenant security zone mangement engine.
T02 said no join key exists — too strong. The correction said the workload side exists "and most of the join with it" — too optimistic, and it was an inference from structure rather than a measurement. Computed, the join matches exactly one lane: issue-core-ingestion-api-key. rapp-qonto-keycape-client demonstrates the predicted naming failure: the path offers keycape-client and rapp-qonto while the rapp declares name qonto, so neither candidate matches. The gap is therefore not a missing key but missing declarations. Thirteen lanes name something plausible that no rapp declares as a workload; thirteen more are not KV addresses at all. This blocks stance modelling rather than unblocking it, and the tempting escape — binding zones to something other than a workload for lanes that have none — would quietly undo the subject decision. Recorded as a decision for repo-manager and net-kingdom rather than resolved here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| docs | ||
| workplans | ||
| .custodian-brief.md | ||
| .gitignore | ||
| .repo-classification.yaml | ||
| AGENTS.md | ||
| GOAL.md | ||
| INTENT.md | ||
| README.md | ||
| SCOPE.md | ||
| WORK-RECORDS.md | ||
zone-engine
Headless authority for security zones — named bands of the estate with different enforcement rigidity, and the lifecycle of time-boxed exceptions to them.
A zone answers a question no existing axis answers: is this control enforced
here, and what happens when it fails? NetKingdom can already say how exposed a
workload is (environment posture), how ready it is (workload maturity M0–M3),
and what state the organization is in (organization_posture). All three
describe. None decides.
zone-engine is not a policy decision point. flex-auth remains the only
PDP; zone membership reaches it by compilation into the registry it already
consumes, never by a synchronous lookup in the decision path.
Orient: GOAL.md → SCOPE.md → workplans/.