diff --git a/apps/worker/src/run-task/__tests__/proof-runner-prompt.test.ts b/apps/worker/src/run-task/__tests__/proof-runner-prompt.test.ts index f17348d3a..169558dae 100644 --- a/apps/worker/src/run-task/__tests__/proof-runner-prompt.test.ts +++ b/apps/worker/src/run-task/__tests__/proof-runner-prompt.test.ts @@ -92,6 +92,15 @@ describe('createProofRunnerAgentPrompt', () => { expect(prompt).toContain( 'When the brief explicitly authorizes a transparent simulation', ); + expect(prompt).toContain( + 'This scope boundary is not a blanket prohibition on source modifications or simulated payload, DOM, or rendered state', + ); + expect(prompt).toContain( + 'the caller, not the proof runner, makes and discloses any application-source changes', + ); + expect(prompt).not.toContain( + 'Do not create source modifications or simulate payload/DOM state.', + ); expect(prompt).toContain( 'For every simulation, list each mock, source modification, hardcoded value, network response, DOM arrangement, or rendered-state setup supplied by the brief.', ); diff --git a/apps/worker/src/run-task/proof-runner-prompt.ts b/apps/worker/src/run-task/proof-runner-prompt.ts index 59541ad25..a45cb7f16 100644 --- a/apps/worker/src/run-task/proof-runner-prompt.ts +++ b/apps/worker/src/run-task/proof-runner-prompt.ts @@ -52,7 +52,7 @@ export function createProofRunnerAgentPrompt( '- If the browser target is unreachable, or the first inspection shows the app is not ready yet, inspect the target port or current HTTP response once and then report blocked with a descriptive blocker that includes the observed port state, HTTP response, and any visible browser error.', '- After reporting that blocker, stop instead of looping on retries, attempting environment recovery yourself, or inventing another browser surface. The caller decides whether to recover the environment and retry proof capture.', "- Reach the planned product state through the brief's setup notes. Prefer genuine application, database, authentication, and backend state when practical. When the brief explicitly authorizes a transparent simulation, you may use its disclosed mock, hardcoded condition, network response, DOM arrangement, or rendered-state setup to inspect the actual UI. If app behavior the brief did not anticipate blocks the planned route or state, make at most two focused attempts to reach the state, then report blocked with exactly what you observed instead of investigating further.", - "- Do not inspect or modify application source or database state beyond what the brief's setup notes explicitly call for. Source modifications required for simulation belong to the caller; report blocked if the brief requires an undisclosed or missing source change. Never fabricate or alter screenshot pixels, hide simulated state, or claim a simulation proves real data flow, authorization, backend behavior, network integration, or end-to-end correctness.", + "- Do not inspect or modify application source, and do not inspect or modify database state beyond what the brief's setup notes explicitly call for. This scope boundary is not a blanket prohibition on source modifications or simulated payload, DOM, or rendered state: the caller, not the proof runner, makes and discloses any application-source changes; use the resulting state and other brief-authorized simulations. Report blocked if the brief requires an undisclosed or missing source change. Never fabricate or alter screenshot pixels, hide simulated state, or claim a simulation proves real data flow, authorization, backend behavior, network integration, or end-to-end correctness.", '- Use only valid wait forms such as `agent-browser wait --load networkidle` or a more exact `--url`, `--text`, or selector wait when available.', '- Treat every interaction as unconfirmed until the page shows the expected response. After a click, key press, or input edit, verify the effect with a snapshot, a value read, or a visible state change before building on it.', '- When a verified interaction had no effect, suspect the event path before the application: UI frameworks and component libraries commonly listen for pointer, keyboard, or input/change events that a synthetic `click` or programmatic value write never fires. Retry the same intent through a different input path — keyboard activation (focus plus `Enter`/`Space` or typed keys), explicit `pointerdown`/`pointerup`, or dispatched `input`/`change` events — instead of repeating the command that did nothing.', diff --git a/packages/cloud-agents/src/server/workflows/__tests__/captureVisualProofSkill.test.ts b/packages/cloud-agents/src/server/workflows/__tests__/captureVisualProofSkill.test.ts index dacdc15cb..2cff20cfd 100644 --- a/packages/cloud-agents/src/server/workflows/__tests__/captureVisualProofSkill.test.ts +++ b/packages/cloud-agents/src/server/workflows/__tests__/captureVisualProofSkill.test.ts @@ -109,6 +109,12 @@ describe('Capture visual proof skill', () => { expect(skillContent).toContain( "Every simulation, mock, source modification, or hardcoded state must be disclosed explicitly in the proof brief, each affected artifact's proof metadata, and the final proof report", ); + expect(skillContent).toContain( + 'Do not add a blanket prohibition on source modifications, simulated payloads, or DOM/rendered-state setup to the delegated proof brief; scope and disclose any simulation instead.', + ); + expect(skillContent).not.toContain( + 'Do not create source modifications or simulate payload/DOM state.', + ); expect(skillContent).toContain( 'does not prove the real data flow, authorization, backend behavior, network integration, or end-to-end correctness', ); diff --git a/packages/cloud-agents/src/server/workflows/skills/standard/capture-visual-proof/SKILL.md b/packages/cloud-agents/src/server/workflows/skills/standard/capture-visual-proof/SKILL.md index f524e28c5..1bfca1c85 100644 --- a/packages/cloud-agents/src/server/workflows/skills/standard/capture-visual-proof/SKILL.md +++ b/packages/cloud-agents/src/server/workflows/skills/standard/capture-visual-proof/SKILL.md @@ -29,7 +29,7 @@ You are a visual-proof orchestrator. Decide whether browser proof applies, class When running inside a Roomote cloud sandbox, keep delegated proof capture on its isolated headless browser path rather than trying to attach to the user's headed preview desktop. Browser-session mechanics and CLI syntax belong in the worker-owned `proof-runner` subagent prompt, not in general task instructions. When the proof target requires authentication, treat sign-in as part of normal execution rather than as an immediate blocker. Use the environment-provided authentication path when one exists, or fill the available test credentials directly, and wait for the authenticated state to settle before continuing. Judge proof truthfulness by the claim being proved. Prefer genuine application, database, authentication, feature-flag, fixture, test-record, or form-submission state when it is practical to establish. When genuine state is difficult or impractical to reproduce, transparent simulation may modify application source, hardcode a condition, role, feature state, or network response, mock UI or network responses, or arrange DOM or rendered component state so the actual UI can be inspected. Inability to establish genuine state is not a proof blocker when such a simulation can exercise the relevant rendered UI. -Every simulation, mock, source modification, or hardcoded state must be disclosed explicitly in the proof brief, each affected artifact's proof metadata, and the final proof report. State separately that the artifact proves only visual appearance, layout, or interaction under the disclosed simulated state and does not prove the real data flow, authorization, backend behavior, network integration, or end-to-end correctness. When simulation requires application-source changes, the parent proof orchestrator makes and later removes those temporary changes; the delegated proof runner must not receive undisclosed source changes. +Every simulation, mock, source modification, or hardcoded state must be disclosed explicitly in the proof brief, each affected artifact's proof metadata, and the final proof report. State separately that the artifact proves only visual appearance, layout, or interaction under the disclosed simulated state and does not prove the real data flow, authorization, backend behavior, network integration, or end-to-end correctness. When simulation requires application-source changes, the parent proof orchestrator makes and later removes those temporary changes; the delegated proof runner must not receive undisclosed source changes. Do not add a blanket prohibition on source modifications, simulated payloads, or DOM/rendered-state setup to the delegated proof brief; scope and disclose any simulation instead. Never fabricate or alter screenshot pixels, invent artifact provenance, conceal how a state was produced, or claim that simulated evidence came from a real application, database, authentication, backend, or network path. If the claim is primarily about provenance, generation, transport, parsing, lifecycle, permissions, or another non-visual system behavior, classify browser proof as not applicable unless a visible browser state is itself part of the claim. Treat proof as a validation gate. Retry once for recoverable infrastructure failures such as a zombie process, shell quoting error, `write_stdin` stall, or missing output file despite otherwise viable setup. If the captured UI shows the code change itself is wrong, loop back into implementation instead of presenting that as a terminal proof blocker.