95dcb78e17
source: repo-manager reason: deterministic projection registration Assistant: codex Assistant-Model: gpt-5.6-sol Assistant-Session: 01a053ff-1d6f-7fe2-ac1c-a6eb40a42a0c
128 lines
5 KiB
Markdown
128 lines
5 KiB
Markdown
---
|
|
id: AUDIT-WP-0010
|
|
type: workplan
|
|
title: "Admit tenant-engine as an attributive sender"
|
|
domain: infotech
|
|
repo: audit-core
|
|
status: ready
|
|
owner: claude
|
|
topic_slug: railiance
|
|
created: "2026-08-29"
|
|
updated: "2026-08-29"
|
|
depends_on:
|
|
- AUDIT-WP-0005
|
|
state_hub_workstream_id: "54655357-74da-5f7f-8fa6-647d4c969f21"
|
|
---
|
|
|
|
# AUDIT-WP-0010 — Admit tenant-engine as an attributive sender
|
|
|
|
## Goal
|
|
|
|
Close `AUDIT-IN-0002`. `tenant-engine` emits mutation evidence through a local
|
|
outbox and **cannot land events in production until audit-core admits the
|
|
sender**. This is another repository's production blocked on ours, which is why
|
|
it is a workplan of its own rather than a task inside `AUDIT-WP-0009`.
|
|
|
|
The request is well-formed and arrives with its own bound already declared:
|
|
class **attributive**, drain non-blocking, documented at
|
|
`tenant-engine/docs/evidence-emission.md`. Under §9.6 that is a legitimate
|
|
trade — attributive evidence may deliberately trade away atomicity provided the
|
|
trade is declared and completeness is never claimed. `tenant-engine` declared
|
|
it. Nothing here needs renegotiating; it needs admitting.
|
|
|
|
Intake: `AUDIT-IN-0002` (`01a04d8f-b1c1-746a-8007-15221ebf0a48`), origin
|
|
`TEN-WP-0011-T04`. Onboarding follows INTENT principle 4 — a source is onboarded
|
|
when ownership, retention, access, export, and evidence policy are declared and
|
|
validated, not when events start arriving.
|
|
|
|
## Non-goals
|
|
|
|
- Reclassifying `tenant-engine` as load-bearing. It declared attributive and the
|
|
declaration is the emitter's to make; §9.6 obligations follow the class.
|
|
- Carrying any credential value in this repository, in a work record, in State
|
|
Hub, or in chat. The intake says so and it is right.
|
|
- Blocking on `AUDIT-WP-0009-T03`. The `evidence_kind` field lands there;
|
|
admission does not wait for it, and T04 below records the class in the
|
|
meantime.
|
|
|
|
## Tasks
|
|
|
|
```task
|
|
id: AUDIT-WP-0010-T01
|
|
status: todo
|
|
priority: high
|
|
state_hub_task_id: "e26170e3-78f1-5d98-bb8f-46cef32244bb"
|
|
```
|
|
Register the sender identity: name `tenant-engine`, `sources: [tenant-engine]`,
|
|
`may_write: true`, `may_read: false`, `secret_policy: redact`, tenants scoped as
|
|
the envelope requires. Follow the existing `user-engine` shape in
|
|
`deploy/externalsecret-senders.yaml` and `deploy/senders-scope.yaml`. No token
|
|
value in Git — projected only, per the established lane.
|
|
|
|
```task
|
|
id: AUDIT-WP-0010-T02
|
|
status: todo
|
|
priority: high
|
|
state_hub_task_id: "13855bd9-4ff4-5e8c-ab98-d5ff45103d22"
|
|
```
|
|
Provide the token lane. Coordinate the projected credential with the owning
|
|
credential operator through the `ops-warden` route, matching the custody pattern
|
|
already used for `user-engine`. Verify field presence without disclosure. Do not
|
|
transport a value through State Hub messages.
|
|
|
|
```task
|
|
id: AUDIT-WP-0010-T03
|
|
status: todo
|
|
priority: high
|
|
state_hub_task_id: "1a75fba2-a625-5e87-bba9-e38f010856fc"
|
|
```
|
|
Extend the NetworkPolicy. `deploy/networkpolicies.yaml` currently admits
|
|
`user-engine`; add `tenant-engine`. `tests/test_networkpolicies.py` exists —
|
|
extend it so the second sender is asserted rather than assumed, and so a future
|
|
third sender fails the test rather than silently failing in production.
|
|
|
|
```task
|
|
id: AUDIT-WP-0010-T04
|
|
status: todo
|
|
priority: medium
|
|
state_hub_task_id: "56bde19e-6b54-5d9e-a3d7-8b13e810cb51"
|
|
```
|
|
Validate the envelope against what `tenant-engine` actually sends:
|
|
`schema_version: audit-core.event.v1alpha1`, `tenant` = affected `tenant_id`,
|
|
`action` = domain event type, `resource` = `tenant:<id>`, duplicate event ids
|
|
returning 200. Confirm the duplicate path reconciles rather than minting a
|
|
second link (`test_replay_reconciles_rather_than_duplicating`). If the envelope
|
|
needs a field this engine does not send, reply with the correction the intake
|
|
invited rather than accepting a lossy record.
|
|
|
|
Record the declared class (**attributive**, non-blocking drain, trade declared
|
|
at `tenant-engine/docs/evidence-emission.md`) alongside the sender registration,
|
|
so the §9.6 trade is documented here and not only in the emitter.
|
|
|
|
```task
|
|
id: AUDIT-WP-0010-T05
|
|
status: todo
|
|
priority: medium
|
|
state_hub_task_id: "777bb728-4a4d-5c5b-8b62-24fdb6ab31e3"
|
|
```
|
|
Prove it end to end against the production receiver: a real event from
|
|
`tenant-engine` accepted, attributed to the right tenant, redacted per policy,
|
|
and linked into the chain. Record the evidence under `docs/evidence/`. Then
|
|
close `AUDIT-IN-0002` with outcome `promoted` citing this workplan, and reply to
|
|
`tenant-engine`.
|
|
|
|
## Acceptance
|
|
|
|
- `tenant-engine` events land in production, correctly attributed and redacted.
|
|
- The token never appears in Git, a work record, State Hub, or chat.
|
|
- The NetworkPolicy admits exactly the intended senders, asserted by test.
|
|
- The attributive trade is recorded on audit-core's side, and completeness is
|
|
nowhere claimed for this stream.
|
|
- `AUDIT-IN-0002` closed and the requester answered.
|
|
|
|
## Notes
|
|
|
|
`tenant-engine` did this the right way round: it built the outbox, declared the
|
|
class honestly, documented the trade, and asked before assuming it could emit.
|
|
The correct response is to move quickly, not to make it wait behind
|
|
`AUDIT-WP-0009`.
|