coulomb/tenant-engine
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Finish TEN-WP-0010: mutable grouping, contract corrected, handoffs sent

Browse source 
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-17 22:53:10 +02:00
parent 2e1c4e15e6
commit bdf9f5f643
4 changed files with 108 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

37
workplans/TEN-WP-0010-mutable-grouping.md
View file

@ -4,7 +4,7 @@ type: workplan
title: "Make tenant grouping mutable and the identifier segment historical"
domain: infotech
repo: tenant-engine
status: ready
status: finished
owner: claude
topic_slug: tenant-guardrails
created: "2026-08-17"
@ -302,7 +302,7 @@ backend to diverge on.
```task
id: TEN-WP-0010-T05
status: todo
status: done
priority: medium
state_hub_task_id: "072cddc6-762a-4efc-8176-31176b9fded6"
```
@ -317,6 +317,39 @@ as part of this workplan.
Done when the contract is documented and the notes are sent.
Done 2026-08-17.
**Documentation.** `docs/tenant-lifecycle-api.md` gains a reclassification
section — and a **correction**, because its Immutability section asserted
`grouping` was immutable, which this workplan made false. Correcting a
statement a consumer built against matters more than adding the new one.
`docs/tenant-guardrail-policy.md` gains the consequence: a ceiling can now move
with no guardrail write against it, and where the audit record lives.
**Handoffs sent.**
| To | Ask |
| --- | --- |
| `flex-auth` | add `tenant.grouping.set` (nine actions → ten) |
| `adaptive-pricing` | grouping now moves; eligibility keyed on it has a transition to handle |
| `user-engine` | contract correction, plus the new route for the operator UI |
Each carried the point most likely to bite that specific consumer rather than
the same text three times. For `user-engine` that is the identifier/field
divergence appearing in a **template** — our survey greps source confidently
and templates much less so. For `adaptive-pricing` it is that a
reclassification is a commercial event on their side even though it happened on
ours, plus the standing offer on the plan-derived guardrail layer, which exists
in the resolver and still has no feed. For `flex-auth` it is why this is not
`tenant.update`: a subject permitted to rename must not thereby be permitted to
raise a spend ceiling by two orders of magnitude.
Also told `adaptive-pricing` that the non-`trial` ceiling values remain
unsigned-off, since a tier making claims that map to those numbers would
otherwise inherit our provisional openers as though they were ratified.
Not deployed, per the task.
## Out of scope
- **Renaming tenants.** Not now, not as a fallback. The identifier stays