Turn the failure into a bounded work order

Once the trace points to a contract, write the repair as a bounded work order. Give the person or implementation agent the failing behaviour, expected behaviour, relevant files or modules if known, constraints, and checks that prove the change.

A good work order for a stale portal state might require:

• one failing test that reproduces the transition;
• one named state owner;
• a change confined to the state update and its consumers;
• no unrelated interface rewrite;
• retained compatibility with existing event payloads;
• an observable error path for malformed or late events;
• verification in both affected roles.

Include facts rather than a proposed patch when the cause is still uncertain. Telling an agent to "add a refresh after submission" may conceal a missing state update by making the browser poll more often. State the disagreement and ask for diagnosis with evidence first. The implementation can follow after the cause is demonstrated.

Separate defects that only happen to appear in the same journey. A permission error, a stale cache and an integration timeout may share a test account while requiring different owners and rollback plans. One large change makes review harder and allows one successful fix to mask two unresolved failures.

Before implementation, note the files or systems that are out of scope. Generated files, unrelated migrations, shared design components and production configuration should not change unless the work order names them. The boundary gives the reviewer a quick drift check.