Turn the failure into a bounded work order

Once the trace points at a specific contract, I'd write the repair up as a bounded work order. The person or implementation agent gets the failing behaviour, the expected behaviour, the relevant files or modules if you know them, any constraints, and the checks that prove the change works.

For a stale portal state, a good work order might ask for:

• one failing test that reproduces the transition
• one named owner for the state
• a change limited to the state update and whatever consumes it
• no unrelated interface rewrite
• compatibility with existing event payloads
• an error path you can see for malformed or late events
• verification in both affected roles

If you're still unsure of the cause, give facts and leave out the proposed patch. Telling an agent to "add a refresh after submission" can hide a missing state update by having the browser poll more often. Describe the disagreement and ask for a diagnosis with evidence first. The implementation can come once the cause has been shown.

Split up defects that just happen to turn up in the same journey. A permission error, a stale cache and an integration timeout might all appear on the same test account and still need different owners and different rollback plans. One big change is harder to review, and one fix that works can cover up two failures that haven't been dealt with.

Before anyone starts, list the files and systems that are out of scope. Generated files, unrelated migrations, shared design components and production configuration shouldn't change unless the work order names them. That gives the reviewer a quick way to spot drift.