secrets-engine/intakes/intakes.md

# Intake records

## SECRETS-IN-0001 — Declaration requested: state this repository's layer in INTENT.md (security layer model §11)

```yaml
id: SECRETS-IN-0001
kind: intake
title: 'Declaration requested: state this repository''s layer in INTENT.md (security
  layer model §11)'
status: closed
origin: cross-repo
origin_ref: net-kingdom security-layer-model_v0.7 §11
priority: low
owner: secrets-engine
requested_by: gate-house
proposed_layer: Engine
resolution: >-
  Declared Engine / Lifecycle in INTENT.md frontmatter and layer.yaml on
  2026-08-29 against accepted v0.7. Layer not contested. Catalog cell
  "custody" is a finding: OpenBao owns custody; this engine owns the
  lifecycle API over it. SSH-CA signing accepted as a proposed engine API
  and declined as a Staff lane. Secret-use evidence accepted as proposed.
  Review: history/2026-08-29-layer-model-scope-intent-review.md.
  Workplan: SECRETS-WP-0008.
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: Engine. Credential abstraction,
  custody, lifecycle. Two boundaries worth stating in your words: the decision that
  authority exists is access-engine''s, and the doctrine governing when authority
  may be materialized is gate-house''s. Also relevant: ops-warden has declared its
  SSH-CA signing write to OpenBao as an engine gap with intended owner secrets-engine,
  blocked on ''no engine exposes an SSH-CA surface''. You may want to contest or accept
  that intended ownership. 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:02:14.320087Z'
updated: '2026-08-28T21:02:14.320087Z'
state_hub_intake_id: "01a04cf6-dcd7-7bd4-82e4-ef434b15fe46"
```

## SECRETS-IN-0002 — flex-auth → access-engine repository-coordinate rename (consumer surface)

```yaml
id: SECRETS-IN-0002
kind: intake
title: 'flex-auth to access-engine repository-coordinate rename: consumer-surface confirmation'
status: open
origin: cross-repo
origin_ref: FLEX-WP-0020 (hub message 15cf351a-bad8-4259-9b6f-b21d183a20ab)
priority: low
owner: secrets-engine
requested_by: flex-auth
resolution: ''
description: >-
  flex-auth is preparing a repository-coordinate rename to access-engine.
  Repository UUID fda8ad85-a7d7-4055-8f21-902a533e59df and Forge ID 42 are
  unchanged; runtime and product names stay flex-auth per FLEX-DEC-2026-013.
  secrets-engine is a consumer surface and is asked to confirm no live
  repository URL or path remains. Survey 2026-09-21 found exactly one:
  docs/approval-service-auth.md line 56 passes
  `--flex-auth-source /home/worsch/flex-auth`, a local checkout path. Every
  other flex-auth string in this repository is a runtime or contract name that
  FLEX-DEC-2026-013 keeps: the Kubernetes namespace and service
  flex-auth-secrets-engine.flex-auth.svc.cluster.local, the token audience
  flex-auth, the contract version flex-auth.decision-record.v1, and prose
  citations of flex-auth decisions and documents. Those must not be renamed.
  Held open rather than edited, because the rename is preparing and not
  complete, and changing a documented local checkout path ahead of the move
  would document a path that does not exist yet. Close by updating that one
  line when flex-auth confirms the rename has landed.
state_hub_intake_id: "01a0c279-538e-7d99-bf69-f4c67a8d3eda"
```

## SECRETS-IN-0003 — railiance-clock: consumer review of the time-sample profile and adoption condition

```yaml
id: SECRETS-IN-0003
kind: intake
title: 'railiance-clock: review signing custody, rotation and lifecycle-consumer adoption condition'
status: open
origin: cross-repo
origin_ref: hub messages f90b9f17 and 302291b5 (railiance-clock, 2026-09-14)
priority: low
owner: secrets-engine
requested_by: railiance-clock
resolution: ''
description: >-
  railiance-clock published its foundation (commit 0a144b6, RCLK-WP plans) and a
  candidate time-sample profile (commit 7af595b, specs/sample-profile-v0.1.md:
  JWS Compact ES256, decimal-string ns, pinned authority/environment/policy,
  bounded elapsed intervals). Asked of secrets-engine: review signing custody
  and library compatibility for ES256 JWS, rotation/revocation and independent
  bootstrap, and return a linked lifecycle/consumer adoption condition
  (RCLK-WP-0002-T04, RCLK-WP-0004 propose a future server-side clock contract).
  Nothing is adopted or unblocked by it: the existing refusal of shifted
  validation clocks stands, and no key, policy or OS clock changed. Recorded at
  triage 2026-09-21 and not reviewed there: a custody and adoption review is
  owner design work, not a cheap reply. No secret values requested or sent.
state_hub_intake_id: "01a0c27b-25ec-7a52-ae11-911a75168dd0"
```