[Epic] Generalize the job-apply browser engine into a general browser-task agent

[serge-ivo]

Epic: Generalize the job-apply browser engine into a general browser-task agent

The job-apply flow is the browser automation that "actually worked." Investigation (2026-08-01) confirmed the engine is already ~80% generic: runApplyLoop (lib/apply-loop.ts) is pure orchestration over ApplyDeps<J extends BrowserJobBase> (snapshot → decide → act → handoff). Only the prompt, decideAction, the finish outcomes, the entry point (/apply → JobApplyWorkflow), and the job.apply_agent runner task type are job-specific. All the hard parts — real-profile Chrome reuse, ARIA snapshot/act, captcha/stuck/needs-input handoffs, durable resumable loop — are generic.

Goal: a first-party "Web Task" agent you can point at any URL with an objective, reusing the proven engine. First-party only (no third-party creation — that's the gated epic).

Children (sequence A→D)

• Extract generic browser-task engine from the apply loop (no behavior change to apply)
• BrowserTaskWorkflow + objective-driven system prompt
• POST /v1/instances/:id/browse + browser.task runner type
• First-party "Web Task" catalog agent (runtime:"browser") wrapping the engine

Guardrails

• Human-approval on sensitive/irreversible actions (send/pay/delete/post) ON by default.
• Do NOT open this to third-party creators here — see the gated epic.
• Gated on demand: only proceed if the focus wedge (#strategy) shows real usage; this is a demand-free bet until then.

Non-goals

Third-party creation, arbitrary-domain autonomy without approval, mass-action automation (that's the trust-model epic).

Issues

• [browser] Extract the generic browser-task engine from the apply loop #70 Extract generic engine
• [browser] BrowserTaskWorkflow + objective-driven system prompt #71 BrowserTaskWorkflow + prompt
• [browser] POST /v1/instances/:id/browse + browser.task runner type #72 /browse route + browser.task type
• [browser] First-party Web Task catalog agent #73 First-party Web Task agent

Gated by #68 (focus bet).

[serge-ivo]

Status update after closing child work: #70, #71, and #72 are done. This epic should stay open only for the remaining child #73: the first-party Web Task catalog agent wrapping the generic BROWSER_TASK workflow.

[serge-ivo]

Closing: all children are done.

This epic's own last comment set the condition — "This epic should stay open only for the remaining child #73: the first-party Web Task catalog agent wrapping the generic BROWSER_TASK workflow."

• [browser] Extract the generic browser-task engine from the apply loop #70 (generic engine) — closed
• [browser] BrowserTaskWorkflow + objective-driven system prompt #71 (BrowserTaskWorkflow + objective-driven system prompt) — closed
• [browser] POST /v1/instances/:id/browse + browser.task runner type #72 (POST /v1/instances/:id/browse + browser.task) — closed
• [browser] First-party Web Task catalog agent #73 (first-party catalog agent) — closed just now, shipped as Portal Watch in 2fd8d9f + migration 0087

Verified on main: workflows/browser-task.ts, BROWSER_TASK in KNOWN_WORKFLOWS, the run_browse trigger action, and the seeded agent row all exist.

The deliberately-deferred residue has a home already: change-detection as a browse pipeline step belongs with opening the step vocabulary (#58), not here. Nothing in this epic is waiting on anything.