A feature can meet its requirements while the user’s larger workflow remains slow or confusing. The command works, but people struggle to find it, recover from a refusal or complete the next handoff.
Assay’s planned continuing-operations loop would give an enduring user journey an owner after the implementation work closes. That owner would preserve the intended effect, examine actual use and return justified improvements through the delivery process. A small manual assessment is the starting point.
Keep the user goal in view
A stream organizes finite delivery work. A user goal can persist for years. For deskpost, the command that posts agent reviews, the goal is to submit a valid review promptly and recover cleanly when posting fails.
Desk tools brief 24 improves shared audit-ledger reads used by the command’s safeguards. It preserves write limits, remembered posts and recovery while reducing repeated parsing. The posting path deliberately keeps a full-history read because it still needs to establish whether that review revision was posted before.
The continuing owner follows the whole task: prepare the review, pass the safeguards, post it, confirm the result and hand it onward. A faster safeguard is an input to that journey’s success.
Define the assessment first
Suppose the owner asks whether the ledger improvement makes review posting quicker. The expectation is a shorter complete-command duration, with duplicate prevention and failure recovery preserved.
Choose a usable comparison. Record the command version on each posting attempt, its ledger workload, elapsed stages, completion, retry and human intervention. Compare similar workloads using the earlier and changed versions. For a first manual assessment, the owner could examine 100 requested posting tasks per version and set a review date; if too few eligible attempts occur, the next action is to improve the observation window.
Exposure and use are separate facts. A package can be available without reaching a particular reviewer. An installed version can sit unused. Both must be established before its outcomes answer the question.
Keep the user workflow under review after the delivery stream closes.
The expectation, included attempts and assessment owner give the later reviewer something to examine. Without them, a favorable number can quietly change its meaning between releases.
Work through an assessment
Here is how that first assessment could proceed. Both versions handle 100 comparable requested posting tasks. Median complete-command time falls from 2.4 seconds to 1.5 seconds. Stage traces place roughly 0.9 seconds of the reduction in the safeguard. Four tasks on each version need one retry, producing 104 command executions per version. All 100 tasks complete without manual intervention or an observed duplicate post. Count requested tasks and command executions separately.
Those observations support a faster command without an observed recovery regression on this workload. The decision-equivalence and recovery checks still establish the safeguard contract; observing no duplicate in these attempts answers a different question. Command timing covers one part of the journey.
Check preparation, confirmation and handoff separately—for example, whether a successful post still needs manual confirmation—before concluding the whole review workflow improved. The owner also examines another explanation: did the changed version receive smaller ledgers or easier review tasks? If so, the apparent gain needs a matched comparison before it can support the same conclusion.
Now the traces reveal that the remaining full-history lookup takes about 1.2 seconds. That identifies a candidate for the next investigation. It does not yet select a replacement. The lookup remembers posts across old segments; its owner needs a design that preserves those answers with less work.
Change the result: if complete-command time stays at 2.4 seconds while the safeguard gets cheaper, inspect the other stages. A slower posting service or more confirmation work may have consumed the saving. Optimizing the safeguard again would address the wrong part of the journey.
Choose the next kind of work
A brief is the bounded work record carrying an outcome, scope and acceptance checks. The assessment owner records the finding, checks whether an existing brief already owns it and proposes the next scope through intake, Assay’s front door for new work.
For the remaining lookup, the proposed brief would state which remembered-post decisions must stay equal, how segments and recovery behave, what performance result matters and who accepts the change. A worker implements it, a reviewer challenges the candidate, and a non-implementer checks the merged result. The continuing owner then assesses the released version’s use again.
Other observations need different exits. An unknown installed version needs better exposure records. A rarely used command may need a longer observation window. An obsolete compatibility path may deserve retirement. Each disposition should say which question it will resolve.
Give recurring reviews a question and owner
The planned regular cadence would examine accumulated behavior between feature requests. A journey review could revisit successful posting, refusals, retries and recovery. It would use the same user goal and compare observations across known versions.
A recurring performance assessment would inspect where work now accumulates: repeated history reads, contention between writers or slow confirmation. An architecture assessment would examine ownership and temporary paths. For example, a second store for prior-post state would need a clear relationship with the authoritative ledger and a recovery strategy.
The owner chooses the cadence and the question. A repeated assessment is useful when its evidence can select a repair, retire a mechanism or settle whether further observation is worth the cost. Recording that disposition keeps the next review from restarting the same investigation.
Improve the review method
A review system should keep improving as the code, the team and the available tools change. A process that worked last month can miss a new failure pattern or spend effort on a check that adds little. Keep studying other approaches, examining your own misses and trying better ways to review. Assign that work an owner and revisit it regularly.
Claude Code’s review service offers one useful pattern: several agents examine a change, a verification step checks their candidate findings against the code, and the remaining findings are deduplicated and ranked before posting. That finding check happens during review. Assay’s independent verifier has a later job: executing the brief’s checks on merged code. An experiment could add stronger finding validation while retaining that separate post-merge examination.
The proposed specification-review refinement in Assay PR #3201 examines another weak point. Having acceptance examples does not establish that they cover every material condition. The change asks authors to map conditions to observable outcomes, separate obligations that can fail independently, and check for contradictions with inherited decisions. After a consequential edit, it calls for rereading the whole affected requirement and its criteria, including unchanged text.
For the ledger example, “the optimized reader agrees with the original” needs histories that exercise refusal, reset, ignored events and recovery. If a later decision changes what resets a refusal run, the earlier verification still describes the earlier contract. The revised obligation needs its own examination even when the test command keeps the same name.
Improving the reviewer includes improving the contract and evidence it receives.
Evaluate a proposed refinement on a fixed set of changes: known defects, clean changes and deliberately planted faults. Compare the existing review with the candidate method, then adjudicate the findings against the code and requirements. Record additional substantiated defects, missed faults, false alarms, repair time, cost and human attention. Keep some cases outside prompt tuning so the comparison tests transfer beyond the examples used to develop it.
That comparison gives the owner a decision: adopt the refinement, revise it, or retire it. Feed escaped defects and unhelpful findings back into the next improvement, and update the shared instructions so the learning reaches later reviewers.
Version the review instructions and evaluation cases so a later model or policy change can be examined again. A recurring process review can improve brief authoring, reviewer context, finding validation, CI assertions or verification instructions; another agent is one possible intervention among those choices.
Observe a consumer when discovery is uncertain
The ledger’s integration tests establish behavior in a known sequence. A fresh consumer can examine a different question: can someone find the command, prepare a valid review, understand a refusal and recover?
Give that consumer the goal and normal documentation. Observe where the task stalls and inspect the reason. An incorrect recovery instruction suggests a documentation repair; a safeguard that rejects the required valid action suggests an implementation or contract problem. A smooth task with no uncovered issue is a useful result too.
We tried a heavier dedicated broader-review and agent user acceptance testing pilot. One local review pair took longer without producing an additional finding; its consumer exercise confirmed a known repair already caught by regression checks. We closed that dedicated pilot and kept two smaller practices: targeted caller inspection and a short consumer journey when uncertainty warrants it.
For an engineering lead, begin with one journey and one assessment owner. Preserve the expected effect, observe versioned use, explain the result and choose the next disposition. That makes the proposed self-healing loop a sequence of accountable decisions.