ops-mason/workplans/MASON-WP-0002-whitehat-foundational-plane.md

---
id: MASON-WP-0002
type: workplan
title: "Provision the Whitehat foundational plane and reconcile intake drift"
domain: infotech
repo: ops-mason
status: finished
owner: codex
topic_slug: whitehat-foundational-plane
created: "2026-08-22"
updated: "2026-08-22"
origin: external-demand
origin_ref: "statehub-message:311a274e-9434-4fc3-bc52-8ea15ca68274"
reviewed_at: "2026-08-22"
quality_dor: DoR-Ok
quality_dor_at: "2026-08-22"
quality_dor_by: codex
quality_dor_note: "Outcome, scope, ownership, source revisions, dependencies, live-change boundary, verification, rollback, and requester/target-owner handoffs were reviewed against the repo and live read-only preflight."
quality_dod: DoD-Ok
quality_dod_at: "2026-08-22"
quality_dod_by: codex
quality_dod_note: "All tasks are complete; the plane is verified with automated coverage and evidence, documentation is current, handoffs are sent, and the only historical identifier debt is registered as residual MASON-IN-0001."
state_hub_workstream_id: "9b34bf82-9d08-51e4-9204-8de5382a4153"
---

# Provision the Whitehat foundational plane and reconcile intake drift

Whitehat's governed live-test plane cannot admit a future engagement until its
foundational Kubernetes boundary exists. `whitehat-security` requested that
`ops-mason` provision only that boundary in State Hub message
`311a274e-9434-4fc3-bc52-8ea15ca68274`; `audit-core` explicitly confirmed the
same bounded scope and asked Mason to proceed in message
`7e0c1d68-1a68-4345-a845-44bd0dae8373`.

The source contract is `whitehat-security` commit
`4882c2d47a826a305d5c4e05aa7fcc1252c3887e`. The plane implementation entered
at commit `95129d7a35c8999be359b163b554853c9c6afa3a`; its three selected files are
unchanged through inspected HEAD `7e83a665735f11fccc4aac4904a510a18d759ce5`.
The requested NetworkPolicy file contains two objects, so the bounded live
change is exactly four Kubernetes objects:

- Namespace `whitehat`;
- NetworkPolicies `default-deny` and `allow-audit-core-e2`;
- ServiceAccount `whitehat-runner` with service-account token automount off.

This workplan does **not** authorize a runner Pod, credential Secret, identity
projection, custody-broker connection, engagement approval, or target packet.
The cancelled identifiers `WH-ENG-20260821-AUDIT-E2` and
`WH-ENG-20260821-TENANT-E2` remain terminal.

The plan is ready as a structure. T01 and T04 are repository-local work. T02 is
a bounded, reversible live-cluster change authorized by the requesting plane
owner and confirmed by the target owner; its required read-only preflight is
part of the task. T03 depends on successful T02 evidence. The README wording
correction can proceed in parallel and is not authority to expand the apply
set. No unresolved dependency makes the first implementation step guesswork.

## Adopt and pin the bounded plane contract

```task
id: MASON-WP-0002-T01
status: done
priority: high
state_hub_task_id: "067451e4-50f7-59d9-b804-50f348e22508"
```

Create an ops-mason-owned, source-pinned apply surface derived only from:

- `plane/namespace.yaml`;
- `plane/network-policy.yaml`;
- `plane/service-account.yaml`.

Record both source revisions above and verify that the selected object content
is unchanged. Do not copy or reference `plane/runner-pod.yaml` from an apply
target. Validate the exact object set locally and against the Kubernetes API
without persisting it.

Resolve the ordering contradiction in Whitehat's source documentation as a
coordination correction: `plane/README.md` still says a new engagement must
exist first, while the newer dated provision request says the foundation must
exist before Whitehat drafts that engagement. Record the dated request and
Audit-core confirmation as the operative construction authority, and ask
Whitehat to align its README. Do not mint an engagement ID here.

**Done when:** the checked-in Mason render has provenance, contains exactly the
four allowed objects, passes dry-run validation, and has an explicit exclusion
list and rollback procedure.

**Done (2026-08-22):** added the byte-identical source pins, approved
construction plan, declarative bundle, guarded CLI, safety documentation, and
rollback generator. Thirty tests pass. Live read-only preflight reports all
four objects absent and validates the matching audit-core Service/policy.
Bundle digest: `9636f48f0b994118ff60a8c014e0099486945d66a2b3d3582dc57a09862b2035`.
Whitehat README alignment request: State Hub message
`47032e07-5086-449f-8251-0f69df6cd934`.

## Provision and verify the foundational plane

```task
id: MASON-WP-0002-T02
status: done
priority: high
state_hub_task_id: "23f78bc5-4185-5181-9f3c-fd718641d2a5"
```

Before apply, recheck the active Kubernetes context, creation authority,
namespace absence or exact adoptability, Audit-core Service port `8080`, and
the matching target ingress policy. Apply only the T01 render.

Verify using metadata only:

- Namespace `whitehat` has restricted Pod Security admission and the plane
  labels from the contract;
- both NetworkPolicies have the exact selectors, destinations, and ports from
  the pinned render;
- ServiceAccount `whitehat-runner` exists with
  `automountServiceAccountToken: false`;
- the namespace contains no Pod, Secret created by this work, projected
  identity, engagement lease, or target traffic.

Rollback is object-scoped deletion of the two NetworkPolicies and the
ServiceAccount. Delete the namespace only after proving that no later or
unrelated object has entered it; if the namespace is still foundation-only,
namespace deletion is the complete rollback. Never use an unresolved variable
or broad selector for rollback.

**Done when:** all four objects are live and match the render, negative-scope
checks are clean, and the exact rollback commands have been captured without
executing them.

**Done (2026-08-22):** guarded apply created exactly the four approved objects.
All desired fields re-verify as exact, every manifest passed server dry-run,
`whitehat-runner` reports token automount `false`, and the namespace has zero
Pods and zero Secrets. Evidence includes object UIDs/resource versions and
rollback; no rollback command or target packet was executed.

## Return evidence and bounded handoff

```task
id: MASON-WP-0002-T03
status: done
priority: high
state_hub_task_id: "a9c0844b-bf0a-5a53-b7e7-c0c2fbb842e6"
```

Write a non-secret evidence record with source revisions, apply time, object
names, UIDs/resource versions where useful, verification output, exclusions,
and rollback. Send pointer-only completion messages to `whitehat-security` and
`audit-core`.

The handoff may state that Whitehat can draft a fresh engagement proposal. It
must not approve that engagement, create credentials, connect the custody
broker, deploy the runner, or exercise the target. Those are later governed
records with new identifiers and their own approvals.

**Done when:** both requesters have apply evidence and rollback, State Hub has
a progress record, and the next engagement remains explicitly separate.

**Done (2026-08-22):** evidence landed in ops-mason commit `c26a6e5` and was
sent with rollback to Whitehat (`a5f00f62-76f2-4ab1-92a3-40c67942813e`) and
audit-core (`161242af-fdf9-45f9-b635-86d95863e24e`). Both handoffs preserve the
separate fresh-engagement, credential, runner, and traffic gates.

## Reconcile local intake and publication drift

```task
id: MASON-WP-0002-T04
status: done
priority: low
state_hub_task_id: "f71f5eee-9ae0-50a2-a38d-2119d5abd175"
```

Clean up the bounded repository drift discovered while triaging this request:

- reconcile `plans/rapp-qonto-openbao-approle-bridge.md` frontmatter with its
  recorded successful revised build, without changing the live lane;
- fetch and verify remote ancestry, review the existing local commit set, and
  publish only by a normal fast-forward push; never force-push;
- obtain the canonical ops-mason classification through the Repo Manager
  workflow and add `.repo-classification.yaml`; do not invent classification
  values merely to silence C-24/C-35;
- re-run repository tests and consistency checks after the record changes;
- reconcile the legacy noncanonical `MASON-0001-Txx` task species and duplicate
  `MASON-0001-T01` through the registrar-safe migration path; if that cannot be
  done without rewriting registered identity, create a residual instead of
  silently renumbering anything.

This task is repository hygiene only. It must not be used to broaden T01-T03,
alter credentials, or modify live infrastructure.

**Done when:** plan status matches recorded build reality, committed work is
published safely or an explicit blocker is recorded, and no unresolved
consistency warning is hidden.

**Done (2026-08-22):** reconciled the Qonto plan to `built`; fetched and
verified fast-forward ancestry; published all work normally; added a canonical
Repo Manager-validated `tooling` classification; and reduced consistency debt
to the historical legacy identifier species. Canon forbids renaming existing
IDs, so that debt is now live residual `MASON-IN-0001`
(`01a028d1-c4af-7a06-adb5-c90399721872`), handed to the Custodian and Repo
Manager in messages `08067461-bb95-42e2-b8de-b492fb99f56e` and
`10ccd734-7c93-43d2-8ccd-e38bb7d4c975`. No registered identity was rewritten.

### Workplan completion conditions

Finish this workplan only when T01-T04 are done or any genuine leftover has
been handed off as a live residual record. Before marking `finished`, run the
repo test suite, `git diff --check`, and `statehub fix-consistency`, then record
the final evidence and handoff identifiers in State Hub.