Routine starter drafts and automatic action history
The existing Routines page offers a Template selector in the New routine form. Version 1 starters cover product/competitor watch (search, CRM list, public-page extraction, human link proof), weekly evidence/check-in review, and manual proof-backed follow-up. Selection only fills local editor state. It never saves, enables, runs, approves, or installs a scheduler. Selecting another starter replaces the unsaved draft.
All starters use manual starts. Recurring cadence, timezone and weekdays must be selected explicitly. Saving uses the canonical shared schema, including eight-step and 3,800-byte portable limits, and creates a disabled routine. Choose the actual project and people after saving, inspect the server-derived permission manifest and hash, then explicitly enable. New draft changes get a fresh server manifest; local starters contain no approval or bindings.
Automatic steps offer exactly the current supported actions:
| Action | Editable fields / existing effect |
|---|---|
ticket_note | Title/instructions; records the step on the run ticket |
web_search | Optional query (300 characters; defaults to instructions); existing public search transport |
record_list_add | Optional list (80 characters; defaults to Competitor watch); files results as CRM companies/tags |
deep_research | Title/instructions; existing executor extracts public-page text for newly added records |
summary_message | Title/instructions; summary to the run starter, with existing notification/email queue behavior |
These are deterministic existing functions, not an autonomous agent executor. Research extraction can include failed reads and requires human verification. Choosing a starter grants neither network nor CRM nor notification access. All role, person-session, project, participant, feature-flag and runtime capability checks remain server-owned.
The existing run page now reads actions from the actual GET serializer and displays step key, action identity, audit time, result, refusal/capability errors, and added-record identity. Workflow progress and action outcomes are separate. Audit prose is escaped; only explicit HTTP(S) URLs without credentials become external links with opener/referrer protection. Read-access failures replace the run view with the existing error state.
Current backend limits
routine.action currently serializes stepKey, action, result, optional refused/missing, added and at. It has no execution start/end timestamps or explicit success state. Consequently positive prose is displayed as Unknown (result recorded), never as proof of completion. Executor failure/refusal prefixes display Failed. Missing rows remain Unknown. Explicit queued/running/completed/failed states are supported if supplied, and unfamiliar future states remain Unknown with their original value.
Ticket-note steps currently produce workflow comments but no routine.action audit row, so the action panel honestly reports no separate action result. Overall workflow completion does not establish that background actions succeeded. Public-page read failures may be embedded in CRM notes while the executor still reports a research result; inspect the evidence.
The existing configuration endpoint permits an omitted manifest hash and records approval.presented=false. The UI requires and sends the displayed hash, but API-level refusal of a missing hash needs a separate backend-owner contract change. No backend was modified in this lane.
Submission guards prevent concurrent UI submissions. A run start retains its occurrence id after an ambiguous response so a retry reconciles through the server's existing idempotency seam. A successful start clears that id for a future intentional run. This does not add execution leases or change the existing background executor's retry guarantees.
Verification
Colocated web tests exercise actual editor submissions through the network boundary and escaped result rendering. Named API fixtures routine-template-journey-http.test.ts and routine-template-journey-browser.test.ts use disposable PostgreSQL workers and synthetic identities. The browser fixture runs production Next pages, real API/DB/action services, and registered MCP transport for the same run. Only external DNS/HTTPS responses are recording fixtures; no real provider calls or customer routines are used. Set ROUTINE_TEMPLATE_BROWSER=1; build with API_PROXY_TARGET=http://127.0.0.1:54871 and empty NEXT_PUBLIC_API_URL first. Ports may be overridden together with a matching build proxy target.