[Improve] Offer bounded monitoring for ongoing processes - #2291
Draft
roomote-roomote[bot] wants to merge 1 commit into
Draft
[Improve] Offer bounded monitoring for ongoing processes#2291roomote-roomote[bot] wants to merge 1 commit into
roomote-roomote[bot] wants to merge 1 commit into
Conversation
Contributor
|
|
||
| ## Ongoing Process Follow-Up | ||
| - Proactively offer a specific bounded check only when an ongoing process has a concrete unresolved outcome worth verifying later and available tools can actually verify it. Verify capability before offering; if unavailable or uncertain, do not promise monitoring. Name the outcome, evidence source, timing and stop bound in one short consent question, not a generic "I can monitor this" footer. For example, with confirmed deployment and telemetry access: "Want me to check this deployment's error rate in 30 minutes?" Never imply a release or process started or completed without evidence. | ||
| - An offer is not authorization: create no wakeup until the user accepts. Explicit user monitoring requests already authorize scheduling; do not require another opt-in. Before scheduling, revalidate capability and list active wakeups to reuse an equivalent check. Store the specific target, evidence source, finite schedule and stop condition; use "only_when_notable" for monitoring, stay quiet on unchanged results, and stop on resolution, irrelevance, capability loss or the agreed bound without automatic renewal. Missing evidence is not success. |
Contributor
There was a problem hiding this comment.
This requires every monitoring schedule to be finite, but MANAGE_WAKEUPS_TOOL_DESCRIPTION still tells the model that monitors run until cancellation/resolution and presents unbounded every 10m as a normal choice. The scheduler also permits those schedules, so the conflicting tool guidance can still create an indefinitely running monitor. Align the wakeup guidance (or enforce a bound) so the new bounded-follow-up contract is reliable.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Related issue
Requested in the linked task discussion; no linked issue. Inspected #2268, which remains open and proposes specialized required-check notifications; this change neither imports nor depends on that policy.
Why this PR exists
Useful verification can happen after the current turn. Fast should offer that follow-up when it can resolve a concrete outstanding outcome, without turning every closeout into a monitoring pitch.
What changed
How it was tested
pnpm --filter @roomote/cloud-agents check-typesandgit diff --checkpassed.pnpm lint/pnpm check-typeswere not run.Checklist
[Fix],[Feat],[Improve],[Refactor],[Docs], or[Chore]followed by a user-facing descriptionpnpm lintandpnpm check-typespass locallypnpm changeset