I0204 — Apply one derived limit for real and prove it changes what happens
Implement the first adapter: one limit, derived from the profile through the resolver, applied where a provider can honestly apply it, with a behavioural case that fails if the limit stops being applied.
BLOCKED wave 3 · p1 · debugging profile · runs alone
Part of runtime-adapters — Profiles become runtime constraints rather than advice.
Blocked. This issue cannot start until I0203 is done. The status is derived from that, not declared.
Objective
Implement the first adapter: one limit, derived from the profile through the resolver, applied where a provider can honestly apply it, with a behavioural case that fails if the limit stops being applied.
Why
The milestone's whole distinction is between a limit that is printed and a limit that is applied. One limit that genuinely bites is worth more than a full set that is advisory, and it is the only thing that makes the claim publishable.
Current state
The mapping exists, the resolver prints the numbers, and the opt-in exists. Nothing anywhere applies a value to anything.
Desired state
With enforcement on, one provider's execution is constrained by a value derived from the active profile, and turning the profile from one value to another changes the observed outcome.
Scope
- lib
- share
- test/cases
Out of scope
- A second provider; one honest adapter first
- Any provider knob whose effect cannot be observed from a test in this repository
Dependencies
What waits on this
Acceptance criteria
- The applied value comes from the resolver, and no constant appears in the adapter
- A case changes only the profile and observes a different outcome
- A case with enforcement off observes the unconstrained outcome
- Removing the application makes a case fail rather than a document go stale
Validation
- bash test/run.sh
Evidence required
- suite
- profile_changes_outcome
Evidence
None recorded. Every token above needs a command or an artifact behind it before this issue can be completed; narrative is refused.
Risk
The only honest adapters are for knobs a provider exposes and documents; if the chosen knob turns out to be advisory on the provider's side, the issue closes as no_match rather than shipping a clamp that does not clamp.
Timeline
- started
- —
- verified
- —
- completed
- —
Those three fields, the evidence above and the state of the dependencies are all the status is made of. There is no status field to disagree with them.
Canonical record: .ai/repo/project/issues/I0204.yaml. Read it back with majordomus plan show I0204.