Start with work you know.

Build campaign naming checker as a working business app in this Continual project.

## Objective and users
Build a campaign naming tool for ad operations managers who need consistent reporting across accounts.

## App screens and workflow
Provide a naming-rule editor, a campaign table filtered by account and violation, and a review queue showing original and proposed names. Let users mark exceptions and export approved fixes.

## Suggested connectors
Google Ads, LinkedIn Ads, Reddit Ads, Google Sheets. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Accounts own campaigns; rule sets define required tokens, separators and allowed values. Findings reference a campaign, rule version, suggested name, reviewer and resolution. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Run checks on demand and each morning. Update existing findings rather than opening duplicates; show last successful refresh and inaccessible accounts. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Never rename automatically. Apply approved renames only where the connected tool supports them; otherwise provide an export. Preserve provider campaign IDs. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A valid name passes, an invalid name gets an explainable fix, an exception stays recorded, and a second scan does not duplicate findings. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build ad spend dashboard as a working business app in this Continual project.

## Objective and users
Build a daily performance dashboard for a performance marketer managing several ad channels.

## App screens and workflow
Include date and account filters, spend trends, campaign drilldowns and a comparison with the previous period. Show conversion definitions alongside each metric and allow report export.

## Suggested connectors
Google Ads, LinkedIn Ads, Reddit Ads, Meta Ads, OpenAI Ads, Supermetrics. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Accounts have currency and time zone; campaigns belong to accounts; dated metric snapshots include source, reporting window, spend, clicks, impressions and separately labeled conversion measures. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Refresh daily and support manual refresh. Replace matching reporting windows to capture late attribution; expose stale data and partial failures. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Start read-only. Do not add unlike currencies or conversion types together. Ask for a reporting currency and conversion mapping before presenting normalized totals. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
Account totals reconcile with a provider report for the same dates; missing data is distinct from zero; mixed currencies and attribution windows remain explicit. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build campaign pacing monitor as a working business app in this Continual project.

## Objective and users
Build a pacing app for media buyers responsible for delivering campaign flight budgets.

## App screens and workflow
Let users set campaign dates, total budgets and pacing thresholds. Show actual versus expected spend, projected end-of-flight spend and a queue of exceptions with owners and notes.

## Suggested connectors
Google Ads, LinkedIn Ads, Reddit Ads, Google Sheets. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Campaign plans reference provider campaigns and include dates, budget, currency and pacing schedule. Daily spend observations feed exceptions with status, owner and acknowledged time. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Refresh each morning; evaluate only active flights. Notify on a new threshold breach or material worsening, and close resolved exceptions without repeated alerts. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Keep budget changes as proposals. Respect provider time zones, reporting delays, paused days and custom pacing schedules; ask for missing flight budgets. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A sample flight demonstrates under, on and over pace; acknowledged alerts do not repeat unchanged; missing reports cannot produce false zero-spend alarms. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build creative review queue as a working business app in this Continual project.

## Objective and users
Build a creative review app for marketers, designers and client reviewers.

## App screens and workflow
Provide a campaign board, asset preview with version history, channel specification checklist and an approval queue. Separate feedback from final approval and show blockers before a creative is ready.

## Suggested connectors
Google Drive, Dropbox, Google Sheets. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Campaigns contain creative assets and versions. Each version has target channels, requirements, review comments and approval decisions tied to reviewers. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Notify assigned reviewers when a version is submitted and remind owners about overdue reviews. A replacement asset invalidates approvals for the old version. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Publishing is outside this workflow unless a verified connector supports it and the user explicitly approves. Do not promise LinkedIn or Reddit creative creation. Keep client assets private. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A new version requires fresh approval, unresolved blocking feedback prevents readiness, and reviewers can identify exactly which version they approved. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build client campaign reports as a working business app in this Continual project.

## Objective and users
Build a reporting workspace for an agency account manager serving multiple clients.

## App screens and workflow
Configure client account mappings, reporting periods and goals. Generate a draft report with spend, delivery, changes, evidence-linked commentary and next steps. Let managers edit, approve and export or send it.

## Suggested connectors
Google Ads, LinkedIn Ads, Reddit Ads, Google Sheets, Gmail. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Clients own account mappings and report configurations. Reports store period, metric snapshots, narrative, proposed actions, approval and delivery history. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Prepare a new draft weekly after data refresh. Flag incomplete accounts and keep already-approved reports versioned when late data changes. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Require review before external sending. Separate each client’s records and recipients. Distinguish measured changes from hypotheses about their causes. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
Two clients receive separate drafts with reconciled figures; incomplete data is flagged; sending the same approved report twice is prevented. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build budget reallocation planner as a working business app in this Continual project.

## Objective and users
Build a planning and approval app for a growth lead reallocating a fixed advertising budget.

## App screens and workflow
Collect goals, minimum commitments and maximum changes. Compare recent performance on compatible metrics, propose transfers, and show before-and-after budgets with rationale and uncertainty.

## Suggested connectors
Google Ads, LinkedIn Ads, Reddit Ads, Meta Ads. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Budget plans contain campaign allocations, constraints and dated evidence. Proposals contain paired changes, reviewer decisions and per-provider execution outcomes. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Prepare proposals weekly. Before an approved change runs, re-read current budgets and invalidate stale proposals. Track partial completion without replaying uncertain writes. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Never change spend without explicit approval and supported management tools. Maintain total budget and currency constraints. Treat forecasts as estimates, not guaranteed returns. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
Proposals balance, respect constraints and reject stale approvals; a simulated partial provider failure shows the actual result and a manual recovery path. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build insertion order reconciliation as a working business app in this Continual project.

## Objective and users
Build a reconciliation workspace for agency operations staff responsible for insertion orders.

## App screens and workflow
Import orders and delivery reports, review extracted line items, map them to campaigns, and compare spend or impressions against contract terms. Manage disputed and accepted variances with supporting evidence.

## Suggested connectors
Google Drive, Dropbox, Google Sheets, Supermetrics. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Orders contain contract versions, line items, dates, units and tolerances. Mappings connect line items to campaign reports. Reconciliation runs create variance cases and resolution records. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Refresh delivery on a schedule and reconcile open orders. Recompute affected cases when a mapping or contract changes while retaining previous results. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Ask a user to confirm extracted terms and ambiguous mappings. Do not equate media cost with billed amounts or mix measurement units. Keep credits and billing adjustments as proposals. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A known variance is detected at the configured tolerance, unmapped delivery is visible, and a contract revision remains traceable to its reconciliation results. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build agency campaign operations as a working business app in this Continual project.

## Objective and users
Build a shared operations app for an agency’s account managers, media buyers and creative reviewers.

## App screens and workflow
Offer a client portfolio, campaign workspace, launch checklist, creative review queue, pacing view and reporting calendar. Assign each blocker and exception to an owner; show what needs attention today.

## Suggested connectors
Google Ads, LinkedIn Ads, Reddit Ads, Google Drive, Gmail. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Clients contain campaigns, account mappings and team access. Campaigns link plans, assets, approvals, deadlines, metric snapshots, exception cases and reports. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Refresh campaign delivery daily, create pacing exceptions and prepare scheduled report drafts. Notify owners when dependencies block a launch or a deadline becomes overdue. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Build one client and one channel end to end first. Enforce client record access on the backend. Require explicit approval for publishing, external reports and budget changes. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A team can take a sample campaign from brief through review to delivery reporting; blocked launches remain blocked and one client cannot read another’s data. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build meeting notes library as a working business app in this Continual project.

## Objective and users
Build a searchable meeting library for a team that wants to recover what was discussed and why.

## App screens and workflow
Provide a meeting list with date, participant and topic filters, plus a detail page with summary, key topics and transcript references. Allow manual transcript import for a first preview.

## Suggested connectors
Google Meet, Fireflies, Read AI. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Meetings store provider ID, date, title and participants. Transcript versions contain source references; summaries and topic tags reference the version used. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Import available transcripts on supported events or scheduled retrieval. Read AI supplies new-meeting webhook events rather than historical search tools. Google Meet requires transcription and eligible meeting access. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Preserve meeting access boundaries; do not publish summaries publicly. Show unavailable or incomplete transcripts and label uncertain speaker attribution. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A user can find a meeting by topic and follow a summary claim back to transcript evidence; repeated delivery of the same meeting does not duplicate it. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build meeting action tracker as a working business app in this Continual project.

## Objective and users
Build a follow-through app for team leads who lose track of commitments after meetings.

## App screens and workflow
Show extracted action candidates beside supporting transcript passages. Let users confirm the action, owner and date, then track progress in a board and optionally link an external task.

## Suggested connectors
Google Meet, Fireflies, Read AI, Linear, Asana. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Meetings contain action candidates with evidence. Confirmed actions have owners, due dates, status and optional external task IDs. Keep review and status-change history. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Process new available transcripts and remind owners about confirmed overdue actions. Reuse external task mappings and avoid duplicates on event retries. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Do not invent an owner or deadline when absent. Require confirmation before assigning or creating external tasks. Support Read AI event ingestion and manual imports when retrieval is unavailable. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
An ambiguous commitment stays in review; a confirmed action appears once in the selected task system; completing it resolves the local reminder. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build meeting prep briefs as a working business app in this Continual project.

## Objective and users
Build a meeting preparation workspace for account managers with many customer conversations.

## App screens and workflow
List upcoming meetings and generate a brief containing attendees, account context, recent discussions, open commitments and suggested agenda items. Let users correct the account match and annotate the brief.

## Suggested connectors
Google Calendar, Gmail, HubSpot, Salesforce, Google Meet. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Calendar meetings link attendees to contacts and accounts through reviewed mappings. Briefs store evidence references, generation time, agenda items and user notes. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Prepare briefs before upcoming meetings and refresh when meeting details change. Avoid processing cancelled events and show which connected sources could not be checked. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Do not assume people with similar names belong to the same account. Restrict access to the underlying account and meeting; do not send briefs to attendees automatically. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A rescheduled meeting keeps its notes, an ambiguous contact needs review, and every factual account claim has a retrievable source. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build sales call follow-up as a working business app in this Continual project.

## Objective and users
Build a post-call review app for sales representatives and managers.

## App screens and workflow
Associate each available transcript with an account and opportunity, summarize needs and objections, draft a customer email, and display proposed CRM changes beside current values.

## Suggested connectors
Google Meet, Fireflies, Read AI, HubSpot, Salesforce, Gmail. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Calls link to contacts and opportunities. Follow-up drafts, action items and field-change proposals reference transcript evidence and store review and execution status. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Create a review package when a transcript arrives and remind the rep about unreviewed calls. Record provider IDs so retries do not duplicate notes or email. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Confirm the opportunity match and require approval before sending or updating CRM. Do not infer deal amount, stage or commitment from weak evidence; flag uncertainty. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A rep can edit and approve a follow-up; rejected field changes never reach CRM; an execution retry cannot send the email twice. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build customer interview insights as a working business app in this Continual project.

## Objective and users
Build a research repository for product managers analyzing customer interviews.

## App screens and workflow
Import transcripts, tag interview context, extract evidence-backed observations and group them into editable themes. Let users inspect contradictory evidence and compare themes across customer segments.

## Suggested connectors
Fireflies, Google Meet, Read AI, Notion, Google Drive. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Interviews link participants and consent/access notes. Observations reference transcript passages; themes group observations; research decisions record rationale and unresolved questions. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Process new interviews and suggest matches to existing themes. Keep suggestions separate from reviewed themes and retain changes when an interview is reprocessed. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
An observation is not a validated market fact. Avoid counting repeated comments from the same participant as independent demand, and do not expose private quotes to unauthorized users. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A theme shows its contributing interviews and counterexamples; users can split a mistaken cluster without losing evidence or reviewed labels. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build decision register as a working business app in this Continual project.

## Objective and users
Build a decision log for project leads coordinating work over many meetings.

## App screens and workflow
Review candidate decisions extracted from meetings, confirm their status and owner, and browse a timeline of rationale and related questions. Suggest links when later discussions revisit a decision.

## Suggested connectors
Google Meet, Fireflies, Read AI, Notion. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Decisions include topic, owner, status and effective date. Evidence references meetings; relationships connect superseding decisions; open questions have owners and resolution notes. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Process new transcripts and flag possible contradictions or revisited decisions for review. Never silently overwrite an approved decision with a newer summary. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Distinguish a suggestion, an agreement and a final decision. Require a reviewer to confirm supersession and preserve historical versions. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A later reversal links to the original decision, an unresolved discussion stays a question, and users can reconstruct which decision applied at a given time. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build client commitments tracker as a working business app in this Continual project.

## Objective and users
Build a commitments workspace for client delivery leaders who need to reconcile promises across sales and delivery.

## App screens and workflow
Collect candidate promises from available calls and selected email threads. Review account and deliverable matches, confirm owners and dates, then show account timelines, overdue commitments and conflicting promises.

## Suggested connectors
Google Meet, Fireflies, Gmail, HubSpot, Salesforce, Asana. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Accounts own commitments linked to source messages, meetings and delivery tasks. Commitments record scope, owner, due date, status, dependencies and amendments. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Process new evidence and check confirmed commitments daily. Raise a case when a new promise conflicts with existing scope or a dependency threatens a due date. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Have a person validate commitments before treating them as contractual obligations. Require approval for customer messages and external task updates; preserve evidence access. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
Two mentions of one promise merge after review, a changed deadline retains history, and an overdue commitment routes to its accountable owner. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build target account research as a working business app in this Continual project.

## Objective and users
Build an account research app for sales representatives preparing targeted business conversations.

## App screens and workflow
Import target companies, review company matches, and prepare briefs with business context, relevant news, buying signals and suggested talking points. Show sources and research dates.

## Suggested connectors
Apollo, ZoomInfo, HubSpot, Salesforce, Web search. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Accounts have domains and external IDs. Research observations store source URL, observed date, confidence and topic. Briefs reference observations and assigned representatives. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Research new accounts on demand and flag old briefs for refresh. Record failed lookups without fabricating missing facts. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Use authorized business data and distinguish observed events from inferred intent. Do not infer private website activity from public research or automatically launch outreach. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A rep can verify a claim at its source, correct a company mismatch and see which information is stale or unavailable. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build stale deal follow-up as a working business app in this Continual project.

## Objective and users
Build a pipeline follow-up workspace for sales managers and opportunity owners.

## App screens and workflow
Configure inactivity thresholds by stage, show deals with missing next steps, and draft follow-ups using the last known conversation. Let owners snooze, dismiss or approve an action.

## Suggested connectors
HubSpot, Salesforce, Gmail. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Opportunities reference accounts and owners. Activity snapshots track meaningful touches; follow-up cases include reason, suggested next step, snooze date and disposition. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Refresh CRM activity daily and create one active case per deal. Close or update cases when a meaningful touch arrives; do not treat automated system updates as customer engagement. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Keep emails as drafts until approved. Exclude closed deals and respect owner snoozes. Do not change opportunity stages automatically. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A genuinely inactive deal is flagged, a recently contacted deal is excluded, and snoozed cases remain quiet until their review date. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build lead intake and routing as a working business app in this Continual project.

## Objective and users
Build an inbound lead desk for revenue operations and sales representatives.

## App screens and workflow
Collect leads from connected forms or manual imports, deduplicate them, review enrichment and route them by territory, company size or existing account ownership. Show unassigned and overdue leads.

## Suggested connectors
HubSpot, Salesforce, Apollo, Gmail. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Leads store source IDs, contact details, company match and intake time. Versioned routing rules assign an owner; assignments and response events form an auditable history. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Process supported intake events or poll on a schedule. Reconcile duplicate deliveries and escalate leads that miss the configured response deadline. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Ask for routing rules and available owners. Missing enrichment should enter a fallback queue rather than guessing. Confirm CRM write permissions before enabling assignments. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A duplicate form event creates one lead, an existing customer reaches its owner, and an unmatched territory remains visible for manual routing. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build weekly growth review as a working business app in this Continual project.

## Objective and users
Build a weekly review app for a growth lead and company leadership.

## App screens and workflow
Define funnel stages and metrics, display current and previous periods, and prepare a narrative of notable changes with supporting charts. Record decisions and carry unfinished actions into the next review.

## Suggested connectors
PostHog, Google Analytics, HubSpot, Salesforce, Stripe, Google Ads. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Metric definitions specify source, unit and calculation. Weekly snapshots store freshness and coverage; reviews link commentary, decisions and actions to those snapshots. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Prepare a draft at a chosen weekly cutoff and refresh incomplete sources when available. Preserve approved review versions rather than silently replacing their figures. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Clarify definitions such as signup, activated account and revenue. Separate measured changes from causal hypotheses and avoid summing incompatible provider metrics. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A review reconciles to underlying source reports, missing sources are explicit, and an unresolved action carries forward without duplication. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build trial activation tracker as a working business app in this Continual project.

## Objective and users
Build a trial activation workspace for lifecycle marketing and customer success.

## App screens and workflow
Define activation milestones, display each trial’s progress and classify blockers using available evidence. Offer a review queue of personalized outreach and track whether the account subsequently progresses.

## Suggested connectors
PostHog, HubSpot, Salesforce, Gmail. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Trial accounts map CRM and analytics identifiers. Milestone definitions evaluate observed events; interventions include reason, proposed message, approval, send status and outcome window. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Recompute progress daily using a configured event-lag allowance. Suggest help after inactivity thresholds and stop interventions when a trial activates, expires or opts out. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Require a verified identity mapping and approval before sending. Respect contact preferences and cooldowns; missing telemetry is not proof of inactivity. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
An activated trial exits the queue, an unmapped account is flagged, and the same stalled milestone does not trigger repeated messages. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build campaign-to-revenue explorer as a working business app in this Continual project.

## Objective and users
Build an attribution exploration app for growth and revenue operations teams.

## App screens and workflow
Configure source-to-contact-to-opportunity mappings and a stated attribution model. Show campaign spend, matched pipeline and revenue, with drilldowns to source records and a queue for unmatched identities.

## Suggested connectors
Google Ads, LinkedIn Ads, Reddit Ads, HubSpot, Salesforce, Stripe, PostHog. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Campaigns, touches, contacts, accounts, opportunities and billing records retain provider IDs. Attribution runs store model version, matching evidence, allocations and unmatched reasons. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Refresh daily and recompute affected windows when late conversions or corrected mappings arrive. Keep model versions so users can compare results. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Do not promise complete attribution. Report coverage and unknown revenue separately, prevent double-counting shared opportunities, and distinguish booked revenue from cash collected. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A traced opportunity shows its mapping path; unmatched revenue remains visible; allocations reconcile under the selected model and currency policy. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build content calendar as a working business app in this Continual project.

## Objective and users
Build an editorial planning app for a marketing team managing recurring content.

## App screens and workflow
Provide calendar and board views, an editable brief, asset links, owners, deadlines and review status. Let users reschedule work and see overdue items.

## Suggested connectors
Notion, Google Drive, WordPress. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Content items have format, audience, channel, owner and target date. Brief versions, asset references, review comments and status transitions belong to each item. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Remind owners about upcoming and overdue deadlines. Keep external publishing optional; the initial app should work with manually entered briefs and links. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
A review state must be explicit. A scheduled date does not itself authorize publication; revised content requires renewed approval. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A team can create a brief, assign it, review it and move its date without losing history; overdue work is easy to find. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build transcript-to-content studio as a working business app in this Continual project.

## Objective and users
Build a repurposing studio for marketers turning webinars and interviews into content.

## App screens and workflow
Import an authorized transcript, select audience and formats, then generate article, newsletter or social drafts. Display evidence beside claims and allow editorial review of each version.

## Suggested connectors
Google Drive, Fireflies, Google Meet, Read AI, WordPress, Mailchimp. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Sources store transcript versions and usage permissions. Content projects contain briefs and derivative drafts with source references, channel, revision and approval state. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Generate drafts on request or from approved incoming sources. Notify editors when drafts need review; do not publish on transcript arrival. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Check permission to reuse private interviews. Do not invent quotes. Keep publication a separate approved action supported by the selected connector. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
Editors can trace factual claims to the source, revise one channel draft independently and prevent an unapproved version from publishing. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build content refresh queue as a working business app in this Continual project.

## Objective and users
Build a content maintenance app for an editor responsible for a growing website.

## App screens and workflow
Inventory pages, combine performance trends with editorial review dates, and prioritize refresh candidates. Show the current page beside a proposed revision and track approval and publication.

## Suggested connectors
WordPress, Google Analytics, PostHog, Google Drive. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Pages retain canonical URL and provider ID. Metric windows, review rules, refresh cases and revision proposals connect evidence to each suggested change. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Scan weekly, flag stale content or sustained performance changes, and refresh case evidence without opening duplicate tasks. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Performance decline alone is not proof of a content problem. Check seasonality and tracking gaps; require approval before replacing live copy and retain the previous version. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A page with missing analytics is not labeled as zero traffic; a proposed update has evidence, and an approved change records its published version. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build campaign launch checklist as a working business app in this Continual project.

## Objective and users
Build a launch coordination app for campaign managers working across marketing teams.

## App screens and workflow
Create reusable checklists for content, landing pages, tracking, creative and approvals. Show owners, dependencies, deadlines and a readiness view with evidence for completed checks.

## Suggested connectors
Google Drive, Asana, Google Analytics, WordPress. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Campaigns instantiate checklist templates. Tasks include dependencies, owners, evidence and completion state; approvals reference the asset or configuration version reviewed. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Remind owners as deadlines approach and flag newly blocked launches. Reopen affected checks when a dependency or reviewed asset changes. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
A green checklist is not permission to activate ads or publish. Mark unverifiable tracking checks as unknown and require an accountable launch decision. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
An unmet prerequisite blocks readiness, replacing an asset invalidates its approval, and each completed check shows supporting evidence. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build marketing experiment tracker as a working business app in this Continual project.

## Objective and users
Build an experiment register for a marketing team learning across campaigns and landing pages.

## App screens and workflow
Capture hypothesis, audience, variants, primary metric, guardrails and evaluation window before launch. Display source-linked results and record whether to adopt, stop or continue.

## Suggested connectors
PostHog, Google Analytics, Google Sheets. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Experiments contain a versioned plan, variant definitions and metric references. Result snapshots record sample coverage; decisions capture reviewer rationale and follow-up actions. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Refresh results on a schedule and notify the owner when the planned review date arrives or a guardrail is breached. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Do not declare a winner from small samples or repeated peeking. Distinguish observational comparisons from randomized experiments and use provider statistical outputs where available. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A completed experiment retains its original plan, missing measurements are explicit, and the decision links to a dated result snapshot. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build client document checklist as a working business app in this Continual project.

## Objective and users
Build a document collection tracker for client service coordinators.

## App screens and workflow
Define required documents for each client, link received files and review completeness. Show missing, received, rejected and accepted states and prepare a reminder listing only outstanding items.

## Suggested connectors
Google Drive, Dropbox, Gmail. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Clients have document requirements with due dates and reviewers. Submissions link files and versions; review decisions and reminder drafts form the collection history. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Check due dates daily and prepare reminders for overdue requirements. Allow manual linking of files when connector discovery is unavailable. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Do not treat any uploaded file as satisfying a requirement without review. Keep client documents private and require approval before reminders are sent. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A rejected document stays outstanding, an accepted replacement closes the requirement, and one client’s reminder cannot include another client’s files. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build client onboarding workspace as a working business app in this Continual project.

## Objective and users
Build an onboarding app for customer success managers taking over newly closed accounts.

## App screens and workflow
Review the sales handoff, create a checklist from an onboarding template, assign milestone owners and collect required documents. Provide an internal portfolio and a client-specific progress view if requested.

## Suggested connectors
HubSpot, Salesforce, Google Drive, Docusign, Asana, Gmail. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Accounts own onboarding cases. Cases contain sales commitments, milestone dependencies, document requirements, assigned owners and status history. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Create a proposed case from a supported closed-won event or scheduled CRM check. Remind owners about blocked or overdue milestones and draft progress updates. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Confirm the handoff before provisioning work. External client views require record-level access isolation. Do not infer completed signatures or promises from an email summary alone. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A duplicate closed-won event produces one case; blocked milestones are visible; a client can access only its own approved progress information. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build support escalation desk as a working business app in this Continual project.

## Objective and users
Build an escalation workspace for support leads handling issues that span several teams.

## App screens and workflow
Link related tickets to an escalation case, show account context and engineering issues, assign an incident owner and maintain next update times and customer communication drafts.

## Suggested connectors
Zendesk, Intercom, HubSpot, Salesforce, Linear, Jira. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Cases reference tickets, accounts and engineering issues. Severity, ownership, commitments, evidence and timeline events record the resolution process. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Ingest supported ticket events or poll for updates. Flag missed commitments and refresh linked engineering status without duplicating timeline entries. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Have a person confirm severity and external updates. Internal notes and customer-visible messages need separate visibility; a closed engineering issue does not automatically prove customer resolution. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
Multiple reports can join one case, a missed update deadline is escalated, and resolution requires a recorded customer outcome. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build renewal preparation as a working business app in this Continual project.

## Objective and users
Build a renewal preparation app for customer success and account managers.

## App screens and workflow
Show upcoming renewals, assemble briefs from usage, account history, support issues and commitments, and maintain a plan with owners, risks and next steps.

## Suggested connectors
HubSpot, Salesforce, PostHog, Zendesk, Intercom, Gmail. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Accounts link renewal opportunities and contract dates. Brief snapshots collect source evidence; risk assessments, actions and owner reviews reference the relevant renewal. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Prepare briefs at configurable intervals before renewal and refresh material changes. Alert owners to new unresolved blockers without repeatedly notifying unchanged risks. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Treat risk scores as explainable suggestions. Missing usage is unknown, not churn intent. Do not send offers, change pricing or update renewal terms automatically. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A manager can inspect the evidence behind a risk, correct a renewal date and track an action to resolution without losing earlier assessments. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build scope change tracker as a working business app in this Continual project.

## Objective and users
Build a scope review app for professional services project managers.

## App screens and workflow
Record the approved scope and deliverables, capture incoming requests and compare them with relevant contract passages. Route potential changes for effort, price and schedule review before client approval.

## Suggested connectors
Gmail, Google Drive, Dropbox, Docusign, Asana. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Engagements have versioned scope baselines. Requests reference source messages and affected deliverables; change proposals contain estimates, approvals and effective revisions. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Collect requests from selected inboxes or manual intake and remind reviewers about pending proposals. Update dependent delivery plans only after an approved change. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Classifications are suggestions, not legal conclusions. Require a person to confirm contract interpretation, commercial terms and customer communications. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A request can be accepted within scope or become a change proposal; the approved baseline changes only with a recorded decision and revision. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build invoice follow-up desk as a working business app in this Continual project.

## Objective and users
Build a receivables follow-up app for account managers and finance staff.

## App screens and workflow
Show overdue invoices by customer with aging, disputed amounts and recent contact. Prepare a reminder, record payment promises, and let owners pause follow-up while resolving a dispute.

## Suggested connectors
QuickBooks, Xero Accounting, Stripe, Gmail. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Customers map to provider invoices and payments. Follow-up cases include owner, promise date, dispute status, message drafts and delivery history. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Refresh invoice balances daily and prepare reminders according to an agreed cadence. Recheck balance immediately before an approved send and stop follow-up on paid invoices. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Require approval for external reminders. Do not collect payments, apply credits or alter accounting records. Preserve currencies and distinguish partial payments from fully paid balances. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A partial payment updates the balance, a paid invoice cannot receive a stale reminder, and a disputed invoice follows its configured hold. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build missing receipt tracker as a working business app in this Continual project.

## Objective and users
Build a receipt collection app for finance operations and expense owners.

## App screens and workflow
List expenses requiring receipts, suggest matches using merchant, date and amount, and let reviewers accept or reject documents. Show missing information by employee and prepare follow-up requests.

## Suggested connectors
Brex, Ramp, Google Drive, Gmail. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Expenses retain provider IDs, currency and owner. Receipt references store extracted fields; match candidates and review decisions link documents to expenses. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Refresh expenses daily and re-evaluate unmatched receipts. Prepare reminders after a configurable grace period and avoid repeated requests for accepted documentation. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Confirm ambiguous matches and avoid exposing one employee’s expenses to another. Do not infer policy compliance from a receipt match or automatically modify expense records. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
Two similar purchases remain distinguishable, an accepted receipt resolves the missing-document case, and rejected matches remain in the review history. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build month-end close checklist as a working business app in this Continual project.

## Objective and users
Build a monthly close coordination app for a finance team.

## App screens and workflow
Create period checklists from templates, assign preparers and reviewers, attach supporting reports and surface unresolved exceptions. Show dependency blockers and sign-off progress.

## Suggested connectors
QuickBooks, Xero Accounting, Google Sheets, Google Drive. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Close periods contain task instances, dependencies, evidence versions and review decisions. Exceptions link affected tasks with owners and resolution notes. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Create each period’s checklist on schedule and remind owners about approaching deadlines. Carry unresolved exceptions forward explicitly rather than copying completion states. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
This app coordinates work; it must not post journals or certify accounts. A replacement evidence file requires re-review where a sign-off depends on it. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A new month starts with incomplete tasks, dependent tasks remain blocked as configured, and every sign-off identifies its reviewer and supporting evidence. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build vendor renewal calendar as a working business app in this Continual project.

## Objective and users
Build a vendor agreement tracker for operations and finance managers.

## App screens and workflow
Import agreements, review extracted renewal dates and notice periods, and show a calendar of upcoming decisions. Assign a business owner and maintain keep, renegotiate or cancel plans.

## Suggested connectors
Google Drive, Dropbox, Gmail, Google Sheets. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Vendors have agreement versions, currency, term dates and verified notice rules. Renewal reviews include owner, decision deadline, actions and evidence. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Calculate review dates from verified contract terms and notify owners before notice windows close. Recompute deadlines when a confirmed amendment changes the term. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Have a person verify extracted terms, business-day rules and time zones. Never cancel or renew a contract automatically or treat a draft decision as executed notice. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A known notice deadline calculates correctly, an ambiguous clause requires review, and a revised agreement preserves the old deadline and decision history. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build invoice dispute workspace as a working business app in this Continual project.

## Objective and users
Build a dispute case app for finance and account managers investigating contested invoices.

## App screens and workflow
Open a case against an invoice, collect the customer’s stated issue, link contract and delivery evidence, and prepare a resolution proposal. Track ownership, deadlines and customer responses.

## Suggested connectors
QuickBooks, Xero Accounting, Stripe, Gmail, Google Drive. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Cases reference invoices and customers. Evidence items identify source and access; disputed line items, timeline events, proposed adjustments and approvals form the case record. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Watch selected correspondence or accept manual intake. Refresh invoice balances and remind owners about overdue investigation steps, deduplicating repeated messages. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Require finance approval before credits, refunds or accounting changes and separate those actions from case recommendations. Keep external messages as reviewed drafts. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A reviewer can trace the proposed resolution to evidence; partial disputes preserve undisputed amounts; resolving the case records the actual approved outcome. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build purchase request approvals as a working business app in this Continual project.

## Objective and users
Build a purchase intake and approval app for employees, budget owners and finance.

## App screens and workflow
Collect vendor, purpose, amount, currency, cost center and evidence. Evaluate explicit policy rules, route to the appropriate approvers, and track ordering and receipt after approval.

## Suggested connectors
Google Sheets, QuickBooks, Xero Accounting, Brex, Ramp. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Requests contain line items, requester and budget context. Versioned policies produce check results; approval steps record decisions and the exact request revision approved. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Route submitted requests, remind approvers and escalate overdue decisions. Re-evaluate policy and invalidate affected approvals when material request details change. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Ask for approval thresholds and budget authority. No requester self-approval where policy prohibits it. Approval does not authorize the app to transfer funds or place an order automatically. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A threshold routes correctly, changing the amount requires fresh approval, and rejected requests cannot advance to an approved purchasing state. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build fulfillment exception desk as a working business app in this Continual project.

## Objective and users
Build an exception desk for commerce operations staff handling delivery problems.

## App screens and workflow
Match orders to shipments, flag missing tracking, late dispatch or conflicting statuses, and assign investigation cases. Show order and shipment timelines with draft customer updates.

## Suggested connectors
Shopify, ShipStation, Odoo, Gmail. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Orders contain line items and promised dates. Shipments map partial quantities and tracking IDs; exception cases store evidence, owner, reason and resolution. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Refresh orders and shipments on supported events or a schedule. Allow for provider lag, deduplicate cases and close exceptions only when the relevant delivery evidence resolves them. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Do not treat a label as a delivered shipment or a partial shipment as a completed order. Require approval before customer messages, reshipments, refunds or order changes. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A split shipment remains accurate, stale tracking is distinguished from confirmed delay, and retrying an import creates no duplicate cases. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build customer-impacting bug tracker as a working business app in this Continual project.

## Objective and users
Build a customer impact app for support leads, account managers and engineering triage.

## App screens and workflow
Link customer reports to reviewed bug records, show affected accounts and workarounds, and track issue and release progress. Prepare account-specific updates when a fix becomes available.

## Suggested connectors
Zendesk, Intercom, HubSpot, Linear, Jira, GitHub, Sentry. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Bugs link evidence, engineering issues and release references. Impact records connect customer reports and accounts; update drafts and verification steps track communication and resolution. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Refresh linked issue and release status and suggest updates for affected owners. Keep ambiguous report-to-bug matches in a review queue. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
A merged pull request is not proof of deployment or customer resolution. Restrict sensitive account and incident details and require approval before external notices. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
Multiple customer reports can link to one bug; a fix progresses through deployment and verification; each account update reflects only its relevant impact. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build release readiness checklist as a working business app in this Continual project.

## Objective and users
Build a release review app for engineering leads coordinating production releases.

## App screens and workflow
Create a release candidate with immutable revision, scope and checklist. Display build results, open blockers, deployment preparation and sign-offs, with a clear readiness decision.

## Suggested connectors
GitHub, Buildkite, Linear, Jira, Sentry. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Release candidates identify repositories and revisions. Checks reference build runs and issues; approvals bind to the candidate revision; exceptions have owner and rationale. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Refresh linked build and issue evidence. Invalidate revision-specific checks and approvals when the candidate changes; notify owners of new blockers. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Do not deploy automatically or equate a passing build with complete readiness. Mark inaccessible or stale checks as unknown and require an accountable release decision. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A failed required check blocks readiness, changing the revision resets affected sign-offs, and a reviewer can trace the decision to exact build evidence. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build supplier delivery tracker as a working business app in this Continual project.

## Objective and users
Build a delivery tracking app for purchasing coordinators managing supplier commitments.

## App screens and workflow
Import open purchase orders and confirmed delivery dates. Show upcoming arrivals, late items and a queue of supplier follow-ups. Let owners record revised commitments and supporting correspondence.

## Suggested connectors
Odoo, Google Sheets, Gmail. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Suppliers own purchase orders with line items, quantities and promised dates. Receipt records track partial delivery; commitment revisions and exception cases retain evidence and ownership. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Refresh purchasing and receipt data daily. Flag unreceived quantities past their confirmed due date and prepare supplier follow-up drafts without duplicating open cases. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Have a user confirm dates extracted from email and approve supplier messages. Do not amend purchase orders automatically or count a partial receipt as complete. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A split delivery leaves only the remaining quantity outstanding, an updated promise retains the original date, and a completed receipt resolves its exception. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.

Build inventory replenishment review as a working business app in this Continual project.

## Objective and users
Build a replenishment review app for inventory planners balancing stock availability and purchasing constraints.

## App screens and workflow
Configure item locations, lead times, minimum stock and order quantities. Show stock coverage and projected shortages, then review proposed replenishment quantities and record purchasing decisions.

## Suggested connectors
Shopify, Odoo, Google Sheets. These are options, not a requirement to connect every service. Inspect available connections and tools, choose the user's systems of record, and explain any missing capability. Hosted MCP and Pipedream tools depend on account permissions. Use a clearly labeled sample-data mode until real sources are connected; never present samples as live data.

## Core records and relationships
Items have location-specific inventory snapshots, demand history and supplier constraints. Replenishment proposals reference the data window, calculation settings, reviewer and resulting purchase reference. Keep provider IDs and source references. Store app-owned records durably in the project database; external services remain authoritative for their records.

## Recurring work
Refresh stock and demand daily and recalculate draft proposals. Distinguish available, reserved and incoming stock, and flag missing or stale inventory data. Use Continual automations for supported events or schedules. Provide run status, last successful refresh and an actionable error state. Make retries idempotent and keep sample mode from calling external services.

## Review boundaries
Treat demand forecasts as estimates. Ask for lead-time and reorder policies; do not place orders or transfer inventory automatically. Recheck stock before accepting a proposal. Enforce user and record access on the backend. Keep credentials in connections, never in app source.

## Success criteria
A proposed quantity respects minimum order rules, inbound stock is counted once, and stale or incomplete data prevents a misleading replenishment recommendation. Demonstrate the main workflow with representative data, including empty, loading and failure states.

## Delivery
Start with the smallest complete workflow, using the app-development skill when available. Ask only for missing decisions that materially affect behavior; use sensible defaults for layout. Build a usable, responsive app with persistent records, filters and detail views. Show a preview and explain connection setup and any remaining gaps. Keep publication and live automations subject to the user's explicit approval.