Create docs/responsibility-map.md: the single home for NetKingdom's
orchestration relationships, kept out of the orchestrated repos' intents
per ADR-0010. Records the classification criterion, the current
minimal-foundation scope, and per orchestrated repo (railiance-infra,
railiance-cluster, railiance-platform, key-cape, flex-auth) the resources
held, what the repo owns (execution), and what NetKingdom orchestrates
(meta). Lists dependencies and out-of-scope repos so the scoping decision
is explicit and revisitable.
Update ADR-0010 to point at the now-created map.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Record two foundational principles that emerged while aligning ecosystem
INTENT.md files:
1. Orchestration != dependency. NetKingdom orchestrates a repo when that
repo holds resources NetKingdom must manage (users, roles, scopes,
policies, infra resources). It depends on a repo when it merely uses it
as a tool. Defining question: does the repo hold resources NetKingdom
needs to orchestrate? (railiance-fabric = dependency;
railiance-infra/cluster/platform = orchestrated.)
2. Intent is self-coherent. A repo's INTENT.md describes its own purpose
abstractly; it must not reference NetKingdom, sister projects' intents,
or even dependencies. Relationships live in the responsibility map /
ADRs / interface contracts, not in intent.
Rejects the earlier "place in the NetKingdom landscape" block idea as a
Principle 2 violation.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- ADR-0007: refine (not overturn) the orchestration boundary with the
two-layer model — Railiance executes parametrized playbooks, NetKingdom
does meta-orchestration (scenario->playbook selection, parametrization,
responsibility map). Add the playbook/capability-contract dependency as
the prerequisite, analogous to the IAM Profile.
- INTENT.md: add "Why NetKingdom" (the kingdom metaphor: governed,
defended, living/evolving, tended by its people); Principle 7
(Meta-Orchestration over Re-Implementation); an Operating Model section
(kaizen-agent workforce for recurring duties + change/improvement); and
matching Direction-of-Evolution entries.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Make the lightweight->expanded decision explicitly capability-driven (not
scale-driven) and capture the turn-key, capability-selectable framework
ambition.
- arch doc: add capability-driven rationale to the identity-mode choice;
add a "Capability Progression (Start Small -> Enterprise)" ladder
(C0 bootstrap -> C6 self-optimizing), including the C2a/C2b 2FA split
(Authelia built-in vs privacyIDEA); answer the lightweight/expanded
open question as capability-driven
- INTENT.md: recast Progressive Expansion as capability-driven with a
no-structural-breaks guarantee; add capability-selection + turn-key
orchestration to the mission and identity
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Refine the recursive platform security architecture to make OpenBao the
canonical runtime secret authority, with SOPS/age, K8s Secrets, and the
emergency bundle reframed as bootstrap/delivery/break-glass mechanisms.
- credential-management standard v0.2: add OpenBao runtime authority
section, rotation rules, and prohibited patterns (OpenBao-as-PDP,
tenant platform-root)
- platform-identity-security-architecture: mark implemented; add
flex-auth/Topaz implications, Coulomb onboarding path, and a
production-readiness checklist
- NK-WP-0004/0005: document bootstrap-to-OpenBao handoff boundary
- NK-WP-0006/0007: status -> done with implementation reviews; add
recursive platform/tenant split and OpenBao broker/audit role for
object-storage STS vending
- NK-WP-0008: status -> done; repoint corpus to infospace-bench
- new ADR-0007 (orchestration boundary), ADR-0008 (STS vending
boundary), and the object-storage STS credential-vending architecture
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Permission enforcement on startup: enforce_permissions() checks store dir
(700), user files (600), signing key, TLS key, audit.log, revoked.json.
CLI and run_server() call it before any sensitive operation.
New modules:
security.py check_store(), enforce_permissions(), print_security_check()
audit.py log_event() — append-only TSV audit log (mode 600)
revoke.py revoke(jti), is_revoked(jti) — revocation list (mode 600)
New CLI commands:
security-check Print per-check pass/warn/fail report; exit 1 on failure
revoke-token <jti|jwt> Add JTI to revocation list; accepts raw JTI or full JWT
Serve integration:
Audit log written for auth request, token issuance, and userinfo calls
Revocation checked at /userinfo; revoked tokens return 401
Docs: security model section in LocalIdentity.md — threat model,
assumptions, non-guarantees, SELinux/AppArmor guidance, revocation usage.
138 tests passing (34 new for Stage 4).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Follows resolved decisions D4 and D5 (2026-03-01, Tegwick):
D4 — ESO chosen as secret injection strategy. NK-WP-0001 T01 Phase 0b
updated to specify ESO; T01 done-criteria updated to require a working ESO
test injection.
D5 — Local Identity implemented in-repo (not a separate repo). Four
deliverables:
- docs/LocalIdentity.md: capability overview, design principles, user
schema, OIDC provider description, risk mitigations, scope boundaries
- workplans/NK-WP-0002-local-identity.md: four-stage implementation plan
(core file store, bootstrap integration, minimal OIDC, security hardening)
with State Hub task IDs
- NK-WP-0001 updated: D2/D4/D5 rows resolved, T07 bootstrap section now
references NK-WP-0002 and documents the export→Keycloak migration path,
Open Questions condensed to two remaining artefacts
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
