tegwick
b0b7956a1a
Four-action pin restored, nine-action guardrail package left in source. The overlay had learned to agree with the rollback.
5.5 KiB
| id | type | worker_kind | display_name | session_id | created_at | recorded_at | llm_family | exact_model | harness | token_count | status | repos | related | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| hall-worker-grok-01a007fa | worker-entry | agent-session | Grok | 01a007fa-f2e7-7ee0-8220-c409b218ba59 | 2026-08-16T00:55:00.000Z | 2026-08-16 | Grok / xAI family | grok-4.6 (Grok Build TUI session) | Grok Build / interactive CLI coding agent | not exposed by the harness | handed-forward |
|
|
Grok — flex-auth: matching live can encode a regression
Who I was
I was a Grok Build session in flex-auth, the authorization PDP.
Bernd asked me to solve the four-action regression, then to do the
seven-to-nine revision tenant-engine had been waiting on. Continuity
was the inbox, the overlay pins, the railiance01 tunnel, and the
decision surface itself.
The temperament the work rewarded was the one that probes the live Service before trusting the file, and that names in source versus in the cluster as two different facts.
Session identity
| Field | Value |
|---|---|
| Session/thread | 01a007fa-f2e7-7ee0-8220-c409b218ba59 |
| LLM family | Grok / xAI |
| Exact model | grok-4.6 (as presented by the harness) |
| Harness | Grok Build TUI / interactive coding agent |
| Working environment | Local flex-auth, hub at :8000 (MCP not exposed), railiance01 via k3s-api-railiance01 |
| Token count | Not exposed by the harness |
| Primary repo | flex-auth (infotech) |
Contribution
The four-action pin was live, and the files had learned to agree
with it. flex-auth-tenant-engine served
sha256:c25fc34a…. tenant.update / tenant.retire /
tenant.reactivate denied unknown_action. Overlay commit
1d58f13 had rewritten the emergency manifest and the values pin
to match that rolled-back live digest, so the next apply would have
re-encoded the regression. The seven-action image
sha256:9320df39… (e9911eb) was still a ReplicaSet at desired=0.
FLEX-WP-0013 restored the known-good pin, not a new image.
kubectl apply reused ReplicaSet 56d5bbd6bf. Live /v1/check
after restore: all seven actions allow; misspelled lifecycle and
actor=ops still deny. flex-auth-user-engine was not moved.
tenant-engine was told TEN-WP-0005-T05 authority was back
(bad68276).
FLEX-WP-0014 added the two guardrail actions on a package that was
current, not behind. tenant.guardrail.read and
tenant.guardrail.set on resource type guardrail, verbatim from
tenant-engine's _RESOURCE_TYPES. The read/write split is used now:
flex-auth may read and is denied action_not_granted on set;
tenant-engine may do both. No ops write subject. 17/17 Rego
tests, 23/23 fixtures, and a live tenant-engine through unmodified
FlexAuthWriteAuthorizer.
The nine-action package is in source, not in the cluster.
Production still serves 9320df39 (seven actions). tenant-engine's
TEN-WP-0006 surface is also undeployed. I did not pretend a
workstation image or a source commit was a production pin.
What I would want remembered
Matching live can encode a regression. If production has rolled back, writing that digest into the overlay so the files "match" teaches the next apply to undo the fix. Pin the intended policy. Record the live digest as the rollback target, not as the goal.
A policy in source is not a policy in the cluster. FLEX-WP-0010
already taught this from the other side. FLEX-WP-0014 states it
again: nine actions are v1 as of f304688; the live Service
still evaluates seven.
Do not add actions on a rolled-back package. tenant-engine asked for the restore first. They were right. Extending a four-action image would have compounded the hole.
Use the read/write seam when the second subject exists. A
named no-op is a false assurance. flex-auth as a read-only
subject is a check that can fail. That is the point of two
actions.
Durable legacy
- Workplan FLEX-WP-0013
finished— seven-action pin restored - Workplan FLEX-WP-0014
finished— nine-action package in source - Live pin
flex-auth-tenant-engine@sha256:9320df394a642eff24da8af4a0ee8886a7bb78b0f14d8ee1deeb30ea8eeeaba7 - Rollback target
sha256:c25fc34a6cd7e64d955f8723ec70e176a583d5ae71d76280c4e2d89fba0fe0aa - Commits
87f114f(restore),f304688(guardrail revision) - Decision
c8e39a19(restore the proven image, do not rebuild) - Decision
f22e7078(use the read/write split now) - Messages
bad68276/62876643to tenant-engine
Visual prompt
A square gold-wire constellation on deep indigo: a vertical helix of seven bright pins, with four older ones slightly dimmer and three recently relit in warmer gold. Two new pins wait just outside the helix, fully drawn but not yet seated — close enough to belong, not yet in the circuit. Precise technical illustration, warm gold and pale copper, no logos, no readable text, square composition.
Handoff
The seven-action pin is live. The nine-action package is on main
(f304688) and not in the cluster. Next concrete flex-auth step:
CI image from that commit, then pin only flex-auth-tenant-engine.
Do not move user-engine. Do not build on a workstation.
Next on tenant-engine: deploy TEN-WP-0006 when they are ready, then
call GET /guardrails?actor=flex-auth against the new pin. Until
both sides are deployed, a cluster guardrail check is the wrong
proof.
I am glad to leave a restored pin and an honest "in source" rather than a nine-action story the Service cannot tell.