Product contract

Target edition: 20 October 2026, expanded for buyer reviews 1, 2, 3, 4, 5, 6 and 7. Pegboard is the complete work and project management product being built for business teams. This is a destination contract, not a description of shipped functionality. No code or published contract exists; every clause is missing. Names and PEG-001 through PEG-030 come from the desk and remain stable. Added PEG IDs extend that scope. Each clause includes a public-door acceptance journey, repeated in ACCEPTANCE.md.

Product target

The complete job

A team takes requests in, turns an accepted brief into an executable project, assigns real owners and dates, coordinates dependencies and capacity, produces and reviews deliverables, obtains version-specific human approvals, and reports honestly to stakeholders against goals. A switching buyer brings active projects, history, files and permissions with them, connects their existing services and continues work without a silent loss of context. Agents do coordination and first drafts, carry approved work forward and show their sources; humans keep decisions and accountability.

This is one independent product. Workspaces are organizational divisions inside an owner-run business installation; a separate isolated business uses a separate installation. Reporting, workload, time tracking, unlimited guests and agent teammates are included, with no seat minimums or buckets. Difficulty, provider app approval, native mobile distribution and source export limitations are engineering obligations, never reasons to drop a clause. Dollar budgets, rates, margin and invoicing belong to Gauge; Pegboard's USD field is work metadata, not a billing ledger.

The evidence base is lane ct’s INVENTORY.md and inventory.json for Pegboard, researched on 20 October 2026. The desk inputs are TARGET.md, row.json and naming-only NAME.md for the work category. Uptime and Orbit's launch contracts set the operational depth; no behavior is asserted implemented by borrowing their tests.

Acceptance conventions

Journeys use the actual deployed Cloudflare/Base product, its authenticated browser routes, versioned public API, installed mobile clients or documented import/CLI doors. Route names in prose are buyer-facing destinations to implement, not claims of existing paths. Every browser journey runs and is personally inspected at 1440 and 390 CSS pixels with realistic US campaign, operations and agency data, keyboard and assistive-technology access. A phone-width web view does not prove native mobile support.

Provider tests use an authorized provider sandbox or a network-edge fake built from the provider's current official request, response, event and error schemas. Fakes never replace Pegboard's domain, permissions, persistence, queue or scheduling. Provider app registration, consent and real-account qualification remain required before claiming a live integration; a schema-fake result must be labeled as such. Delays, retries, quota limits, lost responses, revoked access, duplicates, concurrent edits and process restarts are exercised where relevant. Sending and provider acknowledgment never imply a human read, update, approval or completed deliverable. Human approval is required for published plans, client/executive publications, spend, new outside-organization disclosures and agent/AI-produced changes to other people's dates. A current Admin-reviewed deterministic rule activation under PEG-012 is already approval for its in-scope date and assignment actions, including dates set on newly created tasks; it does not need approval again on each run. The reviewed-share approval for ordinary system notices below is already human approval, not a per-message review requirement. The approval semantics below apply to every clause; no agent or rule can grant that approval to itself.

An external send is disclosure to a person or destination outside the organization: clients, vendors, public pages, guest recipients or externally shared channels, even when the transport is the company's Slack, Teams, Nook or mailbox. A company-only channel/person/mailbox is an internal destination, not external merely because its provider is SaaS. Internal task notifications, digests, reminders and rule/agent posts execute under a standing owner-approved policy naming allowed audience, content/scope, cadence and channels, plus current recipient permissions and preferences.

A person's reviewed guest invitation/share under PEG-019 is also approval for ordinary system notices inside that share: assignments, due-soon/overdue reminders, digests, comment/activity notices, proof/approval notices and reminders, and recipient-bound reply routes. These fixed system event templates deliver to that current guest's own inbox, verified email, personal chat destination or device under the guest's own channel/digest/follow/mute/DND preferences, like a member's notices, without another approval. This applies when a rule or follow-up process triggers the ordinary notice, but never turns arbitrary text supplied by a rule or agent into a system notice. Every queued delivery rechecks the current recipient, share, record, field/comment/proof visibility and preferences; revoked/expired shares cancel queued notices and reply authority, and internal-only material is omitted from the payload and aggregate counts. An explicitly reviewed migration share adoption can supply the same approval; imported inactive shares alone cannot.

The share does not approve agent-composed outbound messages (including a personalized chase to that same guest), client/executive status publications, posts or feeds to client-shared channels, new audiences or content outside the share. Those remain pending for exact human recipient/content/version review. Outside-share record content also requires a separately reviewed access/share change before delivery; a send approval alone never grants access. Changed/unknown audiences wait for review. Human approval of an invitation, share or reviewed update does not authorize an agent to change another person's dates, activate a scheduling rule or approve a person's work; deterministic rule authority comes only from PEG-012’s separate reviewed activation. The human composing/publishing an exact reviewed update or sending an invitation is the approving person for that action; there is no second approver unless configured by the organization.

For a human date edit, the authorized editor sees the entire knock-on change set, including affected owners, dates, capacity and conflicts. Dragging and releasing after that visible preview, or pressing Apply in another date editor, is that person's approval of the exact set; execution rechecks permission and record versions and records the editor. No second sign-off is needed. If any affected record is outside the editor's grant, the proposal waits for its authorized approver without revealing hidden work. An autonomous agent or AI-produced date/assignment value always proposes changes affecting others for a named person's exact approval; personal unlocked blocks can follow PEG-069's standing personal policy. A deterministic rule’s activated version can set, clear or shift start/due dates and assign in-scope new or existing tasks immediately under PEG-012’s reviewed scope, offset and calendar. Changed/inactive rule versions, out-of-scope cascades and effects outside the activating Admin’s current grant wait for an authorized approver; activation cannot approve AI/agent output or grant new access. All reversible schedule changes retain PEG-064 undo.

Target clauses

Work model and planning

PEG-001 — One work graph. Teams create workspaces, teams, projects, sections, tasks, nested subtasks and milestones with stable IDs, owners, collaborators, descriptions, priorities, start/due dates and statuses. A task belongs to several projects without becoming several records; project-specific sections and workflow mappings do not fork its history or double-count its effort. Cross-project membership never grants access to another project's private material. Tasks may also have no project and remain private under PEG-073. Configurable human-readable task references such as MKT-142 are unique within the installation, remain stable on moves/multi-homing and resolve historical aliases after a prefix change; they supplement immutable IDs and never weaken access checks. Team/project discovery, self-joining and permission-safe refused-link requests use PEG-083; discovering an object never confers a stronger role than its configured default. Acceptance evidence: In Projects, build a campaign and launch project, move a task and add it to both, complete a subtask and inspect one task ID, shared changes and one history in both views. A guest on one project cannot discover the other's name, private fields or attachments through UI, API or exports. Create a no-project personal task and a MKT-prefixed task, move/multi-home the latter and change its project prefix; old and current references find the same task for authorized users and reveal nothing to others. Run PEG-083’s public-team join/team-project and private-link request journeys against the same multi-project graph.

PEG-002 — Fields, statuses and shared definitions. Teams configure text, number, USD currency, date, people, single/multiple dropdown, checkbox, formula and relationship rollup fields, per-project status sets and a shared field library. Definitions carry units and permissions; formulas expose errors rather than plausible zeroes, detect dependency cycles and recompute consistently. A shared field keeps its identity across projects and reports; changing its type previews affected records and never silently drops values. Free-form tags are a separate work type from custom fields: a workspace tag catalog supports create/rename/color/archive, task multi-tagging and cross-project tag filters. Catalog names and tag counts are permission-filtered, including personal-task tags. Only project/team Admins change field/status definitions; Editors change permitted values. Acceptance evidence: Create every field type through project settings, add one library field to three projects, edit inputs and compare formula/rollup results through task, report and API reads. Try a cycle, hidden input and incompatible type change; see a safe explanation and no leaked input or lost data. Create a campaign tag independent of a dropdown, tag work across three projects, rename it once and filter by the tag. A Viewer cannot tag or edit values, an Editor cannot alter definitions, and a guest cannot enumerate internal/personal tags.

PEG-003 — Every work view on the same records. List, board, spreadsheet-style table, timeline/Gantt, calendar and workload show the same task graph. Save, name and share filters, grouping, sorting, visible columns and personal/team defaults without granting extra access. Inline edits and accessible alternatives to drag operations update all open views; date-only work and timed work remain distinct. Saved filters also drive list, board, table, calendar and timeline/Gantt across selected projects at team, portfolio and workspace scope, with workload across the same permitted commitments. Multi-project tasks appear once unless an explicitly labeled membership grouping is chosen; edits retain each home project’s field/status mapping. At PEG-023’s fixed dataset/network/device profiles, a remote committed authorized edit is painted in another open permitted view without reload at p95 at most 2 seconds, measured commit-to-paint over 100 events per profile; pending/offline conflicts and permission revocation remain explicit. Acceptance evidence: Open a realistic project in all six views in two signed-in browsers, filter and group it, move a card and edit a due date in the table. Observe identical persisted records without reload and restored saved views after sign-in; a shared-view recipient sees only permitted rows and fields. Create a team-scope due-this-week view over 30 projects in list, board, table, calendar and timeline, including one hidden project and one multi-homed task. Check exact permitted counts, move a card and edit a date, and observe the same single record in its home project and all saved views. Sharing never grants access to the hidden project. Measure 100 remote real edits on each fixed profile and compare commit-to-painted-value p95 with 2 seconds; hidden records never arrive, and an offline view is labeled stale rather than counted live.

PEG-004 — Dependencies and believable schedules. Finish-to-start, start-to-start, finish-to-finish and start-to-finish dependencies support explicit lag/lead, cross-project links, milestones, critical path/slack, working-day calendars and saved baselines. Scheduling explains the chain and proposed shifts, honors working hours, weekends, US federal holidays, time off and DST, detects cycles and exposes impossible constraints. A human editor confirms the previewed change set by the drag/drop or Apply gesture defined above; its dependent shifts execute together without a second sign-off. Agent/AI-initiated shifts and unactivated or out-of-scope rule shifts affecting others wait for a person to approve the exact set, and any stale or out-of-scope set refuses. Baselines remain historical when the current schedule changes. The preview is visible before commit on Timeline as well as list, board, calendar and task detail; the same schedule algorithm and permission checks serve every door. Deterministic PEG-012 rule activation approves only dependency effects inside its reviewed scope and activating Admin’s current grant; outside cascades wait for their authorized approver and do not disclose private work. The default PEG-037 Ready to start notice follows the actual last-blocker completion transition without requiring a user-built rule or exposing private predecessors. Acceptance evidence: Through Timeline, exercise all four dependency types, delay a predecessor over a US holiday/weekend and DST boundary, inspect the critical path and baseline variance, then approve the reviewed shift. Reject a cycle and a stale plan; no unapproved downstream date changes occur. Drag a predecessor as a project Editor after viewing the knock-on preview: dependants shift exactly once, attributed to that editor with undo and no second approval. Repeat as an autonomous agent and require pending approval; a viewer or stale edit cannot shift any task. Exercise PEG-012’s in-scope date propagation and out-of-scope hidden-dependant case, with immediate authorized effects only when coherent and no unauthorized partial schedule. Run PEG-037’s two-blocker/concurrent completion and hidden-predecessor readiness cases on this same dependency graph.

PEG-005 — Recurring work and human decisions. Tasks and entire projects recur on calendar or completion schedules with a timezone, exceptions, end condition and preview. Recurrence preserves template references without copying approvals as new decisions and does not duplicate occurrences across restart or DST. Milestones and approval tasks are first-class types; approve, request changes and reject record the human, time, exact reviewed revision and reason. Acceptance evidence: Complete a weekly recurring task and recur an onboarding project, restart during generation and inspect one next occurrence. Through an approval task, request changes, revise and approve; historical decisions remain attributed and a copied or changed revision cannot inherit sign-off.

PEG-006 — Useful reusable templates. Task and project templates capture phases, subtasks, fields, dependencies, rules, relative dates, role placeholders and required approvals. A gallery covers marketing campaigns, launches, client onboarding, events and content calendars. Instantiation previews the concrete work, dates, missing roles and capacity impact; source owners, client guests and secrets are not blindly copied. Template updates are versioned and do not rewrite live projects without a reviewed application. A direct Duplicate project flow, separate from templates, previews selectable tasks/subtasks, assignees, relative/original dates, rules and members. It creates new work IDs and retains source provenance, rechecks every copied membership, shows audience/date effects and leaves copied rules/sends/shares inactive until explicitly reviewed; prior proof approvals and private-task context do not become new decisions or shares. PEG-012’s reviewed deterministic rule activation can instantiate a pinned template with reviewed role mapping, scope and relative dates without a new per-run approval; copied rule definitions and prior proof/share decisions remain inactive unless separately authorized. A later template version or changed date/assignment mapping invalidates the activation that depended on it. Acceptance evidence: Instantiate each gallery family through New project, choose start date and role mapping and inspect correct dates, owners, fields, dependency edges and rules. Leave a role unresolved and require an explicit choice; updating the template leaves an existing project unchanged until reviewed. Duplicate an active project with options first excluding members/rules and then selecting them; compare exact chosen work/assignees/dates, new IDs and source backlinks, review staged shares/rules and confirm no copied sign-off, duplicate notification or broadened visibility. Instantiate a pinned template from an activated deterministic rule and inspect immediately applied new-task dates/assignments; change the template/mapping and keep the next run pending until the Admin reviews/reactivates. An AI-chosen template/date still requires exact human approval.

PEG-087 — Convert work without losing its history. Authorized people preview task → project, project → task, subtask → top-level task and task → subtask conversions through ordinary work menus and the public API. The preview maps owner/collaborators, dates, fields, nested work, comments/files/proof versions, time, source aliases, dependency links, memberships and history, and shows target visibility/capacity changes and any unrepresentable settings. A task-to-project conversion creates one linked project, maps its subtasks into project work and keeps a stable resolvable source record/alias and historical evidence; project-to-task creates a linked parent task with chosen constituent work as subtasks or explicit retained links. Promotion/demotion preserves task identity where the type remains a task, rejects cycles/depth or permission conflicts and never leaves orphaned time/files/children. Nonrepresentable project-only configuration stays as counted linked inert source context with a repair path, never disappears. The person chooses/reviews visibility; conversion cannot expose private personal work, copy an old proof approval onto a different version, activate imported rules or turn an approval into ordinary completion. Recheck the exact source/target revisions and affected scope atomically; repeating the request yields the same conversion, and PEG-064 undo reverses only unchanged owned effects while preserving later native edits. Acceptance evidence: At 1440/390 and through the API, convert an intake task with nested work, file/proof versions, comments, a time entry, dependency and source alias into a project, then convert a populated project into a task with reviewed nested-work mapping. Resolve old links to the authorized survivor/linked record and reconcile all counts, authorship, durations, version digests and scopes. Promote a subtask to a task and demote another task, retaining IDs/history and refusing a cycle, private-scope disclosure, stale preview and unauthorized target. Keep unrepresentable rule/report settings visible as linked inert repair items; replay once without duplicates and undo after a human edit without deleting that edit or resurrecting old approvals.

PEG-031 — Find and safely change work at scale. Permission-aware global search covers tasks, projects, comments, briefs and authorized attachment metadata with filters, saved searches, favorites and recent work. Keyboard quick-add, shortcuts and multi-select support bulk assignment, status, dates, fields, movement, duplication and archive. Bulk review names affected records and skips none silently; stale or forbidden rows are reported, and undo preserves subsequent independent edits. Ordinary tasks can be marked duplicate or merged after a preview chooses the survivor and resolves conflicting fields, assignments, project memberships, dependencies and attachments. Source IDs/reference aliases redirect to the survivor without leaking its existence to outsiders; comments/time/history retain author/source provenance, one approved decision is never duplicated onto different content and merging grants no broader visibility. A stale or unauthorized merge refuses atomically, with conflict-preserving undo where reversible. At PEG-023’s fixed 10k-task/500-member profiles, search paints real permission-filtered results at p95 at most 1 second from submitted query over 100 cold and 100 warm searches per profile, including comments and empty-result queries; skeletons/cached hidden counts never satisfy it. Acceptance evidence: Find an old approval by comment text, save its filtered view, then bulk-change a mixed-permission, concurrently edited task selection through the UI. Inspect exact per-row outcomes, undo unchanged effects and retain later edits; hidden records never appear in search suggestions, counts, API or downloads. Mark and merge two ordinary tasks with conflicting owners and fields, a dependency and separate comments/time entries. Inspect the chosen survivor, one conserved history/time total and safe alias redirects; concurrent edits force re-review and a private-task merge cannot expose either task or its fields. Run the stated cold/warm searches on both fixed profiles, measure query-submit-to-painted-results p95 against 1 second and compare exact permitted result IDs after revocation, with no loading skeleton or hidden-row cache shortcut.

PEG-033 — Visual business-work planning. Teams use task-linked mind maps and a collaborative planning canvas to arrange phases, notes and relationships, promote a planning item into a real task and see its current owner/status. Moving a representation does not clone a task or approve dates. Canvas content and exports follow project permissions and remain portable; project planning is not an unrestricted database or knowledge-base product. Acceptance evidence: In a project planning canvas, two members rearrange a mind map, create a task from a note and edit that task in List. The canvas reflects one task ID and state, exported content restores, and a guest cannot see internal-only notes.

PEG-034 — Reusable workflow bundles. An administrator versions a bundle of fields, views, rules, templates and approval stages, applies it to selected projects and previews subsequent changes with conflicts and local overrides. Adoption preserves existing work and decisions; disabling a bundle stops future actions without deleting history. Acceptance evidence: Apply a campaign bundle to three projects, locally modify one rule, then preview a new version. Adopt only chosen compatible changes, preserve the override and work history, and disable the bundle during queued work without executing an obsolete action.

PEG-035 — Risks, decisions and change requests. Projects keep an accountable register of delivery risks, blockers, assumptions, decisions and scope/date change requests linked to tasks and milestones. Each has owner, impact, next action and review date; accepted changes record the human decision and preserve the original baseline. These are business delivery records, with engineering issues linked to Vector rather than recreated. Acceptance evidence: In a project, raise a dependency risk, assign mitigation and propose a scope/date change. Require the right human to accept it, retain its rejected alternative and original baseline, and trace the risk into the portfolio update and linked work.

Intake and collaboration

PEG-007 — Request intake and triage. Public and internal branching work-request forms support required fields, attachments, safe validation, acknowledgments and mappings to task fields and templates. Submissions enter a permission-scoped queue with routing, duplicate candidates, owner, priority and triage deadline; business-hour SLA clocks pause only under explicit policy. Abuse controls protect public intake and never expose internal project data. Pencil responses use the same intake door. Every intake attachment uses PEG-082’s 25-MB-per-file/75-MB-per-submission preflight, resumable transfer and owned custody. A fixed intake assignment/date policy reviewed and activated by its Admin under PEG-012 assigns and dates new matching tasks immediately; it does not require the designer to approve each request’s due date. AI-generated routing/date choices retain the human gate. Acceptance evidence: Submit branching internal and public forms and a signed Pencil response, including an attachment and duplicate source ID. Inspect one mapped task, acknowledgment and triage clock; advance beyond its deadline to flag/escalate it, and reject malformed, abusive or forged submissions without leaking private fields. Run PEG-082’s exact-boundary and one-byte-over form cases from public and internal intake without private-field leaks or partial submitted attachments. Submit PEG-012’s ten form requests, compare exact five-business-day due dates and fixed designer assignments without pending per-run approval, and distinguish a separately pending AI-proposed assignment/date.

PEG-082 — Resumable attachments with owned byte custody. Task and comment attachments, proof revisions, guest-portal uploads, desktop quick-add, both native phone apps (including camera/photo/video capture), browser/sidebar file upload and the public API all accept at least 100 MB per file; the launch limit is exactly 100,000,000 bytes, inclusive, on every ordinary path. Public and internal PEG-007 request forms accept 25 MB per file (25,000,000 bytes inclusive) and 75 MB combined per submission (75,000,000 bytes inclusive). The UI/API state both human-readable and exact byte limits before choosing/transferring files; administrators cannot silently lower these per-file guarantees. There is no arbitrary files-per-task/workspace count cap; bytes consume the installation’s disclosed PEG-061 storage usage and owner-set aggregate quota. Each uploader sees the applicable remaining capacity or a privacy-safe available/not-available decision for restricted shares, without learning private storage totals. A lower remaining aggregate quota is named before transfer, with an owner-contact/repair path; concurrent uploads reserve capacity atomically and cannot overcommit it. Before sending file bytes, a size/role/quota preflight refuses an oversized file or over-total form selection, names the exact applicable limit/remaining allowance, and offers Attach a Google Drive or OneDrive link through PEG-043 (or the owner’s PEG-080 connection guide if disconnected). The server independently checks actual streamed size and refuses falsified size claims; no partial or failed upload is a finished attachment or proof. Web, desktop, guest and native app transfers show bytes/progress, interrupted/resumable/failed state and a cancel control; the public API exposes the same upload-session progress and resume door. Durable bounded-chunk/multipart sessions resume after a connection or process/app interruption and finalize exactly once only after verified byte count/content digest and current permission checks. Retrying a part or finalization creates no duplicate attachment/version, and cancellation, expiry, quota failure or share/session revocation aborts incomplete objects and releases reservations. Completed attachment bytes and proof versions live in the installation’s own US R2 bucket, registered in Base’s createPortability({db, buckets, policy}) buckets and bucket/object-reference policy; a metadata row, external URL or unregistered parallel store cannot satisfy custody. This follows Base’s portable bucket contract and Coffer GIVE-002’s FILES-bucket precedent. PEG-058 archives include actual complete bytes, metadata, source/version/digest and task/comment/proof links and restore multipart-sized files to the destination bucket; resumable session credentials/partial uploads never become restored authority or completed artifacts. PEG-059/065 erasure/retention covers original bytes, proof versions, derived previews and incomplete parts. A reviewed external proof share can separately grant narrow Upload a revision permission: it allows a replacement only on that shared proof and grants neither general task editing, wider access nor any new proof-approval authority; existing human approval policies apply and approve-only shares remain approve-only. A migrated attachment at or below the same 100-MB bar can be uploaded as a later proof version through the ordinary paths, with historical source provenance and decisions retained and fresh review required. Acceptance evidence: Through browser/public API upload-session doors at 1440/390, the installed macOS/Windows desktop app and both native iOS/Android apps, upload and finalize an exact 100,000,000-byte fixture on every ordinary path, including task, comment, proof revision, browser/sidebar upload and guest upload; compare stored bytes/digest and one version. A member, guest Editor and external proof approver with the explicitly reviewed revision-upload grant each upload a valid 95-MB MP4 and 80-MB PDF through web and both native apps, then annotate the MP4 at a specific frame/timecode and the PDF on its page. An approver without that extra grant cannot upload, and an upload-only contributor cannot approve without a separate current human approval grant. Interrupt a chunk and the receiver/app, restart and resume to exactly one matching version; replay part/finalize, revoke the share mid-transfer and cancel another session, checking no unauthorized completion or orphaned reservation/part. Refuse a 100,000,001-byte file and a 25,000,001-byte form file before any file-data request; accept three 25,000,000-byte files in one form submission and refuse an added byte before that selection transfers. Inspect exact limits and the Drive/OneDrive option on web, desktop, guest, phone and API responses, including a disconnected-provider guide link. Exercise visible lower remaining quota, two competing reservations and dishonest size metadata; no failed/partial object appears in Files or proof review. Re-upload a migrated 100,000,000-byte Asana attachment as proof v2, preserve source v1 history and refuse stale v1 approval. Through Base’s actual archive/export and restore API/CLI doors with a real R2 sandbox, interrupt/resume archive restoration of these files into a fresh installation, compare exact bytes/digests/links including the large MP4/PDF, and prove no old upload capability executes. Erase one proof and an interrupted upload and verify original/derived/version/partial-object cleanup and released PEG-061 storage usage.

PEG-008 — Capture where the team already works. Email-to-project handles forwarded mail, envelope routing, attachments and sender attribution. Authorized Slack, Teams and Nook message actions create tasks with source links and approved contextual excerpts. A browser extension captures a selected page/title and chosen content under the user's current scope. Capture previews project, owner and visibility, deduplicates replays, treats external content as untrusted and never grants the source sender project membership. Each member can create/rotate a sealed personal email-to-My-Tasks address in Account settings; authenticated mail routed there becomes an owner-private no-project task with safe attachments, sender/source attribution and no automatic collaborator/project grant. Receipt routes are installation/member-bound, rate-controlled and revoked at sign-out policy/deprovisioning/address rotation; a guessed or foreign route cannot enumerate personal work. Acceptance evidence: Forward a real-format email with attachments, invoke each of Slack, Teams and Nook message actions and capture a web page with the installed extension. Read persisted tasks with source links, replay an event and revoke source access; no duplicate task, unauthorized excerpt or hidden project is created. Create a personal intake address, forward authorized mail with an attachment and find one private My Tasks item; replay it without duplication. Another member cannot read/search the task or its raw route, and messages to a rotated, revoked or cross-installation route create no work or share.

PEG-009 — My Tasks and useful notifications. Personal prioritized work combines assignments, due work, approval requests and reminders across permitted projects. A unified inbox supports follow/unfollow, read/unread, mute, snooze, daily digest, do-not-disturb and timezone-aware quiet hours. Users can explain why an item arrived and act without losing place. A muted work stream does not create new notifications; mandatory security notices remain clearly separate. PEG-073 defines personal no-project tasks, private sections, date promotion and the deterministic default order; My Tasks shows those alongside authorized project assignments. Every task/comment/approval email notification supports PEG-072 reply-by-email. Internal notices use standing policy; ordinary guest system notices and reply routes use the current reviewed share approval defined above, with each guest choosing their own notification preferences. Agent-composed guest messages and new/outside-share disclosures still require exact review. Guest notification controls are independently editable by the guest and neither inherit a member’s preferences nor default to silence merely because the account is external. Every outbound email follows PEG-084’s authenticated sender, qualified inbox delivery path, address suppression and provider-paced queue; provider acceptance remains distinct from actual Inbox receipt or human response. PEG-037’s Ready to start notice is on by default for the current assignee when the last blocker completes and follows these notification preferences, including guest controls. Acceptance evidence: Assign work, mention a follower and a muted user, snooze an approval and cross a DND boundary. In My Tasks and Inbox, inspect correct priority and only expected notices; receive one configured daily email digest with no hidden or muted content and no lost actionable approval. Compare My Tasks ordering with PEG-073’s stated order; reply to an ordinary comment notification and verify PEG-072’s one attributed comment, then verify an internal digest sends under policy and a guest digest containing only currently shared work sends without per-message approval. An agent-composed client-guest message still remains pending exact review. Assign shared work to a guest Editor with email and push enabled and receive exactly one of each without an approval queue; deliver a due-soon reminder, comment notice and daily digest with no internal-only field/comment, then mute/DND and verify the guest’s choices suppress or defer the expected notices. Exercise PEG-084’s unauthenticated-domain block, signed bounce/complaint suppression and throttle/restart cases for this email path without duplicate, silent-drop or false-delivered outcomes. Exercise PEG-037’s no-rule default last-blocker completion, replay/mute/reassignment/guest privacy cases through Inbox and configured channels.

PEG-010 — Collaboration with a complete history. Rich-text task descriptions, project briefs, comments, mentions, reactions, file attachments and collaborative editing preserve revisions and attributable activity for every work-field change. Presence and live updates do not bypass permissions; concurrent edits surface conflicts or merge without losing text. Edit/delete controls retain appropriate history under retention policy. Project context links to Slate knowledge pages without creating a second wiki. Project/team Messages are scoped announcement threads with a subject, work links, threaded replies, subscription controls and email/in-app delivery alongside status history; they do not create workplace chat channels. Rich descriptions, briefs and comments embed permitted Loom/YouTube video, Figma designs and Google Docs with an accessible link alternative, provider permission checks and explicit unavailable/revoked states; embedding never publishes a private source. Native task/comment file uploads use PEG-082’s 100-MB inclusive limit, progress/resume and version-safe custody. The same p95 2-second committed-change-to-painted-view bar from PEG-003 covers comment/brief collaboration on PEG-023’s fixed profiles, with source revision and stale/offline labels. Acceptance evidence: Two browsers edit a brief and comment on a task, mention a teammate, attach a file and react. Inspect live updates, field-level actor/time history and conflicting edits after reconnect. A restricted guest's UI, API, exports and mention picker reveal only permitted content. Publish a project and team announcement to a reviewed audience, receive one in-app/email notification and reply in-thread from email. Embed each named media type in a brief and task context, revoke source access and confirm a restricted guest sees no protected preview or content; keyboard users can use the link alternative. Complete PEG-082’s task/comment limit, interruption and no-duplicate finalization cases. Measure 100 remote comment/brief edits per fixed profile, including a revoked reader and reconnect conflict, with p95 at most 2 seconds for online authorized views and no private payload.

PEG-011 — Version-specific creative proofing. Reviewers annotate images, PDF pages, video timecodes/frames and webpage captures, compare versions side by side and track open/resolved feedback. File identity, content digest and version remain attached to every pin and decision; moving or replacing a source file never moves old feedback onto unrelated content. Webpage proofs capture the reviewed state rather than pretending a mutable URL is a fixed asset. Every native proof revision accepts the PEG-082 100-MB bar, including externally shared uploads with a separately reviewed revision-upload grant; upload never constitutes proof approval. Acceptance evidence: Review two versions of an image, PDF, video and webpage through Proofs at both widths. An external guest pins a comment on PDF v2, compares v1/v2 and approves v2; change the underlying file and observe old proof/approval retained with new review required, including unavailable-source and expired-share states. Use PEG-082’s 95-MB video timecode/frame and 80-MB PDF paths, a migrated 100-MB file re-uploaded as v2 and the current-version approval refusals.

PEG-012 — Explainable local work rules. A no-code builder offers event and scheduled triggers, conditions and actions within/across Pegboard projects: assign, move, set fields, create from template, request review, notify or call a webhook/Crank. Rules carry actor scope, version, enable state, preview and durable run log with inputs, intended effects and outcomes. Loop protection, idempotency and bounded quota-aware retry protect work; retrying a failed run never repeats successful effects or bypasses human approvals. Only the relevant project/team Admin can create, change or enable its rule, field definition or task/project template; Editors can trigger authorized work actions without managing that configuration. AI classify/extract/draft steps are PEG-074. Named Slack/Teams/Nook channel/person actions run for internal audiences under standing policy. A rule-triggered fixed system notice to a current guest about already-shared work uses that reviewed share approval and preferences. Agent-composed guest text, arbitrary rule posts to external audiences, client-shared channel posts and agent/AI-produced date or assignment changes affecting others still wait for exact human approval. Deterministic in-scope rule dates/assignments use the separately reviewed activation below. A pending outside-share send cannot execute until an authorized human both reviews its exact disclosure and establishes any required share; the rule never broadens the share itself. The action catalogue also names mark an ordinary task complete, add a comment, add an existing permitted collaborator/follower, multi-home a task into another permitted project, create a subtask, and add a tag. Each has field/recipient/project scope, preview and the same retry/run/undo semantics; completing an ordinary task cannot sign an approval task. Adding collaborators or multi-homing cannot silently disclose previously private work: existing access is rechecked and any new share still requires the independent reviewed share decision. Deterministic scheduling actions set, clear or shift start/due dates from the trigger instant, a specific date, creation date, the triggering task’s start/due/custom date field, or versioned template-relative dates, with positive/negative offsets in days, weeks, months or business days. The preview names timezone, business calendar/US holidays, source-field null policy, invalid end-of-month clamping and DST handling; missing source dates produce a visible no-op/repair item rather than an invented date. An authorized project/team Admin reviews and activates an exact rule version with projects/task predicates (including future matching tasks), fields/actions, assignee choices, date offset/calendar and allowed dependency knock-on scope. That recorded activation is standing human approval for deterministic due/start dates and assignments on in-scope new and existing tasks, including form intake, created subtasks and create-from-template work. Each run applies those effects at once without another approval, subject to the Admin’s still-current grant and version checks; it records activating Admin, activation/version, trigger/source revision, computed dates/assignees and outcomes. A changed definition, calendar policy, scope or assignment/date configuration invalidates activation until reviewed again; there is no silent use of an older grant for a newer draft. Each run rechecks rights and affected dependencies. A cascade outside the reviewed scope/current Admin grant stays pending for its authorized human, with no private titles/counts leaked; a coherent approved in-scope effect may apply only if it leaves no inconsistent dependency state, otherwise the linked schedule change waits atomically. AI rule steps or agent-provided date/assignment values always require exact human approval; an AI label, template choice or upstream output that determines the resulting assignee/date is AI provenance too and cannot be laundered through a deterministic wrapper. Approval is never generated by a rule itself. Run deduplication and PEG-064 conflict-preserving undo cover dates, assignments and all six added work actions without undoing later independent human edits. A holiday-calendar edit identifies only activated business-day rules referencing that calendar revision; calendar-day rules, unrelated calendars and already committed task dates continue unchanged. Show one consolidated old/new-date/assignee/scope preview for affected rules and a bulk Re-review and reactivate selection to an Admin authorized over the selected projects. Record one decision per unchanged selected rule; stale/unauthorized rows wait individually, and no calendar edit silently rewrites existing commitments. New affected runs remain visible pending this single bulk review, not a hidden failure or one approval dialog per run. An Editor who cannot manage rules sees Ask your project Admin with the responsible current Admin(s), a scoped request/suggestion and its status; it creates no executable rule or elevated role. PEG-046 imports rule authorship as source attribution, suggests the required per-project Admin mapping and stages any role escalation for a human access decision rather than silently elevating a former Asana Editor. Acceptance evidence: Build a conditional status-change rule through Settings, trigger it across two projects and inspect the run. Fail its provider webhook, restart, retry and replay the trigger; one local effect persists, failure/uncertainty is visible, scope denial is enforced and no rule signs a human approval or sends an unapproved external message. Have an Editor attempt rule/field/template configuration via UI and API and refuse each, then have an Admin configure an AI intake-classification step and a Slack/Teams internal-channel post. Inspect the permitted dropdown result and step input/output log, one internal post without per-message approval, and a pending outside-share/arbitrary external send or AI-produced date proposal; a fixed assignment/reminder notice to a current guest inside their share delivers without another approval. Trigger two rules for the same guest: one ordinary due reminder inside their share and one disclosure of an unshared task. The reminder sends once under their preferences; the unshared disclosure remains pending review with no payload delivered, and refusal remains if required access is not granted. At 1440/390 an Admin previews/activates one form rule (assign the fixed designer, due in five business days on the selected US holiday calendar) and one section-move rule (assign the fixed editor, due in two calendar days). Submit ten requests and move ten existing tasks: all twenty runs apply the expected dates/assignments once with no pending per-run approval, and every log names the activated version/Admin and exact source/computed values. Replay a trigger and restart mid-run without duplicate effects; undo one run, preserving a later human edit as a named conflict. Create template work and a meeting-agenda subtask two weeks before a custom event date under activation; inspect correct new-task dates, negative offsets, a holiday, DST/end-of-month policy and missing-date no-op. Edit the offset without reactivation and require the next run to wait; reactivate after preview, then apply once. Revoke the activating Admin and refuse a later run. Make a date change reach a hidden dependant outside the reviewed project scope: keep the unauthorized cascade (or its inseparable change set) pending without hidden data, and require that project’s authorized approval. An AI-extracted date, AI-chosen routing/template that determines a date/assignee, and an agent re-plan each remain pending exact review. Exercise every added action via builder and public API: complete an ordinary task, add one comment, add a permitted collaborator, multi-home one task, create one subtask and add one tag; compare one intended effect after replay/restart and scoped undo. Refuse approval-task auto-signoff, hidden-project multi-homing and a collaborator who would gain unreviewed access. Add a US company holiday used by 30 rules across permitted projects, including two unrelated-calendar/calendar-day controls. Preview all affected future dates once, bulk approve the unchanged authorized rows and resume their pending deterministic runs without per-run approval; controls and existing dates are untouched. Change one rule or revoke one project grant between preview/apply and hold only that row. As an Editor follow Ask your project Admin, submit a rule suggestion and inspect the responsible person/request state, with UI/API config writes still refused. Import an Asana Editor who authored a rule, inspect source attribution and proposed project-Admin mapping, and activate only after the independently reviewed grant/activation.

PEG-036 — Approval routing and external review custody. Approvals support ordered or parallel stages, named people, required quorum, delegates, due dates, reminders and reopen/withdraw paths. Approve-only guests receive only the exact shared material; authenticated or expiring verified-recipient links bind the decision to a person and proof version, and merely opening a link never decides. Changed material invalidates pending decision authority and requires review again. The reviewed proof share authorizes fixed system proof/approval notifications and due reminders to its current external approver, with no additional send review and with their preferences respected. This delivery does not decide the approval or release other project material. Acceptance evidence: Route a creative proof through internal then external reviewers, deny an unauthorized reviewer, expire and revoke an external link, delegate a stage and submit changes. Inspect quorum, human identity, time and exact version; a stale tab or replay cannot approve a replacement asset or reveal other project content. Give an external approver a reviewed PDF-v2 share, advance to its configured reminder time and receive the ordinary proof reminder once without a per-message review. It identifies only their permitted version and safe fields; a hidden internal comment is absent and the decision remains pending until the human’s version-bound action.

PEG-037 — Durable follow-up and delivery outcomes. Due/overdue, blocked dependency, missing update, intake and approval reminders have named owners, working-hour timing, repeat/escalation policies and stop conditions. In-app, email, Slack, Teams, Nook and mobile push show queued, provider-accepted, failed, uncertain and person-responded states separately. Digests respect preferences; recovery, reassignment and revocation cancel obsolete chases. Uncertain external sends are reconciled before re-send. Ordinary assignment, due, comment, proof and approval notices and digests to a current guest use the current reviewed share as send approval, including rule-triggered notices, while honoring that guest’s channel/mute/digest/DND choices. Their delivery log names the approving share revision. Agent-written external chases still wait for exact send review; neither an agent action nor a reminder timer can convert its draft into an approved system notice. Every outbound email follows PEG-084’s authenticated sender, qualified inbox delivery path, address suppression and provider-paced queue; provider acceptance remains distinct from actual Inbox receipt or human response. The Ready to start system notice is enabled by default, without building a rule: when the last currently blocking precedent completes, notify the waiting task’s current assignee once per blocked-to-ready transition. Multiple blockers do not generate a premature readiness notice; duplicate/out-of-order completion events and concurrent final completions deduplicate. Reopened/new blockers retract an unsent obsolete notice and a later genuine blocked-to-ready transition may produce a new notice. Respect current task visibility, reviewed guest share, assignee changes and that recipient’s follow/mute/digest/DND/channel preferences; never reveal a hidden predecessor’s name/content/count. The notice opens the authorized waiting task and explains readiness using only permitted dependencies. It does not complete work, alter dates or imply proof approval; a person may disable it in notification preferences. At PEG-023’s fixed scale/profiles, ordinary non-digest non-DND internal/guest system notices appear in the authorized in-app inbox within 5 seconds of the committed event and are handed to the configured mail provider within 60 seconds when its quota/service is available. Measure event commit, inbox-visible, queue-ready, provider acknowledgment and receipt separately. Chosen holds, confirmed authentication failures, provider throttles, quiet hours and digests are explicit deferred states with next eligible time/owner, not falsely on-time successes; after eligibility returns, the same bounds apply from that instant. Push retains PEG-079’s separate five-second hand-off bar and actual Inbox placement/human receipt is never inferred from mail acceptance. Acceptance evidence: Make an approval overdue, reassign it during a queued reminder, simulate provider rejection and lost acknowledgment, restart and then receive a valid reply. Inspect one correctly routed reminder, visible exception and stopped escalation after the actual decision; no duplicate send, muted notice or fabricated response appears. With a guest Editor and external proof approver on reviewed shares, deliver assignment email/push, due-soon/overdue and comment notices, a digest and an on-schedule proof reminder without per-message approvals. Inspect one intended notice per event/recipient/channel and no internal-only material; recheck a queued notice after revocation. In the same run keep an agent-drafted guest chase and an outside-share rule disclosure pending exact review, with no external payload submitted. Exercise PEG-084’s unauthenticated-domain block, signed bounce/complaint suppression and throttle/restart cases for this email path without duplicate, silent-drop or false-delivered outcomes. With no PEG-012 rule configured, give one waiting task two blockers and a member assignee. Complete the first: no Ready to start notice. Complete the last (including concurrent/replayed/out-of-order completion) and receive one default readiness notice opening that task. Reassign before a queued send, mute/DND or revoke access, and verify current-recipient delivery or suppression with no hidden dependency details. Repeat for a scoped guest and a hidden predecessor, reopen/add a blocker before dispatch to cancel obsolete readiness, then complete a fresh blocked-to-ready transition and receive only its current notice. No task/date/proof decision changes as a side effect. At the fixed 10k-task/500-member profiles, timestamp 100 ordinary notice events including a guest and Ready to start: every happy-path inbox notice is visible within 5 seconds and mail is provider-accepted within 60 seconds, without counting a skeleton/outbox row as visible delivery. Cross DND/digest/quota/auth/chosen-hold cases, inspect explicit deferral/deadline and resume timing, no duplicate send and no fabricated mailbox receipt.

PEG-072 — Reply to ordinary notification email. Task, comment, approval and project/team Message notifications carry a recipient-bound, revocable reply route. A signed provider inbound event must establish delivery custody and authenticated sender identity, matched to a verified current member/guest address with comment access to the exact task/thread; an untrusted From header or possession of a forwarded reply address is insufficient. Valid replies append one attributed comment with safe attachments, strip recognized quotes/signatures without discarding new inline text and deduplicate message IDs. Explicit first-line /complete and /reopen commands from an authenticated current Editor/assignee can change ordinary task completion once and log the human action; they cannot complete an approval task in lieu of a decision. Other reply text becomes a comment, never an implicit command. Reply text never constitutes approval or grants To/CC addresses membership; exact decisions use the authenticated PEG-036/071 controls. A refused reply has an inspectable redacted reason without leaking hidden work to the sender. Every outbound email follows PEG-084’s authenticated sender, qualified inbox delivery path, address suppression and provider-paced queue; provider acceptance remains distinct from actual Inbox receipt or human response. Acceptance evidence: Generate an ordinary task/comment/approval notification and an announcement, reply from the verified authorized member address through the official-schema inbound mail door and read one comment with its attachment and original source ID. Replay it and test inline text amid quotes. Spoof the From address, forward the reply route to a stranger, revoke the member and use a Viewer’s address; each produces no comment, access grant or decision. Reply /complete and /reopen to an ordinary task notification as its authorized assignee and inspect one human-attributed state change per message; deny the same command from a Viewer. Reply “approved” or /complete to a proof approval email and keep its human approval pending until the explicit version-bound action. Exercise PEG-084’s unauthenticated-domain block, signed bounce/complaint suppression and throttle/restart cases for this email path without duplicate, silent-drop or false-delivered outcomes.

PEG-039 — Meetings become reviewed actions. Authorized Zoom, Google Meet and Teams meeting notes/transcripts become proposed task assignments, decisions and follow-ups with meeting/segment citations. Consent and source access govern capture; transcription can be provider-delivered or supplied through an authorized import. Participants resolve ambiguous owners/dates before adoption. No meeting recorder joins or records without the required organizer/participant controls. Acceptance evidence: Connect each meeting service at its official-schema boundary, ingest an authorized transcript with uncertain ownership and prepare actions. A person edits and approves them once through the meeting review page; tasks link back to the source, duplicate delivery does not duplicate work, and revoked access removes unavailable context from later agent reads.

Delivery and visibility

PEG-013 — Portfolios that roll up truthfully. Nested portfolios organize projects two or more levels deep and roll up status, progress, dates, owners, milestones, custom fields and delivery risk with drill-through to the underlying work. Shared task membership does not inflate totals; manual health and computed indicators are separately labeled. Permissions apply to portfolio search, aggregation and drill-down; totals do not disclose hidden work. A versioned owner-adjustable risk policy is visible beside manual health, with defaults: at risk when any incomplete milestone is past due, any incomplete critical-path task has negative slack, at least 20% of incomplete due-dated tasks are overdue, or the last human-published status is over seven calendar days old. Zero eligible due-dated tasks yields no overdue-share ratio, and a never-published status is labeled missing/unknown, not healthy. Each flag shows triggering source rows, evaluated time and policy version; manual health cannot erase a computed reason. Portfolio tabs include project and cross-project task timelines, workload and dashboards, with saved filters and permission-safe aggregates. Acceptance evidence: Create a two-level portfolio of 20 projects, including shared tasks and a private project. Change a blocker and completion through Tasks and see correct live rollups, at-risk flags and source drill-down; a limited stakeholder sees only authorized totals and no private project names. At a controlled clock, cross each default threshold independently, including exactly 20% overdue and just over seven days stale; observe the expected flag and reason, then resolve it and change the policy to inspect recalculation. Compare manual health separately. Inspect timeline/workload/dashboard tabs for the nested portfolio and confirm no double-counted work or hidden-project leakage.

PEG-014 — Goals and OKRs linked to execution. Company, team and personal goals support objectives, key results, owners, periods, numeric targets, check-ins and linked projects/tasks/subgoals. Progress can be manual, weighted work completion or an authorized numeric source, with explicit unit, calculation, freshness and override history. Missing/stale inputs are shown rather than promoted to success, and one task is not counted twice. Acceptance evidence: Create company/team/personal goals, complete linked work, update a numeric source and inspect computed progress and check-ins through Goals and API reads. Replay or age the numeric event, change permissions and inspect deduplication, stale labeling and restricted rollups.

PEG-015 — Stakeholder status with a publishing decision. Project and portfolio updates contain health, highlights, risks, decisions and next steps, source links and the covered time window. Drafts and published revisions remain distinct; a named human approves anything clients or executives will see. Subscriptions deliver approved updates to in-app, Slack, Teams, Nook and email audiences with per-recipient access and delivery outcomes. Later corrections remain visible in status history. A person can request a date-bounded AI status draft on demand, edit/reject it and explicitly publish the reviewed revision under PEG-074. Project/team announcement threads under PEG-010 appear with status history and retain threaded responses. Standing internal notification policy delivers an already human-approved publication without a second approval per delivery. Each published status-update revision has a permission-scoped comment/reply thread with mentions, follow/mute, edit/delete attribution and links to that exact revision; authorized recipients can discuss it without republishing the status or silently broadening the audience. Guest replies follow the reviewed share, and private/internal replies never leak through the client version. Acceptance evidence: Draft an update from three projects, exclude a private risk from a client's version, approve and publish exact content to each channel. Inspect subscriber receipt outcomes and immutable published history; revise a source before approval and require a new review rather than publishing stale or private material. Generate an on-demand project and portfolio status draft for a chosen window, reject/edit one sourced assertion and publish as an authorized human. Confirm one publication decision, expected internal deliveries and a still-pending client version until its exact recipient/content review. Publish a project and portfolio update, add member and guest comments/replies at 1440/390, edit/correct the update and retain revision-bound conversation/notifications. Revoke a guest, replay an email/chat reply and refuse hidden/internal comments across UI/API/digest without changing the publication decision.

PEG-016 — Capacity across all committed work. People have working hours, IANA timezone, hours/effort capacity, skills/role placeholders and time off from calendars and Willow or configured HRIS feeds. Workload includes cross-project commitments without double counting; tentative resource plans are labeled separately. Overload and unknown availability are visible, with drag-to-reassign and accessible alternatives, scenario comparison and reviewed reassignment. Capacity is hours/effort, while Gauge owns utilization economics. A member can declare dated full/partial-day out-of-office in Account → Availability without calendar/HRIS integration, with IANA timezone, working-time reduction and optional delegate/contact. It is labeled self-declared, not approved HR leave; assignment and mention pickers show an absence warning, workload removes the absent capacity and plans use it. Reasons stay private unless the member explicitly shares them. External approved leave overlaps by union, never subtracts twice; missing/stale feeds remain visibly unknown outside the known self-declared interval. A task retains one accountable owner plus permitted collaborators and explicit per-person effort allocations. Workload sums each person’s allocation once across multi-homing; task estimates, participant-hours and task counts have separate labeled totals. PEG-047/048 preserve source assignees and split/sum/per-person estimate semantics through reviewed mapping rather than dropping secondary people or guessing each person’s load. Acceptance evidence: Overload a person across three projects, add approved time off and an unfilled role, then inspect week/day capacity. Compare a staffing scenario and reassign a task through Workload to clear the real overload. A stale HRIS feed shows unknown freshness and a hidden task does not leak its title. Without any integration, declare three local out-of-office days and a half day, inspect assignment/mention warnings, daily workload and an agent plan excluding unavailable capacity; cancel/extend the declaration with attributed history. Overlay approved Willow leave and verify union/no double subtraction and no private reason leak. For a 10-hour monday item assigned to two people, reconcile Split as 5/5 and Sum as 10/10 participant-hours while preserving a single 10-hour task estimate. For a ClickUp 3/7 per-assignee estimate preserve both allocations and total 10; a multi-homed task remains one allocation per person. Missing source semantics are an explicit reviewed choice/repair before any lossless workload claim.

PEG-017 — Task time and approved timesheets. Timers and manual entries record person, project/task, date, duration, notes, source and estimate versus actual. One person cannot accidentally run overlapping timers; reconnect preserves intent without duplicate entries. Timesheets submit, return for correction, approve and lock; later corrections are attributed adjustments, not silent rewriting. Approved entries export to Gauge, Harvest, QuickBooks Time and CSV with stable external IDs and totals. Pegboard issues no invoice, rate card, payroll or monetary budget. Acceptance evidence: Track and manually enter time across two tasks, reconnect an interrupted timer, submit/return/correct/approve a timesheet and attempt a forbidden edit. Export to each named time service and CSV through official-schema edges, then reconcile exact durations and project/task references without duplicates.

PEG-018 — Included reporting and export. Cross-project dashboards offer configurable charts/widgets, saved filters, drill-through, completion/overdue/throughput/cycle-time/status-age, time/capacity, request and approval reporting. Scheduled reports respect recipient access, timezone and selected window; CSV, real Excel workbooks, Letter-size PDF and BI connectors expose the same snapshot and definitions. Included reporting is not a paid tier, and truncated exports are never called complete. The minimum widgets are horizontal bar, vertical column, line/time-series, donut, single-number, table, burn-up and burn-down; each offers a named measure, group/time bucket, date window, completion/timezone semantics and source-row drill-through. Historical snapshots and event-time changes retain scope added/removed, reopened work and baseline changes, so a burn chart cannot quietly rewrite past progress; counts or effort are selected explicitly. Google Sheets live reporting is PEG-077. A scheduled authorized report is available in-app and handed to its configured provider within 15 minutes of its scheduled local time, including DST policy and restart; provider acceptance and actual recipient receipt remain distinct. If provider delivery cannot complete within that bound, the recipient/owner sees an overdue/failed state and cause by the deadline, with safe recovery, rather than a false on-time success. The passing happy-path evidence includes controlled recipient receipt within the bound; client/executive report publication still requires the existing human publication decision, not a fresh review of each notification. Every outbound email follows PEG-084’s authenticated sender, qualified inbox delivery path, address suppression and provider-paced queue; provider acceptance remains distinct from actual Inbox receipt or human response. Acceptance evidence: Build a dashboard over three projects, reconcile each widget with its source rows and download CSV/XLSX/PDF. Schedule an authorized email report over a DST transition, inspect one correct window and delivery result, then deny a private-data subscription and verify no count or export leaks. For every named widget, use a dated work history with added scope, completion, reopening and a removed task. Reconcile every point/bar/slice/number/table row and both burn curves to source events over the selected range, including a DST boundary; inspect unknown history instead of invented trend points. Schedule a report across DST and restart, record scheduled instant, generation, provider acceptance and controlled mailbox receipt and require at most 15 minutes lateness in the available-provider case. Fail the provider and inspect the overdue cause by the same deadline; no duplicate delivery or unapproved client publication is labeled on time. Exercise PEG-084’s unauthenticated-domain block, signed bounce/complaint suppression and throttle/restart cases for this email path without duplicate, silent-drop or false-delivered outcomes.

People and daily access

PEG-019 — Free guests and scoped client views. Unlimited free guests receive project/task shares, viewer, comment-only, approve-only and editor/assignee roles and a branded client portal scoped to their client work. Internal-only tasks, fields, comments and files stay internal across views, reports, search, notifications and agents. Share previews show exactly what the recipient will see; expiry/removal revokes links and sessions promptly without deleting attributable historical decisions. A free guest Editor can create work within a shared project, assign/reassign among permitted project participants, be assigned deliverables, complete/reopen tasks, edit allowed fields, attach results and log/submit time on assigned tasks; an assignee-only guest grant limits edits to that task. Guest shares never permit member-directory browsing, invitations, permission changes or configuration edits beyond an explicit administrator policy. Existing commenter/approver-only restrictions remain selectable. The reviewed share records the inviting/adopting human, recipient, scope, exclusions and role; that decision authorizes in-scope ordinary system notifications/reminders/digests/reply routes under the conventions, subject to the guest’s own preferences and current server permissions. It grants no standing approval for agent-written messages, client-shared channel posts or outside-share data. Guest uploads have the same ordinary 100-MB limit/progress/resume and privacy-safe capacity state as members under PEG-082; an external approver may receive its separate narrow proof-revision upload grant only by reviewed share. Acceptance evidence: Share one client project with each guest role, preview their portal, approve an asset and remove a guest. Attempt internal record IDs, hidden fields, attachment URLs, exports and old links through UI/API; all refuse while the manager retains the historical signed decision and free-guest accounting. As a freelancer guest Editor, create a shared-project task, assign it within the shared participant set, complete assigned work, upload its deliverable and submit time. Refuse internal fields, unrelated projects, member enumeration and invitations through UI/API and email/chat actions; an assignee-only guest cannot edit a peer task, and comment-only/approve-only guests retain those exact limits. After the reviewed invite, assign a shared task to the freelancer and receive one email and push without another approval; receive a comment notice, due-soon reminder and digest omitting a planted internal-only field/comment. Queue another notice, revoke the share before send and prove it and its reply route are canceled. An agent-drafted chase to the same guest and a rule disclosure outside the share both remain pending exact review. Run PEG-082’s guest Editor and explicitly granted external proof-uploader web/iOS/Android cases; approve-only guests without that grant remain unable to upload or edit work.

PEG-020 — Server-enforced roles and administration. Owner, administrator, workspace/team manager, project editor, member, guest, analyst and scoped agent roles have explicit capability grants. Private workspaces, teams and projects and field-level hide apply at every read/write door; a UI hide is never authority. The admin console manages memberships, invitation policy, sharing, retention, exports, integration grants and an auditable access review. The last responsible owner cannot be accidentally removed. For members and guests alike, team/project grants include Admin, Editor, Commenter and Viewer in addition to approve-only/task-assignee scopes. Viewer reads only; Commenter adds comments/reactions/allowed attachments but changes no task values; Editor creates and edits work; Admin additionally manages project/team settings, field/status definitions, rules, templates and shares. Within each object, effective capability is the highest current valid direct/team grant; explicit internal-only field/task restrictions, agent scopes and personal-task privacy still cap it. The UI explains each granting path, and revocation recalculates immediately. Administrative custody powers do not turn personal tasks into ordinary browsable work. Team privacy, project visibility/defaults and request/decision lifecycle are first-class settings under PEG-083; resulting grants and refusal paths are enforced at every read/write door and included in the access review. Acceptance evidence: Use a role matrix through real sign-in, task/project routes, API, exports and webhook registration. Change permissions while a user has an open tab and show immediate server refusal and an audit event; try to remove the last owner and expose private fields through aggregate/formula responses, with no unauthorized effect. Give one member Viewer on project A and Editor on B: deny A comments/edits via UI/API while B task edits pass. Give a Commenter direct and Editor team grant on B, observe Editor access, then revoke the team grant and require immediate Commenter restrictions. B Editor cannot edit rules/fields/templates/settings that B Admin can; personal/internal-only work remains undiscoverable through either grant. Exercise PEG-083’s join/request/approve/deny/expiry/replay/deactivation matrix and compare exact role/effective-grant audit rows across UI/API.

PEG-083 — Discoverable teams and accountable access requests. Team Settings offers Public to workspace, Membership by request and Private. Active workspace members browse/search public and membership-by-request teams with only policy-discoverable names/details; public teams offer Join without approval at the configured default Viewer, Commenter or Editor level, never implicit Admin, and request teams offer Request to join. Private teams remain absent from unauthorized browse/search/counts; an opaque direct link can offer a blind request under the same no-existence-disclosure rules as refused work links, without making the team discoverable. Team Admins choose authorized request approvers and a responsible fallback. Project Share offers Private to members, Team only and Shared with workspace, with explicit team/workspace default access levels and a preview of effective grant paths under PEG-020. Workspace-wide sharing excludes guests; invited guests retain only reviewed current grants. Discovery, joining and inherited visibility grant no more than configured defaults, and explicit private tasks/fields retain their restrictions. Changing a team’s privacy never silently changes a project’s own visibility; a broadened project audience requires the existing share preview/authorization. From a refused task, project or portfolio URL, browser/mobile deep link or Slack/Teams unfurl, an authenticated active workspace member can select Request access, choose a requested level and add an optional message. A task request proposes the narrow task grant unless a human explicitly reviews a broader project grant. Undiscoverable targets show no private name, field, thumbnail, owner, membership or work count before approval; invalid and undiscoverable links use indistinguishable generic refusal/request acknowledgments so requests cannot enumerate existence. Guests/uninvited/deactivated identities have no internal request option or submission authority. PEG-073 private no-project tasks can never become access-request targets: no request object, approver delivery or grant is created, and ordinary refusals cannot disclose their existence. Requests create no share/invitation and authorize no work content before approval. Delivery routes to currently authorized object Admins/approvers with the project owner, then team Admin or responsible owner/admin as a configured fallback; fallback routing conveys only the minimum administrative request metadata and does not itself grant ordinary private-work access. Requests arrive in the inbox, configured email, PEG-071 Slack/Teams and PEG-079 mobile push with preferences and current authority rechecked; missing provider connections show PEG-080’s guide state while inbox handling remains available. A person with current delegation authority, including an authorized owner/admin or project owner, previews the exact requester, scope and chosen Viewer, Commenter, Editor or Admin grant and approves it, or denies with a safe optional reason. Admin approval requires actual authority to delegate Admin; a request, bot callback, mailbox possession or agent cannot confer it. Authenticated inbox/API actions, signed-in email decision pages and mapped chat/mobile actions use the same public decision door; a GET/prefetch, forwarded button or unverified reply never grants access. Every request, deduplication, expiry, decision and resulting grant is recorded under PEG-057 and appears in the PEG-020 access review with actor, target/scope, requested/granted level, reason and time. Active requests deduplicate by requester/target/scope, have a visible expiry (seven days by default, configurable and bounded by policy), and recheck requester activity, target/share policy, approver delegation and the preview revision atomically at decision time. Denied, expired, already decided, replayed or stale requests grant nothing; deactivating a requester or revoking an approver invalidates outstanding authority. A valid approval takes effect on the next authorized UI/API read without a manual membership workaround. PEG-046/081 import Asana’s three team privacy types, project visibility/defaults and exact direct/team/guest paths as reviewed staged settings, preserving private nondiscovery and refusing unreviewed audience expansion. Acceptance evidence: At 1440/390 browse/search all three team types as a new active member and guest. Join a public team at its configured Viewer default and open its team-visible project at that project’s stated default; no Admin or hidden-project access appears. Request a membership-by-request team with a message, receive email as its chosen Team Admin, sign in from that email and approve Editor; UI/API reflect only that reviewed scope immediately. Paste a private project link into Slack as a second member: its refused unfurl/page contains no private name/fields/counts but offers Request access; approve Commenter from the project Admin’s inbox and prove read/comment succeeds while edit/settings fail in UI/API. Repeat narrow task and private portfolio requests, delivery/decision through connected Teams and mobile, denial with a safe reason, and project-owner/team-Admin fallback without granting unrelated access. Choose each of Viewer/Commenter/Editor/Admin as an authorized delegator, refuse an unauthorized Admin delegation and inspect exact grants/audit/access-review rows. Concurrent duplicate submissions produce one pending request; expire it, replay approved/denied decisions, deactivate the requester, revoke the approver and change the previewed policy in separate cases: every stale action grants nothing. Mail GET/prefetch, forwarded or unsigned callbacks cannot approve. Compare invalid and undiscoverable target refusals/acknowledgments through UI/API/unfurls without private metadata or existence leaks. A guest sees no request option and cannot POST an internal request; a private no-project task creates no request, notification or grant, even when its ID is submitted. Import an Asana fixture containing all three team privacy types and all three project visibility levels, mixed defaults and direct/team/guest grants through PEG-046 and the full PEG-081 account journey; reconcile source/effective permissions, review staged audience decisions and repeat directory/join/refusal checks after cutover with no broadened share.

PEG-021 — Enterprise identity and US custody. Native sign-in coexists with owner-configured SAML/OIDC through Auth, Okta, Microsoft Entra ID and Google, plus SCIM provisioning/deprovisioning, MFA, SSO-only enforcement, session duration, device/session listing and revocation. Provisioning never infers permission from email domain alone. US data hosting covers work records, attachments, backups and configured agent/provider processing with documented exceptions requiring explicit owner consent; provider residency restrictions are engineering work. Settings → Sign-in provides the browser-guided PEG-080 Continue with Google and Continue with Microsoft setup, without hand-authored SAML/OIDC config. Verified source identity must match an active invited/local member; invitation-only admission never broadens to a domain-signup policy. The native mobile apps offer the same configured methods in the system browser under PEG-079; disconnected methods name the missing connection and guide rather than silently failing. Acceptance evidence: Qualify each named IdP using its official schema or sandbox, sign in under enforced SSO/MFA, then SCIM-deactivate a member and refuse every active session, token and mobile write within five minutes. Inspect actual deployment/storage/backup placement and configured processor routing rather than inferring US custody from an app URL. As a non-technical owner enable each Google/Microsoft method through the timed PEG-080 guide/live check, sign in an invited member and find their existing identity. Refuse an uninvited, unverified-email, wrong-tenant or wrong-issuer account and show the named connection/recovery link if the method is not ready.

PEG-022 — Native iOS and Android daily work. Installable native apps provide My Tasks, inbox, search, assignments, comments, attachments, approvals and push with deep links. Offline queues preserve pending edits and reviewed asset revisions, show unsynced state and resolve conflicts on reconnect; offline approval remains pending until the server validates current authority and version. Local caches and push payloads honor revocation and privacy. Run Edit Run’s release lane owns app builds, signing, App Store/Google Play publication and APNs/FCM service credentials; Run Edit Run operates the scoped push relay in PEG-079. The installation owner never needs an Apple/Google developer account or app-signing/push credentials. Member device consent and the owner’s once-per-installation relay registration remain explicit browser/app actions. Native apps additionally quick-add tasks and projects, complete/reopen work, edit due/start dates, assignee, status and every permitted custom field, browse project list/board/calendar and read project status/dashboards. Camera/photo pickers attach deliverables with visible upload state. Offline creation, completion and edits queue with one causal history each; a cached authorized project directory allows creating a task in a project never opened on that device, without pretending its uncached tasks are readable. Newly created offline projects/tasks remain pending authorization until reconnect. iOS/Android home-screen widgets show a permission-scoped Today list and quick-add entry; dark/light/system appearance and private notification previews follow user controls. Public-store installation, invitation/QR/URL binding, same-as-web native/IdP sign-in, app-version compatibility and production push qualification are mandatory PEG-079 journeys in addition to all offline and daily-work journeys here. Native camera/photo/video and attachment/proof uploads meet PEG-082’s ordinary 100-MB limit and persist resumable progress across app restart. Acceptance evidence: On real iOS and Android clients, open assigned work from push, comment and queue an approval offline. Reconnect for a valid sync, then repeat after an asset change and after deprovisioning; inspect conflict/refusal, no duplicate decision and no accessible revoked cache. Web screenshots alone do not satisfy this clause. On both real OS clients, cache the authorized project directory without opening project B, go offline, create a task in B, complete a cached task in A and change another due date. Reconnect and inspect exactly those three changes with one history each. Also create/edit a project, reopen work, change assignee/status/custom fields, attach a camera/photo item and read list/board/calendar/status/dashboard. Test denied reconnect, widget quick-add, dark appearance and lock-screen privacy with no unauthorized cache access. On stock iOS/Android devices, follow the public listing and installation invitation as PEG-079 requires, sign in to the fresh installation and receive a real assignment push; none of these steps asks the owner or member for developer tools or a developer account. On both native apps complete PEG-082’s exact-limit, interrupted-resume, pre-transfer oversized refusal and shared-proof upload cases.

PEG-079 — Public mobile apps and Run Edit Run push service. Run Edit Run’s release lane builds, signs and publishes the Pegboard iOS app to the public App Store and Android app to public Google Play under Run Edit Run’s developer accounts, and operates their production push relay. For every supported Pegboard release it tests and publishes compatible apps; the owner distributes no build and holds no Apple/Google developer or APNs/FCM credential. Each app’s signed compatibility manifest, store-support notes and installation-binding screen state its exact oldest supported Pegboard installation semver/API generation. For both launch apps that oldest version is the first released Pegboard installation edition: the exact full version from that launch’s edition.json is compiled into each app’s minimumInstallationVersion, not left as “latest” or an unfilled placeholder; later app builds declare their actual oldest qualified version separately for iOS and Android. An older/unsupported installation shows “This Pegboard app needs installation {minimumInstallationVersion} or later. Ask your owner to upgrade” with the current/required versions and owner-upgrade link; it cannot silently bind or mutate incompatible data. Members install the public app and enter their HTTPS installation address, scan its Settings/invitation QR or open its verified invitation deep link, see the installation identity/origin and confirm the binding. Native email links and configured Google/Microsoft/Auth/enterprise IdPs use the system browser and return a one-time installation-bound sign-in code to the app; tokens never travel in untrusted deep-link query strings. A member from another installation, wrong-origin invitation, replayed code or revoked installation cannot obtain the first installation’s session/data. Run Edit Run operates the relay under the same custody limits as Vector MOBILE-004/MOBILE-002: Settings → Mobile links relay terms, its data list/status page and compatibility matrix. The owner confirms one registration; its installation key is sealed/encrypted at rest, never returned in ordinary reads/logs/archives, immediately rotatable/revocable, and authorizes only that installation’s registered devices. Devices register through their signed-in installation; it submits only authenticated, signed relay requests and the relay refuses unsigned, cross-installation, deregistered or revoked sends. Allowed payload fields are the opaque device registration, work-item identifier, optional item title and actor display name, notification kind and installation-scoped notification ID; no description, comment, customer/contact data, credential or attachment may be included. ID-only is the private default and omits title/actor; the app fetches authorized details directly from its installation after waking. Optional title/actor previews require the member’s explicit setting and current record/share access, with disallowed sensitive content omitted. The relay stores only registrations/installation authority and redacted delivery metadata, forwards via APNs/FCM and retains no notification payload after forwarding; relay data/processing posture is declared under PEG-021/065. The owner can disable push installation-wide; sign-out, SCIM deprovisioning, device-token revocation, installation revocation and share removal stop matching pending pushes and direct quick-action authorization. Connected healthy delivery is submitted to the relay within five seconds of its inbox event outside the recipient’s quiet hours, with provider acceptance distinct from device receipt; deferred notices send once when allowed. Acceptance evidence: A tester with a stock iPhone and stock Android phone and no developer tools installs from the real public store listings, follows a fresh PEG-055 installation’s reviewed invitation/QR/URL, confirms its origin and signs in by native email link and each configured web IdP. The owner’s recording shows one Settings confirmation and no Apple/Google developer/signing/push-console step; receive one real assignment push per enabled device through the production relay and act directly on the installation. On every release also qualify the signed TestFlight/Play internal-testing builds against the declared oldest supported installation and a current edition; verify each app’s exact minimum value and the named upgrade message/refusal against an older installation. A relay fixture built from the published relay schema rejects unsigned, cross-key/cross-device, revoked and replayed attempts; capture only allowed payload fields, ID-only omission and no retained payload after forwarding, with no planted comment/customer/attachment content. Cross-installation invitation/code replay cannot read data; deprovision/sign out and confirm deregistration, stopped push, denied quick actions and inaccessible revoked cache. Test quiet hours and share revocation before queued delivery without duplicate notices.

PEG-076 — Installable desktop access and notification control. A browser-installable desktop app runs on macOS and Windows with a standalone window, deep links, keyboard quick-add, the same project/task/report permissions and OS notifications. Installation/update paths are browser-guided, visibly offline-capable to the supported PEG-023 queue, and sign-out/revocation clears local authority. OS and browser notifications require consent, use private previews, respect DND/mute and cannot expose work after revocation. Light, dark and system themes preserve contrast, chart legibility, proof version cues and focus at both widths; appearance preferences synchronize per user without changing shared project state. Desktop quick-add/task/comment/proof uploads meet PEG-082’s 100-MB limit with visible durable progress/resume and pre-transfer provider-link alternative. Acceptance evidence: Install the desktop web app on macOS and Windows from its actual browser door, quick-add a task, open an allowed task deep link and receive an assignment notification. Deny notification permission, mute/DND, revoke the session and inspect suppressed/private notifications and denied cached/deep-link reads. Switch light/dark/system, inspect the changed screens at 1440/390 and run the same keyboard/contrast/reflow checks; an app update preserves pending edits or shows a named conflict. Run PEG-082’s exact-limit/one-byte-over and interrupted upload on each installed desktop app, preserving one version across update/restart.

PEG-023 — Speed and continuity at buyer scale. A 10,000-task project supports p95 interactive first-list load under one second and filter response under 300 ms on a published, reproducible US desktop/phone network and device profile. Measure actual authorized retrieval, permission filtering and rendering, including cold and warm runs, with 500 members and realistic custom fields, comments and dependencies. Optimistic edits show pending/error states and survive brief disconnections without silently overwriting newer work. Limits and degraded service are visible. The minimum fixed reference profiles are a four-core Intel Core i5-8250U laptop with 8 GiB RAM/current stable Chrome at 1440 CSS pixels on 20 Mbps down/5 Mbps up with 40 ms RTT, and a Pixel 6a with 6 GiB RAM/current stable Chrome at 390 CSS pixels on a stated 4G profile of 10 Mbps down/2 Mbps up with 80 ms RTT. Timing uses browser navigation start to the first real interactive authorized task page (including asset/network startup) and input event to painted filter results; 100 independently reset cold and 100 warm samples on each profile use the same stated dataset and p95 bars. Faster hardware or a less constrained network cannot substitute for these acceptance profiles. Acceptance evidence: Use the built app with the stated dataset and published timing method at both widths; measure loads/filters, edit during disconnect and concurrent remote change, reconnect and verify persisted work or an explicit conflict. Record actual timings and profile; a skeleton or cached empty list is not a pass. Measure both fixed device/network profiles with those sample counts and time origins at the 10k-task/500-member dataset; publish observed p95 cold/warm loads and filters, device/browser versions and shaping settings, with no skeleton/empty-cache shortcut. Any profile that exceeds the existing one-second/300-ms bars remains unmet rather than redefining the profile.

PEG-073 — Private personal work and a predictable day. My Tasks creates no-project tasks private to their owner, with user-defined sections, reorderable section/task ranks and a visibility preview before any project share or collaborator is added. Other members, guests and administrators cannot discover them through ordinary lists, search, API, notifications or agents; exceptional owner custody/export/retention actions remain explicit audited administration under PEG-058/059/065. The default incomplete-task groups are Overdue, Today, Upcoming and Later in that order: past due; due on the user’s current local day or manually marked Today; due in the next seven local days; then remaining/no-date tasks. Overdue wins over Today. Within each default group sort by due instant/date ascending, no date last, then urgent/high/normal/low priority, creation time and immutable ID. Date-only due values use the end of the named local day; manual ranks or saved custom sorts override only when visibly selected. At local midnight, due-tomorrow work becomes Today without changing its project section or deadline. User-defined section rules can promote or move personal work with a logged, reversible result. Acceptance evidence: Create a private no-project task and custom section through My Tasks, then search/read its ID as owner, another member and an administrator’s ordinary session: only the owner succeeds. Inspect default order using overdue, today, equal-date priorities, next-seven-day and no-date tasks; mark Today manually and compare with the stated tie breakers. Advance local midnight across DST so due-tomorrow work promotes once, set a manual section rank, reconnect and verify persistence. Adding the private task to a project requires a visibility preview and grants only the reviewed access.

PEG-032 — People leave without orphaning work. Member removal previews owned tasks, projects, portfolios, goals, approvals, rules, scheduled updates, connector custody and delegated agent work. A responsible administrator chooses a replacement or explicit unassignment for every set; concurrent changes invalidate the review. Access revocation is immediate, unsafe sends stop and historical authorship remains attributable or privacy-anonymized. Transfers never impersonate the departed person's approval. Acceptance evidence: Remove a manager with active projects, queued sends and pending approvals through Admin. Review each affected set, transfer work and inspect revoked sessions/keys, canceled old sends, new accountable owners and preserved history; a concurrently added assignment forces a fresh review.

PEG-045 — Identity lifecycle and access review. Domain verification, invitation acceptance, group-to-role mapping, SCIM user/group change, guest lifecycle and organization ownership transfer have an explicit preview and permission-safe default. Deactivation cancels scheduled personal/agent authority and invalidates pending approval links; reactivation does not resurrect old tokens or share links. Admins can inspect and revoke third-party app grants and download an access review without exposing credentials. PEG-083’s pending access requests are part of deactivation and access review: reactivation never revives a prior request’s approval authority. Acceptance evidence: Provision and move a user between IdP groups, map a restricted role, invite an external guest and inspect the access review. Deactivate/reactivate the user, revoke an app and transfer installation ownership; old sessions, API/MCP keys, proof links and personal automations stay invalid until explicitly renewed. Deactivate/reactivate a pending requester and revoke a pending approver, then refuse their stale access decisions and inspect the access review.

Connections and public automation

PEG-025 — Calendars and task time blocks. Two-way Google Calendar and Outlook Calendar connections map task due dates and scheduled work blocks explicitly, respect free/busy permissions, work hours, timezones, holidays and locked meetings, and distinguish a deadline from effort reserved before it. Event moves update only the mapped task schedule under authorized change policy; provider edits never silently approve a team deadline change. Cancel, disconnect, recurring-event exceptions and concurrent edits reconcile with visible conflicts. Dial owns booking links. An optional read-only iCalendar/ICS subscription for My Tasks or selected project work provides stable UIDs, timezone/date-only semantics and update/cancel events, with an expiring revocable scope-bound capability whose URL is treated as a secret. Users preview exported fields; guest feeds stay within reviewed shares, and removing access stops further reads without claiming to erase events already cached by a calendar client. Acceptance evidence: Through Calendars, schedule a task into free time on each provider using Google event and Microsoft event schema edges. Move/delete the event, cross DST and simulate a simultaneous task edit; inspect exact mapping, preserved deadline, conflict state and one event after replay/reconnect. Subscribe Apple Calendar and a second ICS client to a selected project/My Tasks feed, update a due date and cancel a task, then inspect stable UID and correct dates/cancellation without duplicates. Revoke the feed/share, require failed later fetches and verify no hidden task/field or raw capability enters logs or archives; acknowledge previously cached client copies explicitly.

PEG-026 — The full integrations hub. Owners install, scope, configure, test and revoke Slack, Teams, Nook, Gmail, Outlook, Zoom, Google Meet, Google Calendar, Outlook Calendar, Google Drive, Dropbox, Box, OneDrive/SharePoint, Chest, Figma, Adobe Creative Cloud, Canva, GitHub, Jira, Vector, HubSpot, Salesforce, Orbit, Buoy, Gauge, Harvest, QuickBooks Time, Auth, Okta, Entra ID, Google identity, Zapier, Make, Crank, Tableau, Power BI, Pencil, Willow, Linen and HappyToHelp adapters. Each names supported directions/actions, required grants, data custody, app approval and current connection health; arbitrary workflow composition belongs to Crank. Integration cards cannot stand in for a working adapter. PEG-071 defines complete in-tool chat actions, feeds, notifications and Gmail/Outlook sidebars; PEG-077 adds Google Sheets, Loom, Miro, Zendesk, Freshdesk, Intercom, DocuSign, Calendly and YouTube/Google Docs embeds. Every added adapter follows the same installation, authority, health and qualification requirements, with its declared direction and handoff; it does not merge the sibling’s specialist job. PEG-080 owns the browser-only registration/distribution guide and measured 15-minute qualification for Slack, Teams, Google Workspace and Microsoft 365, with tenant-local apps/clients rather than a Run Edit Run shared OAuth broker. All connected subfeatures, pending provider approvals and member identity-link requirements are separately visible; one working Calendar scope cannot falsely enable Gmail/Drive or sign-in. PEG-085 additionally requires Run Edit Run-published native public Zapier/Make apps, guided per-installation scoped connections and ready-made triggers/actions/templates; generic webhook recipes alone cannot satisfy distribution. Acceptance evidence: Install every named adapter through the hub and exercise its named job in PEG-007/008/016/017/021/025/039–045: source event/read → allowed Pegboard effect → provider acknowledgment or authorized return update. Also execute Zapier, Make and Crank task-create/task-change webhook recipes and a Willow time-off update. For each, record schema/sandbox or live-account qualification, denial, disconnect and reconciliation; no unchecked listing passes. Qualify PEG-071’s chat and mail round trips and each PEG-077 service’s declared journey, including rejection/revocation/replay, rather than treating capture or an integration logo as sufficient. Complete all four provider guides against official-schema network edges plus one live connection for each, then use each sign-in/chat/mail/calendar/file door required by PEG-080. A disconnected subfeature explicitly names the missing connection and guide rather than presenting a nonfunctional control or silently dropping a chase. Find/connect both PEG-085 public apps and run the native-template/live-account journeys in addition to the retained webhook recipes; unapproved/private listings remain unmet.

PEG-080 — Guided owner-registered provider apps and first live connection. Settings → Connections guides the owner or an explicitly delegated integration Admin through separate Slack, Microsoft Teams, Google Workspace and Microsoft 365 registrations using the owner’s provider organization/accounts. It shows not connected, connecting, awaiting provider/admin consent, connected and needs attention per client and feature. For the chosen installation origin it generates exact authorized redirect URIs/JavaScript origins, request/event/interactivity/sidebar URLs, least-needed scope names with purpose, subscription/consent settings, complete manifests/packages and safe copy/open-console controls; no one hand-writes a manifest, invents a URL/scope or runs CLI code. Step-by-step links lead to the correct provider consoles and back to the saved guide. A provider-displayed client ID/secret or app configuration token may be copied once into a sealed field; actual access/refresh tokens are acquired in the browser OAuth code flow, encrypted at rest, origin/tenant/scoped and excluded from archives/logs. Guide progress survives reload and credentials can be rotated/revoked without losing work links. The page states who registers the client, which provider receives which data, grants/custody under PEG-021/065, and that no Run Edit Run-operated shared OAuth broker handles these connections. The mobile push relay is a separate service and never receives provider OAuth credentials or chat/mail/file content. Slack uses a buyer-owned Slack app created from the installation-generated manifest via the provider console or apps.manifest.create, then OAuth installation, request/event URL verification and a signed message/action test. Teams uses the buyer’s bot/Entra registration and generated Teams app package with installation messaging endpoint, scopes/valid domains and icons; the guide covers browser registration, tenant custom-app upload/deployment and a real bot/action callback. Google Workspace guides the owner through their Cloud project/consent and web OAuth client for Continue with Google, Calendar and Drive, plus deployment of the generated Gmail sidebar add-on into their authorized Workspace domain; exact generated redirect URIs/scopes and required publication/domain/internal-testing settings are shown, with no implied public Marketplace listing. Microsoft 365 guides Entra client registration and consent for Continue with Microsoft, Outlook Calendar and OneDrive/SharePoint plus the generated Outlook add-in manifest’s tenant deployment; Teams registration and deployment are explicitly linked but separately tested. Member-owned access uses a per-member Link account browser consent step after installation-level connection; a bot or tenant admin token never impersonates an unlinked member. Each feature is enabled only after provider credentials/grants validate and the owner completes its live round trip; denied consent, missing scope, bad callback, client rotation, blocked app policy or pending provider approval shows its precise cause and browser repair step. External provider review is not a success state or an excuse to drop an adapter. A non-technical authorized owner following each guide connects each of the four providers in at most 15 elapsed minutes from Open guide to successful live test, including required console/account/client/package steps and provider waits. Qualification includes a scripted walkthrough against fakes generated from the provider’s official app-registration/OAuth/event/add-on schemas and one real live connection per provider, recorded separately with timestamps/screen recording and redacted request/event evidence. Feature tests cannot be skipped because the broader tenant is connected; pending external approval or an exceeded time bar leaves that connection obligation unmet. The baseline PEG-055 installation remains usable while optional provider connections are pending, and the separate 15-minute clocks do not replace its 30-minute installation/AI bar. Every dependent surface—Continue with Google/Microsoft, Slack/Teams actions/unfurls, Gmail/Outlook sidebar, calendar sync/time blocks, Drive/OneDrive picker, mobile IdP sign-in and PEG-030’s per-channel chase job—names the missing or broken feature/connection and links to its saved guide. Blocked jobs stay visible without fabricated success, silent fallback to another channel or unapproved sends; reconnect retests and resumes only still-authorized deduplicated work. For Continue with Google, show whether this owner-registered client is Internal-only or configured/qualified for External users. An invited guest with a personal Gmail or another company’s Workspace account may use it only if that client admits the account and verified subject/email matches the existing invitation; external-client publishing/consent/verification is guided engineering work, not implied by internal Workspace setup. An Internal-only denial names that restriction without revealing membership and offers native email-link/passkey sign-in immediately; it never blocks an otherwise invited guest’s native access. Required external-user configuration and denied/test/unverified-app states are explicit and do not silently swap to a shared OAuth broker. Microsoft add-in deployment measures two visible timestamps: owner console/package work and actual add-in availability/live test. The existing 15-minute bar remains total elapsed time including provider waits, not a paused operator-only clock. If Microsoft’s documented propagation takes up to 24 hours for a new deployment (or longer update propagation), show Awaiting Microsoft deployment, submission/time/affected users and next check; no connected-sidebar or timed-pass claim is made until an actual client live test succeeds. Record active owner minutes separately for diagnosis. A pending propagation run exceeding 15 minutes leaves that timing qualification unmet, with the provider constraint explicit; it does not drop Outlook support, extend the bar silently or weaken a test. Acceptance evidence: At 1440/390 the PEG-055 non-technical tester completes four timed browser-only walkthroughs using official-schema provider fakes, then one live Slack workspace, one live Teams tenant, one live Google Workspace and one live Microsoft 365 connection, each within its 15-minute bar. Begin without the provider apps/clients already registered and retain registration/package/consent and signed callback/test evidence without secrets. After Slack setup, an invited member links their own account and comments/completes one task from Slack. After Teams setup, install its generated tenant app and receive/act on a task notice. After Google setup, an invited verified member signs in and uses Calendar, the deployed Gmail sidebar and Drive; after Microsoft setup, do the same for Microsoft sign-in, Outlook Calendar/sidebar and OneDrive. Uninvited and cross-tenant identities are refused and member setup-management attempts are denied. Disconnect each feature, visit every named dependent surface and trigger its chase/job, and verify the specific missing-connection guide state, no provider call or false successful job, ordinary work continuity and safe single resume after repair. Repeat denied consent, bad redirect, missing scope, admin app-policy rejection, expired client and origin change without inventing success or restarting a duplicate registration. Invite a Gmail guest and a guest from a second Workspace domain. With an Internal-only client show the named restriction and complete native sign-in; configure/qualify External access through the guide and sign each into the same invited identity, refusing an uninvited/wrong-subject account. Simulate Google publication/test-user/consent restrictions with official schemas and inspect recoverable native access, not a broken invite. For Microsoft, measure a fast live connection against the original 15-minute wall clock; separately simulate an add-in unavailable for 24 hours after successful tenant submission. Show pending propagation with owner-work and wall times, preserve ordinary work/native mail sign-in, perform the real sidebar test when it appears and record that this delayed run did not meet the 15-minute qualification. Never count the submitted manifest alone as a working sidebar.

PEG-071 — Work inside chat and mail tools. Slack, Teams and Nook show permission-filtered task/project link unfurls with live status/freshness, personal My Tasks and cited status queries, comment/complete/reopen/assign/due-date controls and human proof approval tied to the exact version. Authenticated action callbacks map the actual human to a current Pegboard identity and recheck rights at execution; a bot token or channel membership alone grants no work authority. Project-to-channel feeds and personal assignment/mention/approval notifications follow configured audience scopes and preferences. PEG-012 rules can post to a named internal channel/person under standing policy; a fixed personal system notice to a current guest about shared work uses the reviewed share and guest preferences without another approval, while a client-shared channel/feed, arbitrary guest post or unknown audience waits for exact disclosure approval. Gmail and Outlook installed sidebar add-ons create/search/link tasks from an open email with project, assignee, due date and chosen attachments. Explicit per-thread reply sync retains provider/thread/message IDs, a visibility preview, stop-sync and deletion controls; later replies become attributed source-message comments once, without automatically enrolling external authors as members. A private chat recipient linked to a guest is not treated as a client-shared channel; it receives only the guest’s personal authorized notices. Sending any project feed to a shared channel still requires review even when all currently known guests have project shares. Owner app registration, tenant sidebar deployment and first live connection are PEG-080 requirements; ordinary members only link their own authorized account afterward. The Slack/Teams and Gmail/Outlook UI and sidebar entry points display a named missing-connection guide state until the corresponding feature test passes, including partial tenant consent or revoked credentials. A refused private unfurl/deep link offers PEG-083’s no-leak member request door; connected chat request notifications and authenticated human decisions preserve exact scope/role and current delegation. Acceptance evidence: In each installed Slack/Teams/Nook app, unfurl a task, list My Tasks, query a permitted project, comment, complete/reopen, assign and preview/apply a due-date change under current rights. Link a project feed and receive one personal notification and one rule-triggered internal-channel post without per-message approval. Human-approve PDF v2 in chat, replace it with v3 and refuse the old button/replay. Revoke the actor and inspect refusal and non-leaking private unfurls. In both Gmail and Outlook sidebars create a task from an open email with all mapped fields, enable reply sync, deliver/replay a later reply and see one source-attributed comment/attachment; stop sync, revoke mail access and verify no subsequent ingest or automatic external share. Receive a fixed personal assignment/proof notice as a scoped guest without per-message approval in each configured chat adapter; remove the share and cancel a queued notice. Keep an agent-composed guest chase and a feed/rule post to a client-shared channel pending exact review even when the guest can see the source task. Start with unconnected Slack/Teams/Gmail/Outlook and inspect explicit connection/guide states at each tool entry point and Pegboard action door; finish PEG-080’s guide and first live test, link a member account and perform the actual in-tool actions. Revoke the client, keep the intended action visible as blocked and reconnect without a duplicate task/comment or disclosure. Run PEG-083’s Slack refusal-to-request/inbox approval and Teams request/decision, compare guest/invalid/private-task refusals and reject replayed or unmapped decision callbacks.

PEG-085 — Published Zapier and Make apps for every installation. Run Edit Run’s integrations/release lane builds, submits, publishes and maintains the official Pegboard integration in Zapier’s public app directory and the approved Pegboard app in Make’s public catalogue, including versions, support links and ready-made Zap templates/Make scenario blueprints. Provider review, account ownership, app verification and ongoing compatibility are Run Edit Run engineering obligations; an invite-only development app, private blueprint or generic Webhooks/HTTP module cannot satisfy public distribution. Each public app’s connection screen accepts the owner-run installation’s exact public HTTPS base address, displays/validates that product identity/API compatibility and uses a browser-guided scoped credential grant from that installation. API-key authentication is supported through PEG-027’s dedicated revocable automation credential: an authorized Admin opens Connections → Zapier or Make, selects only allowed projects/fields/actions, reviews access and generates a one-time display to paste into the platform’s secure connection field. An OAuth variant may use a documented per-installation client instead, but no shared Run Edit Run OAuth broker is required and no ordinary member password/provider secret is requested. The connection binds installation origin, credential sponsor and scope, with secure platform credential storage, no cross-installation token reuse/redirect forwarding, no private-network fetch target or arbitrary remote credential destination and no central copy of work content at Run Edit Run. The connection page states Zapier/Make’s processor/data custody and the owner’s current plan/task-credit requirements before consent. The native trigger/search/action catalogue includes new task, changed task/status/due date, completed/reopened task, new comment, find task/project by stable reference, create task/subtask, update permitted fields/date/assignee, add comment and multi-home to a permitted project. Dynamic permitted project/field/person selectors, sample output, schema/units and structured permission/validation errors replace handwritten payload/URL recipes. Templates cover form/Sheets request → task, new Pegboard task → permitted Slack notice, completed task → external record update and cross-tool comment/task follow-up, with selected mappings and no imported recipient authority. Triggers support scoped subscription or documented checkpointed polling with stable event IDs, deduplication and missed-event recovery; platform retries/out-of-order events, rate limits and reconnect cannot duplicate work. Searches/actions read and mutate only the current grant; human proof decisions, new access/disclosures and AI/agent scheduling retain their contract approval doors, and a connected app cannot self-activate a Pegboard rule or impersonate a human. Existing Zapier/Make task-create/task-change webhook recipes remain additional public-API doors. The migration guide helps replace Asana/monday.com/ClickUp steps using mapped local IDs/fields, previews new recipes and tests them while inactive; switching providers never silently enables an old scenario or promises an impossible automatic transfer of third-party ownership/plan entitlement. Platform plan charges/task credits, premium classification and polling intervals are shown as actual published provider terms under PEG-061, not an unsupported promise of a free tier. General cross-app orchestration stays with Zapier/Make or Crank. Acceptance evidence: In real Zapier and Make accounts find Pegboard in the public directory/catalogue, record Run Edit Run’s publisher identity/listing/version and create a native Pegboard connection to each of two separate owner-run installations through its address plus scoped credential guide. A buyer writes no generic webhook URL, custom JavaScript or JSON payload for the native cases. From published templates/blueprints, map a Google Sheets/form request into one task, react to its change/completion into one permitted Slack/external record update and add a comment/subtask through each platform’s native modules; exercise every listed trigger/search/action with source IDs and a limited project/field set. Use official-schema platform/network fakes for throttle, polling checkpoint gap, duplicate/out-of-order delivery, lost acknowledgment and restart, and separately qualify the same round trip live in both platforms. Revoke/rotate credentials and show an actionable failed/reconnect state, preserve event watermarks and resume each still-authorized effect once. Refuse a hidden project/field, wrong installation, unsafe base address, redirect to another origin, unauthorized share/proof decision and AI-produced date action without exact human approval. Rebuild a representative inactive Asana Zap and Make scenario using PEG-046/081’s mapped local IDs, compare trigger/field/output mappings and activate only by the authorized buyer’s explicit action. Compare actual required platform plans/classification/task credits with the estimate; a private/unapproved app or generic Webhooks/HTTP workaround leaves this distribution clause missing.

PEG-027 — Public API, events and MCP. A documented versioned REST API exposes permitted work CRUD, views/search, project/portfolio/goal reporting, time, approvals, import/export and automation configuration with pagination, concurrency checks, idempotency and structured errors. Signed webhooks offer subscriptions, event IDs, replay and delivery history. An MCP server lets Claude, ChatGPT, Gemini, Cursor and other compatible external agents use the same user/bot permission model, with declared tools and approval-required operations. Neither transport can elevate an agent into a human approver. API/MCP resources also cover personal tasks/sections, tags, cross-project views, announcement threads, custom task references, duplicate-merge previews and custom-agent definitions under their exact human/agent permissions. Acceptance evidence: Using the published OpenAPI and MCP doors, create/update a task, paginate a project, read a report and receive a signed task event. Connect each named client, deny out-of-scope access, stale edits, expired credentials and forged webhooks; replay a valid event without duplicate effects and refuse an agent attempt to approve itself. List a personal task as its owner and deny the same ID to an administrator’s ordinary key; try a guest-editor mutation and Viewer comment, proving transport-independent permission results.

PEG-038 — Connector failures are recoverable work. Connections show last success, freshness, required permissions, cursor, failed object and actionable owner. OAuth refresh/rotation, webhook verification, backfill, polling gaps, provider rate limits and schema changes preserve stable source IDs and causal order. A durable outbox separates local commit from external delivery; proven-unaccepted requests may retry, ambiguous submissions reconcile before retry. Reconnection repairs missed changes with a preview when overwrites or external sends would occur. Connection health includes provider-app identity, consented subfeatures and the current generated installation origin; a changed origin/secret requires guided provider callback/package repair and retest before dependent actions resume, without discarding existing source IDs or member links. Acceptance evidence: Through an installed connector, create work while its provider returns 429, later 401 and then loses a response; restart Pegboard, reconnect and replay events out of order. Inspect visible health and exact per-object outcomes, one intended effect, retained later edits, no leaked credential and no false delivered state. Change the installation origin or rotate a provider client secret during a timed-setup fixture, repair exact callbacks/manifests through the saved guide and require a new live event/test before connected status. Preserve source links and queued action identity, and expose unresolved provider-policy failures.

PEG-040 — Engineering handoff without a second issue tracker. A business task links to existing or explicitly requested Vector or Jira issues and GitHub issues and pull requests with stable external IDs, backlinks, owner/status mappings and sync direction. Engineering cycles, code reviews and release flow remain in Vector and the code host. An engineering closure updates the linked business indicator but does not automatically satisfy business acceptance or approve a launch. Acceptance evidence: Link one campaign dependency to each of Vector, Jira and GitHub, update its source status and reconcile it in Pegboard, then return an authorized mapped update. Deny an unmapped closure, revoke a source grant and replay the event; retain one link, visible stale state and a still-pending human launch approval.

PEG-041 — Commercial and service work becomes delivery. Won Orbit, HubSpot and Salesforce deals, selected Buoy customer-success milestones and Linen/HappyToHelp ticket escalations can create a delivery project from an approved template with owner, client share preview, due expectations and source backlink. Configured status/milestone updates return to the source, with explicit human approval for customer-visible content. CRM, account health and ticket SLA state remain at their source; reopened or duplicate events cannot duplicate projects or erase the original commitment. Acceptance evidence: For each of the six source products, deliver a qualifying event through its authorized schema edge, review/adopt one project and return a permitted delivery-status update. Replay, reopen, decline the handoff and fail the return write; inspect one project, source identity, restricted customer fields and accountable unresolved exception.

PEG-042 — Reconciled time handoff to specialist systems. Gauge, Harvest and QuickBooks Time adapters map people, projects/tasks/job codes and approved duration entries with external IDs, approval state and adjustment provenance. Buyers preview exact totals, mapping gaps and exclusions, choose the system authoritative for each field and reconcile acknowledgments, rejection and later corrections. Pegboard never fabricates billable rates, invoices, margin or payroll authorization; Gauge owns those economics. For PEG-046’s Asana Timesheets & Budgets handoff, route exact source budget/rate/billable/currency/effective-date artifacts to Gauge’s reviewed move-in/mapping process (RATE-001/002, BUDGET-001 and economic reconciliation), with stable Pegboard task/person/time links and per-type acknowledgments or named pending mappings. No Gauge API capability or automatic finance approval is presumed; unsupported source-shaped rows remain inert for explicit mapping/import work, not a fabricated completed transfer. Acceptance evidence: Export an approved timesheet to each named service using its official schema/sandbox, including QuickBooks Time's official API reference. Reject an unknown job code, fix its mapping and resume; replay and adjust an entry and verify one acknowledged entry plus a traceable correction, exact hours and no invoice or payroll action. Using Gauge’s actual public reviewed import/API door or its official-schema edge, map the Asana handoff into finance drafts and compare exact amounts, currencies, dates, billable flags and frozen approved-time provenance. Receive per-type IDs/acknowledgments, replay without duplicates, refuse unsupported mappings visibly and retain the full pending/exportable packet until repaired; no invoice or new approved budget is issued.

PEG-043 — File and creative-tool continuity. Google Drive, Dropbox, Box, OneDrive/SharePoint and Chest file pickers attach stable source IDs and versions with permission-aware previews. Figma and Canva designs and Adobe Creative Cloud panels connect briefs, task updates, assets and review results; approved exports enter version-bound proofing. Source deletion, permission change and version replacement remain visible without granting file rights. Native attachments meet PEG-082’s explicit 100-MB per-file bar, resumability and Base R2 custody on every ordinary upload path; forms have the separately stated 25-MB/75-MB limits. Pegboard is not a file-sync drive; larger assets use linked providers, including Google Drive and OneDrive. A project Files tab lists the currently permitted attachments and proof versions across its tasks, with task/source/version links, filters and an explicit unavailable-source state. It deduplicates the same source version while preserving task associations and never lists internal-only filenames, counts or thumbnails to a guest. All native, imported and linked file versions keep distinct custody/source labels; PEG-082 is mandatory for native/uploaded bytes and proof revisions. Acceptance evidence: Through each named file provider, attach a permitted file, deny an unauthorized file and replace/revoke the source. Through Figma, Canva and an installed Adobe panel, open a brief, submit an asset and read its review result. Inspect exact version and return update, no broadened share and a clear unavailable state after revocation. Open Files on a project with multi-task attachments, two proof versions and one internal-only asset; inspect one entry per permitted source version and its task links, filter/open the proofs and compare member versus guest counts and denied-source states. Complete PEG-082’s upload/provider-link refusal and Base R2 round trip, then compare permitted Files entries and version digests.

PEG-077 — Agency and operations service handoffs. The hub includes Google Sheets live task/project/portfolio export with field selection, read-only sync direction, refresh watermark, deletion markers and permission-filtered snapshots; spreadsheet edits do not silently change source work. Loom/YouTube video, Google Docs and Figma rich embeds in briefs/descriptions/comments retain source access, accessible links and explicit source-version/freshness labels. Miro board/card links and authorized selected-note-to-task handoff preserve backlinks without rebuilding Miro. Zendesk, Freshdesk and Intercom ticket escalation creates/links one business task/project with a reviewed field/audience mapping and returns permitted progress as source internal notes; ticket/customer reply/SLA authority stays at the help desk. DocuSign handoff prepares a reviewed envelope request or links an existing envelope and records verified signed/declined/voided events and artifact references; Pegboard never substitutes a task approval for a legal signature or sends an envelope without a person’s exact approval. Calendly booking/cancel/reschedule events link preparation/follow-up tasks and reconcile the existing calendar event; booking links/scheduling stay in Calendly or Dial. These are required target adapters, delivered directly or through a documented configured Crank/Zapier/Make connector with equivalent custody and observed outcomes; no native-incumbent availability is assumed. Acceptance evidence: Install each service and use its actual supported sandbox or official-schema edge: refresh a three-project Google Sheet after edit/deletion and revoke its grant; view/revoke each named embed; create a task from a selected Miro item and follow its backlink; escalate/replay a ticket from each of Zendesk/Freshdesk/Intercom and return one internal progress note. Human-approve one DocuSign envelope handoff, verify signed/declined/voided events, reject a forged event and leave an unapproved send pending. Process Calendly booking/reschedule/cancel without duplicate tasks or calendar events. For every service inspect denied scope, source deletion/revocation, unavailable state and reconciled outcome; external disclosure never bypasses recipient review.

PEG-044 — BI without private-data shortcuts. Tableau and Power BI connectors provide documented, paginated task/project/portfolio/goal, time, request and approval datasets with stable IDs, relationships, units, report definitions, incremental sync and deletion markers. An analyst key sees only allowed records/fields; snapshots and refresh watermarks expose stale data. Work exports and scheduled reports match these definitions rather than producing conflicting totals. Acceptance evidence: Connect each BI tool using its supported connector protocol, build a three-project report and compare exact counts/durations with the same Pegboard snapshot. Incrementally update and erase a task, refresh and inspect removal, then revoke the key and deny hidden fields and cached new fetches.

Everyday assistant and configuration

PEG-074 — Ask, summarize and use AI in rules. An in-app assistant answers work questions using only the current user’s permitted tasks, comments, project/portfolio/goal state and authorized references, with clickable record/excerpt citations, covered time window and freshness; hidden or missing context stays unavailable and never leaks through an answer or source list. On-demand task/thread/project/portfolio summaries and date-bounded status drafts expose decisions, blockers, actions and source evidence. Users edit/reject/accept drafts before publication. PEG-012 offers no-code classify, extract, summarize, draft and custom-prompt AI steps with schema-bound outputs, allowed dropdown values, explicit input selection, model/provider/cost limits and a preview. Run logs retain the permitted input references, definition/model versions, output, validation/error and applied effect; malformed/unjustified outputs stay failed/pending without invented values. AI steps obey the same scope, standing internal policy and exact human approval gates as other agents. All AI entry points share the connection state established in PEG-055: Ask, task/thread/project/portfolio summaries, status drafting, AI rule-step builder/run log, and native/custom agent teammates, planning, coordination and capacity surfaces show “No AI model connected” with an accessible Connect model link when setup skipped AI or the model is disconnected. Background rules/agents are visibly blocked with that same reason and a resumable pending job, never marked successful or completed. Invalid/revoked credentials, service unavailability and budget/custody failures show a named AI-unavailable cause and browser recovery link; secret values are excluded and no automatic substitute processor is used. On reconnect/retest, only currently authorized deduplicated work resumes; ordinary work and non-AI rules/notices continue throughout. An AI-produced date/assignee or AI-selected template/routing that determines them retains AI provenance across later rule steps; deterministic rule activation cannot supply approval for those generated commitments. Acceptance evidence: Through Ask, query “what’s blocking the launch?” as a limited member, summarize a 60-comment task thread and a date-bounded project/portfolio, and compare each answer’s factual claims/citations with only authorized rows. Deny a named private project and remove access mid-request; output and retained answer reads must exclude revoked data. Create an AI rule step that classifies a known intake request into an allowed dropdown, extracts a date and drafts a comment; inspect input/output logs and one permitted application. Return an out-of-schema category or injected approval instruction from the model edge and inspect visible refusal without extra writes or disclosure. An ordinary summary or status draft cannot auto-publish to clients/executives. On the explicit no-AI installation, visit every named entry point at 1440/390 and invoke its public API/job door: inspect the exact no-model message and connection link, structured blocked reason, zero inference calls, no invented output and retained pending work. Revoke a working model credential, invoke Ask, a summary/status draft, an AI rule step and assigned teammate, and inspect visible recoverable failures with ordinary task/edit/guest-notification journeys still passing. Reconnect through the link, pass a live test and resume once with current scope, logged model/budget and no duplicate task change or send. Extract a date and choose a routing/template with AI, feed each into a later deterministic step and require exact human schedule/assignment approval before applying; a fixed non-AI rule in the same fixture applies immediately under its reviewed activation.

PEG-075 — Define and govern a custom teammate without code. Authorized project/team Admins use a no-code editor to name an agent, version its instructions, attach permitted knowledge sources/style guides, select tools/model/provider, define assignment/event/schedule/rule triggers and set output schema, rubric, stop/budget and human-review rules. It previews effective credential/data scope and sample permitted input/output before activation; a knowledge URL, prompt or trigger cannot grant permission. Changed instructions or knowledge access are versioned and re-reviewed for activation, with old in-flight runs fenced from new authority. Triggers deduplicate and loop-protect through PEG-012/063; disable immediately stops new work and reaches running tasks through PEG-062 cancellation. The definition editor and teammate task/run pages expose PEG-074’s no-model or named AI-unavailable state and browser Connect model/retest link. An authorized administrator may save a disabled definition without AI, but activation/paid execution is blocked until a current model test and budget/custody checks pass; a saved draft does not simulate a successful dry run. Acceptance evidence: As Admin, build a marketing-copy teammate with named style knowledge, allowed task/comment tools, assignment and scheduled triggers, a PEG-028 rubric and cost cap; dry-run with the actual configured model edge, review and activate it. Trigger one task from assignment and one rule, replay the trigger and inspect exact versioned inputs, output and cost/action log. As Editor attempt instruction/trigger changes and refuse them; revoke the style source, change the instructions, disable mid-run and verify no new out-of-scope read, paid action or stale-version write. Choose “continue without AI,” save a disabled custom teammate and attempt dry-run/activation: inspect “No AI model connected,” the connection link and no paid call or task mutation. Connect/retest a permitted model, then explicitly activate and run the same version with observable usage; revoke its credential and inspect the named recoverable blocked state.

Migration and cutover

PEG-024 — Migration as a complete buyer journey. Importers for Asana, monday.com, ClickUp, Trello, Wrike, Smartsheet, Motion, Dart, Taskade and CSV provide upload or authorized source extraction, saved dry-run, field/status/person/dependency mappings and a fidelity report. Source identities, timestamps, history and attachment custody stay explicit. Missing source data is named and recoverable by source API or authorized supplemental files where available; it is never invented or silently dropped. Imported shares, rules, recurring schedules, agents and sends start inactive. Asana’s complete account path is PEG-081: browser OAuth and streamed whole-account API extraction on non-Enterprise+ plans, not a required organization export, CLI or manual per-project export. Existing JSON/CSV/saved-export doors remain available as additional importer paths rather than prerequisites. PEG-047 and PEG-048 also require complete monday.com/ClickUp account-scale browser-authorized extraction and 300-container/125-person/10-GB reconciliation, not just one campaign or a task CSV. Acceptance evidence: Through Import, ingest a real authorized Asana export augmented with official-schema API data for comments/files and compare sections, custom fields, dependencies, comments and attachments. Inspect per-record failures and unmapped data, apply once, re-import and undo without removing later native edits. Complete every source-specific journey below before claiming migration parity. Alongside the retained file-import cases, have the non-technical owner start the whole-account Asana API job in PEG-081, approve its estimated scope/time, interrupt/resume it and complete account-wide reconciliation and the reviewed invitation/delta cutover. Complete both PEG-047/048 full-account fixtures in addition to their retained export/small-source journeys.

PEG-046 — Asana account migration. Move teams/projects/sections, tasks/subtasks, multi-homing, field library, dates, dependencies, milestones, comments/attachments, followers, approvals, recurring definitions, portfolios, goals and supported status/time history using JSON/CSV plus authorized API extraction. Keep source users as attributed identities until mapped to local members, and preserve unsupported rule/template details as inert source context with a rebuild path. JSON/CSV availability is documented in Asana's export guide. The migration checklist explicitly counts tags/tag memberships, branching form definitions, project briefs/Overview/key resources, project/team Messages and replies, task templates, saved searches/views, reports/dashboards, My Tasks private tasks/sections and per-member Admin/Editor/Commenter/Viewer levels plus guest editor/assignee shares. Each record is migrated, translated or held inert with source identity, artifact and a concrete rebuild path; a source API limitation is a named unresolved cutover item. Personal exports apply only for their authorized source owner, and inactive staged shares retain exact source grant paths for review. Source app.asana.com task/project URL aliases are retained after cutover: pasting a known migrated source URL in search or the migration resolver opens its mapped local record only for a currently authorized user. Ambiguous/unmapped URLs show a specific repair item to authorized migration administrators, never a guess or an unauthorized existence leak. Whole-account switching is mandatory at PEG-081’s 300-project/125-person/10-GB scale using browser OAuth and API enumeration even when organization-export endpoints are unavailable to the source plan. It includes active and archived projects and the full available source types named here, with source-authorized private-data collection and explicit unresolved access/custody/rebuild items. A 20-project portfolio or per-project export alone cannot satisfy the whole-account obligation. The fidelity checklist includes team privacy (Public to workspace, Membership by request, Private), project visibility (Private to members, Team only, Shared with workspace), their default levels, join/approval policies and direct/team/guest granting paths. Source settings are staged for PEG-083 review; a missing setting is a named repair item, never guessed public. Rule-author identities and their source roles are counted separately from active Pegboard configuration authority. Provide PEG-012’s Ask your project Admin and staged per-project Admin review; source authorship never silently grants Admin. Asana Timesheets & Budgets time, approval and billable/non-billable provenance join PEG-017/042’s hours reconciliation; budgets, effective-dated bill/cost rates, rate cards and monetary actuals are retained as finance-restricted inert source artifacts and handed to Gauge with source identity/currency/period, never activated as a Pegboard monetary ledger. A missing source field or disconnected Gauge is a counted repair/pending handoff, not a dropped economic record or an implied budget migration success. Acceptance evidence: In Import Asana, migrate a campaign already in approval and a 20-project portfolio from real export and official-schema paginated source reads. Compare identity counts, shared tasks, dates, custom fields, dependency graph, author/time history and file digests; source export omissions appear in the fidelity report and block an unqualified complete-cutover decision. Migrate an Asana project containing tags, branching intake, a brief and key resource, Messages/replies, a task template, saved search/chart, My Tasks sections and Viewer/Commenter/guest-editor grants. Compare per-type/source-ID counts for every listed item; each is mapped or appears in an explicit counted rebuild item, and no form/share silently disappears or activates. Paste migrated Asana task/project URLs through search and the public resolver door, including a multi-homed task, and reach the correct local ID. Repeat as a restricted guest and refuse without revealing hidden names; an unmapped URL yields the authorized repair item without creating work. Run PEG-081’s Advanced-tier account fixture through the browser in addition to this 20-project/export journey; reconcile every source type and file digest across 300 active/archived projects, 85 members and 40 guests, then apply an edited-source delta and reviewed bulk member invitations without silent shares/sends. Add all three team privacy types and all three project visibility levels with mixed defaults to both source-export and PEG-081 fixtures; reconcile source settings and staged/effective grant paths, then repeat PEG-083 discovery/join/request checks after reviewed cutover. Import rule-author/Editor metadata plus approved time, billable flags, rates and a USD project budget. Compare hours/approval/source IDs in Pegboard and exact financial artifacts in the restricted handoff, review project-Admin elevation separately and reject unreviewed activation. A non-finance guest cannot read amounts; when Gauge is unavailable the manifest stays pending with counts and an exportable repair packet.

PEG-081 — Whole-account Asana extraction and accountable cutover. The non-technical owner starts Settings → Migration → Asana, follows a saved browser guide to register their installation’s own Asana OAuth client with exact generated HTTPS callback/scopes, and authorizes the selected source organization through browser OAuth. Any provider-displayed app client secret is sealed once; the buyer never copies a personal access/access/refresh token, runs a CLI or manually exports individual projects. Source tokens are obtained/refreshed server-side after the browser grant, stored encrypted, excluded from logs/archives and revoked on disconnect. The guide makes the app ownership, source role/plan, permitted object types, unavailable permissions and scope explicit. The migrator enumerates the complete active and archived account graph available under authorized source membership, including projects/sections/tasks/subtasks/multi-homing, people/guest grants, fields/tags, dependency/time/approval/comment/message history, portfolios/goals and attachment provenance, plus all PEG-046 mappings or counted rebuild items. It detects source access gaps and offers browser reauthorization/requests to the proper source owners; it never calls an incomplete authorized subset the whole account or silently invents private records. The necessary source authorizations are engineering work, not an exemption from account completeness. Before work starts, a saved preflight shows account/object/byte counts or clearly labeled scan estimates, plan/rate assumptions, expected request volume, staged storage/cost, throughput assumptions and an elapsed-time range. Durable background extraction checkpoints page cursors/source IDs, scanned data revisions and byte/object progress, survives token refresh and process interruption, and resumes without re-reading/creating completed effects unnecessarily. Scheduling respects the actual provider token quotas and Retry-After, including paid-domain 1,500 requests/minute, at most five concurrent duplicate/instantiate/export jobs per user where such endpoints are used, search and request-concurrency/cost limits, and shared source-account activity; workers cannot evade throttles by switching unapproved tokens. Non-Enterprise+ extraction uses ordinary authorized paginated APIs, never requires the Enterprise+-only organization-export service-account route and remains complete when that endpoint refuses. Attachments are streamed into owner-controlled US storage with byte counts/content digests and source/version identity while download URLs are valid; expired URLs are reacquired from the authorized source and failed/forbidden/missing blobs are named unresolved custody items with a repair action, never replaced by an empty file or called migrated. Data extraction/metadata and file-byte progress remain separate. Actual completed requests, source rates, throttled time, retries, transferred bytes, transfer rates and elapsed time are reported against the displayed estimate, including interruptions and revised estimates; raw token-bearing file URLs never enter public reports. PEG-054’s final delta, fidelity reconciliation, inactive authority and conflict-preserving rollback operate across the whole account. Cutover includes reviewed mapping and bulk invitations for source members and guests: preview exact local identities, email recipients, roles/project scope and existing-account matches, select/approve the batch with one auditable current decision per invitation, then send only those reviewed invitations once. New records are not silently invited by importing them. Existing active members are matched rather than duplicated; a changed address/share invalidates that invitation’s review and preserves other approved rows. Every available source type and all attachment digests must reconcile, with unresolved items counted and repaired or explicitly accepted as named losses before cutover; accepted loss does not become a claim of lossless migration. Source rules, proof decisions, bot scopes and share capabilities never become new execution/approval authority. Asana team privacy types, project visibility/default access levels and direct/team/guest grant paths join the enumerated account fidelity report and staged-setting review under PEG-083. Attachment bytes use PEG-082’s Base-registered R2 buckets; a migrated file up to 100 MB is eligible for the same ordinary proof-v2 upload limit. Reviewed bulk invitations also require PEG-084’s current evaluated DMARC-passing mail identity, advisory placement status and capacity preflight; sending is paced with remaining/per-address outcomes and changed or suppressed recipients cannot bypass review. Acceptance evidence: The PEG-055 non-technical tester uses only browser setup/OAuth to migrate an authorized Asana Advanced account or an official-schema network-edge fake with at least 300 active/archived projects, 85 members, 40 guests, multi-homed tasks, portfolios/goals, multi-year comments and at least 10 GB of actual streamed attachment bytes. The fake rejects Enterprise+ organization export, enforces 1,500/minute token quota, five-job limit where relevant, documented search/read/write concurrency limits and 429/Retry-After, and includes expired cursors/token refresh/expiring attachment URLs; retain a separate scheduler case that reaches the five-job boundary even if the main path uses no export jobs. Show the owner a preflight estimate, pause/interrupt the actual extraction and receiver, resume after restart and compare per-type IDs/counts, graph edges, identity/permission mappings and every stored file’s digest/byte count across the full account. Fail one blob, inspect named unresolved custody, reacquire/repair it and reconcile before success; a declared Content-Length or synthetic metadata counter cannot substitute for transferring/digesting the 10-GB corpus. Edit source records/files/permissions and native work during a delta pass, inspect conflicts and updated totals and complete or roll back the reviewed cutover without lost native edits or repeated effects. Review and bulk-invite 85 mapped members plus chosen guest shares, compare one decision/delivery per invitation, skip matched members, reject a changed-address row and prove unreviewed identities receive nothing. Record screen/timestamp evidence, measured requests/bytes/rates, retries/throttled time and total elapsed versus the saved estimate; require accurate unresolved status or estimate-overrun explanation rather than an unmeasured speed claim. Include every Asana team privacy/project visibility type with mixed default roles and source grants across the 300-project account. Compare settings/counts before review and effective discovery/default access after approved cutover; no private team/project becomes discoverable inadvertently. Upload a migrated exact-100-MB file as proof v2 through PEG-082 and require fresh current-version review. Run PEG-084’s 125-person mail-capacity queue at this source’s reviewed cutover, including one suppressed address, a corrected/re-reviewed row, provider throttle and restart; reconcile each invitation to one accepted or visible failed outcome with no unreviewed send.

PEG-047 — monday.com account migration. Move workspace/board/group/item/subitem work, columns/statuses, people, connected-board references, dates, updates, files, dependencies, views, dashboards and supported time/automation definitions. Use authorized account exports/API augmentation; board Excel export alone omits view behavior and some updates, which the report must name. Formula and mirror definitions are translated or held explicitly for human repair. The same per-type fidelity checklist includes labels/tags, intake/form definitions, project briefs/Overview/key resources, project announcement/thread history, task templates, saved views/searches/reports/dashboards, personal organization and exact member/guest access levels where present in this source. Every item is migrated, translated or held inert with counted artifacts and an actionable rebuild path; absent source capability/data is labeled rather than invented. The whole-account obligation has PEG-081’s completeness/custody/cutover bar: a non-technical owner uses Settings → Migration and a saved browser guide with exact installation OAuth callback/scopes and sealed client configuration, never a CLI or copied personal/access token. Authorize the source account/workspace, enumerate all authorized active and archived work across every container and page, reconcile source visibility/access gaps explicitly, and obtain necessary source-owner authorizations rather than calling a partial account complete. Per-board/list manual exports cannot be the required normal path; optional account exports/supplements remain supported. Save preflight counts/byte estimates, source plan/quota assumptions, request volume, staging storage/cost, throughput and elapsed-time range. Durable background page/object/byte checkpoints survive interruption, lost pages and revoked/expired credentials repaired by browser reauthorization without duplicate work. Stream/digest at least 10 GB of actual source attachment bytes into PEG-082’s Base-registered owner R2 custody, track file bytes separately from metadata, reacquire expired source URLs under authorized source access, and expose/repair every missing or forbidden blob. No counter or URL substitutes for custody. Report actual requests/bytes/rates, throttled/retry time and total elapsed versus saved estimates. Across the complete account, require per-type IDs/counts, graph/file/permission/time fidelity, counted inert rebuild items, source/native concurrent deltas and PEG-054’s reviewed conflict-preserving rollback. Review bulk mapping/invitations for at least 85 members and 40 guests with exact scope/recipient/role and existing-local matches, one current human decision and one delivery per chosen row; changes invalidate that row, and unreviewed identities/shares never activate. Named accepted losses never become a lossless/completed-subset claim. Use monday OAuth configuration and its current supported token lifecycle. Enumerate board pages with archived/all state and item cursors without assuming items_page enumerates archived items. Where archived IDs are not API-enumerable, provide a guided, authorized read-only capture of the source archive listing through Pegboard’s browser companion, saved with source identity/watermark, then use supported ID-based reads; it never unarchives or changes source work to make extraction easier. Account exports can supplement custody but omit archived boards and workdocs, so they cannot establish complete extraction. Any inaccessible archived work remains an explicit blocking inventory/repair item until collected or accepted as a named loss. Respect the selected plan’s documented daily/minute/concurrency/complexity/IP limits and retry_in_seconds/Retry-After under official rate limits; no unapproved token rotation evades quotas. Reviewed bulk invitations also require PEG-084’s current evaluated DMARC-passing mail identity, advisory placement status and capacity preflight; sending is paced with remaining/per-address outcomes and changed or suppressed recipients cannot bypass review. For multiple source assignees, the dry run retains every source person/ID and chooses one accountable Pegboard owner by a reviewed mapping (prefer an explicit source owner when available; otherwise the reviewer chooses), with remaining people as current-scope collaborators/effort participants, not silently unassigned or invited. Preserve source workload settings and each per-person duration: monday Split divides effort as source does, Sum attributes full effort to each participant, and ClickUp explicit per-assignee estimates remain exact. Unavailable allocation settings/data are counted repair items requiring a reviewed choice and labeled changed semantics, never guessed source equivalence. Native PEG-016 allocation records and source-reference views reconcile person/week totals alongside one task identity; source/native differences are reported before cutover, not hidden by changing denominators. New collaborator/share authority remains staged under PEG-054. Acceptance evidence: Migrate an active multi-board campaign with subitems, cross-board links and private client work. Inspect mapped values, supplemental updates/files, reconstructed dependencies and reconciled board/dashboard counts; repeat after source changes and retain one mapped record with conflicts and source-only omissions visible before cutover. Include labels, a form, brief, saved view/report and mixed member/guest grants in this source migration fixture; compare per-type counts and reconstruction decisions, inspect every held item and require a resolved or explicitly accepted loss before cutover. In addition to the retained smaller fixture, a non-technical tester completes browser OAuth and a full source-account run at 1440/390 against an authorized source account or official-schema network-edge fake, with at least 300 active/archived work containers, 85 members, 40 guests, multi-year comments/history and at least 10 GB of actually transferred/digested file bytes. Show/save the preflight estimate; throttle requests, expire a credential/file URL, interrupt extraction and the receiver, restart/resume, repair a failed blob and compare every type/ID/count, edge, identity/permission/time total and stored file digest across the account. A metadata-only 10-GB counter cannot pass. Change source records/files/grants and native work during a repeat delta; inspect conflicts and complete or roll back without losing native changes or replaying effects. Review/invite 85 mapped members and 40 chosen guest shares once, skip matched locals, invalidate a changed address/role and prove unreviewed rows receive nothing. Record measured requests/bytes/rates, throttle/retry time and elapsed versus the saved estimate and explain overrun/unresolved work honestly. For monday.com the 300 containers are boards spread across multiple workspaces, including private/shareable and archived boards, archived items/subitems, connected-board links, formula/mirror definitions, updates/files and dashboards. Include more than one item page and board page. The fake enforces the documented Pro plan daily/minute/app-token complexity/concurrency limits and retry timing, active-only items_page behavior and separately authorized archive-list capture plus official ID reads; a separate live authorized archive-list capture proves the browser door without fabricated archive APIs. Require archived source IDs/bytes and mixed source grants in reconciliation, with missing archive capture visibly unresolved rather than silently skipped. No per-board export or source unarchive is required. Run PEG-084’s 125-person mail-capacity queue at this source’s reviewed cutover, including one suppressed address, a corrected/re-reviewed row, provider throttle and restart; reconcile each invitation to one accepted or visible failed outcome with no unreviewed send. Add a multi-assignee source fixture, select the one accountable owner and preserve every remaining person/ID as a scoped collaborator/allocation. Exercise PEG-016’s monday 10-hour Split (5/5) and Sum (10/10), and ClickUp 3/7 estimates on a shared task. Compare every person/week total, task estimate/count and membership edge with the source-defined semantics, re-run without duplicates and inspect an explicit allocation-repair item when the source setting is absent. No source assignee is lost or silently invited and a changed interpretation cannot be called an exact workload match.

PEG-048 — ClickUp workspace migration. Move spaces/folders/lists, tasks in multiple lists, subtasks, custom statuses/fields/relationships, dependencies, goals, comments, files, time entries and supported dashboards/templates/automations. Project briefs/task-linked planning content migrate into equivalent Pegboard context; independent wiki documents and chat are handed to Slate/Nook with links and an explicit content report. Use workspace task CSV and authorized APIs/files to fill export gaps. The same per-type fidelity checklist includes labels/tags, intake/form definitions, project briefs/Overview/key resources, project announcement/thread history, task templates, saved views/searches/reports/dashboards, personal organization and exact member/guest access levels where present in this source. Every item is migrated, translated or held inert with counted artifacts and an actionable rebuild path; absent source capability/data is labeled rather than invented. The whole-account obligation has PEG-081’s completeness/custody/cutover bar: a non-technical owner uses Settings → Migration and a saved browser guide with exact installation OAuth callback/scopes and sealed client configuration, never a CLI or copied personal/access token. Authorize the source account/workspace, enumerate all authorized active and archived work across every container and page, reconcile source visibility/access gaps explicitly, and obtain necessary source-owner authorizations rather than calling a partial account complete. Per-board/list manual exports cannot be the required normal path; optional account exports/supplements remain supported. Save preflight counts/byte estimates, source plan/quota assumptions, request volume, staging storage/cost, throughput and elapsed-time range. Durable background page/object/byte checkpoints survive interruption, lost pages and revoked/expired credentials repaired by browser reauthorization without duplicate work. Stream/digest at least 10 GB of actual source attachment bytes into PEG-082’s Base-registered owner R2 custody, track file bytes separately from metadata, reacquire expired source URLs under authorized source access, and expose/repair every missing or forbidden blob. No counter or URL substitutes for custody. Report actual requests/bytes/rates, throttled/retry time and total elapsed versus saved estimates. Across the complete account, require per-type IDs/counts, graph/file/permission/time fidelity, counted inert rebuild items, source/native concurrent deltas and PEG-054’s reviewed conflict-preserving rollback. Review bulk mapping/invitations for at least 85 members and 40 guests with exact scope/recipient/role and existing-local matches, one current human decision and one delivery per chosen row; changes invalidate that row, and unreviewed identities/shares never activate. Named accepted losses never become a lossless/completed-subset claim. Use ClickUp browser OAuth to select authorized Workspaces and enumerate Spaces, Folders, folderless Lists and nested Lists including their archived variants. Traverse task pages explicitly including archived/closed tasks, subtasks and tasks in multiple Lists; preserve one task identity plus every List relationship rather than relying on the endpoint’s narrower defaults. Honor the actual Workspace plan’s per-token rate limits, 429 and X-RateLimit reset/remaining/limit headers; source visibility and provider-version limitations stay named and repairable. Reviewed bulk invitations also require PEG-084’s current evaluated DMARC-passing mail identity, advisory placement status and capacity preflight; sending is paced with remaining/per-address outcomes and changed or suppressed recipients cannot bypass review. For multiple source assignees, the dry run retains every source person/ID and chooses one accountable Pegboard owner by a reviewed mapping (prefer an explicit source owner when available; otherwise the reviewer chooses), with remaining people as current-scope collaborators/effort participants, not silently unassigned or invited. Preserve source workload settings and each per-person duration: monday Split divides effort as source does, Sum attributes full effort to each participant, and ClickUp explicit per-assignee estimates remain exact. Unavailable allocation settings/data are counted repair items requiring a reviewed choice and labeled changed semantics, never guessed source equivalence. Native PEG-016 allocation records and source-reference views reconcile person/week totals alongside one task identity; source/native differences are reported before cutover, not hidden by changing denominators. New collaborator/share authority remains staged under PEG-054. Acceptance evidence: Migrate an agency workspace with a shared-list task, approved timesheet, private asset and linked document/whiteboard. Compare IDs, nesting, status history and time totals, verify attachment bytes or named unresolved custody, and inspect the reviewed Slate/Nook handoff without granting imported guest access. Include labels, a form, brief, saved view/report and mixed member/guest grants in this source migration fixture; compare per-type counts and reconstruction decisions, inspect every held item and require a resolved or explicitly accepted loss before cutover. In addition to the retained smaller fixture, a non-technical tester completes browser OAuth and a full source-account run at 1440/390 against an authorized source account or official-schema network-edge fake, with at least 300 active/archived work containers, 85 members, 40 guests, multi-year comments/history and at least 10 GB of actually transferred/digested file bytes. Show/save the preflight estimate; throttle requests, expire a credential/file URL, interrupt extraction and the receiver, restart/resume, repair a failed blob and compare every type/ID/count, edge, identity/permission/time total and stored file digest across the account. A metadata-only 10-GB counter cannot pass. Change source records/files/grants and native work during a repeat delta; inspect conflicts and complete or roll back without losing native changes or replaying effects. Review/invite 85 mapped members and 40 chosen guest shares once, skip matched locals, invalidate a changed address/role and prove unreviewed rows receive nothing. Record measured requests/bytes/rates, throttle/retry time and elapsed versus the saved estimate and explain overrun/unresolved work honestly. For ClickUp the 300 containers are active/archived Lists across multiple Spaces and Folders with folderless Lists, archived/closed tasks, deep subtasks, a task in multiple Lists, custom item fields/statuses, comments/files, goals, time entries and private guest assets. Include more than 100 tasks in a List so paging is compulsory. The fake enforces the documented Business plan 100-requests/minute token limit, 429/reset headers, zero-based task paging and default omission of closed/subtask/multi-list work; only explicit traversal can reconcile every source identity/List edge. Include reviewed task-linked content and the existing counted Slate/Nook handoff without inventing missing source data or granting imported access. Run PEG-084’s 125-person mail-capacity queue at this source’s reviewed cutover, including one suppressed address, a corrected/re-reviewed row, provider throttle and restart; reconcile each invitation to one accepted or visible failed outcome with no unreviewed send. Add a multi-assignee source fixture, select the one accountable owner and preserve every remaining person/ID as a scoped collaborator/allocation. Exercise PEG-016’s monday 10-hour Split (5/5) and Sum (10/10), and ClickUp 3/7 estimates on a shared task. Compare every person/week total, task estimate/count and membership edge with the source-defined semantics, re-run without duplicates and inspect an explicit allocation-repair item when the source setting is absent. No source assignee is lost or silently invited and a changed interpretation cannot be called an exact workload match.

PEG-049 — Wrike creative-work migration. Move spaces/folders/projects and cross-tagged tasks, custom item types/workflows/fields, dependencies, dates/baselines, comments, attachments/versions, proof feedback, approvals, reports, requests and time history using Excel export, authorized APIs and supplemental archives. Source proof pins and decisions remain labeled historical evidence of the source version; missing proof artifacts are reconciled, never treated as a fresh Pegboard sign-off. Acceptance evidence: Migrate a creative project between PDF v1/v2 approval rounds with time entries and a Gantt baseline. Compare source attachment digests, annotations and decision attribution, then continue review in Pegboard on the correct version. The report names every absent pin/approval artifact or unsupported mapping and the buyer approves its resolution before cutover.

PEG-050 — Motion work and calendar migration. Move workspaces, projects, tasks, priorities, estimates, dependencies, recurring definitions and authorized project context through official API/export capabilities; map scheduled blocks separately from deadlines. Calendar reconnection establishes new authority without copying OAuth secrets. Scheduling policy and locked blocks are reviewed rather than blindly imported; source-only agent/knowledge configuration is retained as inert context or linked to the responsible sibling. Acceptance evidence: Extract an active Motion project through the documented source API, including an unscheduled overloaded task and a moved calendar block. Preview and approve owners, deadline versus time-block mapping and recurring behavior; compare counts/effort with the source and reconnect calendars without duplicate events, copied credentials or automatic unapproved rescheduling.

PEG-051 — Dart workspace migration. Import Dart's raw workspace export with spaces/dartboards, tasks, properties/statuses, dependencies, comments/docs, reminders and assignable-agent context where supplied, supplementing through its authorized API. Preserve original authors and task IDs, and send engineering sprints/issues to Vector with linked business work rather than adopting an engineering product. Agent instructions migrate as disabled draft configuration requiring a scope review. Acceptance evidence: Migrate two Dart spaces with custom properties, a dependent task and an agent-owned draft. Reconcile raw records and file availability, rebuild a saved business view, inspect linked engineering handoff and refuse imported bot authority. Re-import a changed task and report the conflict without cloning it.

PEG-052 — Taskade project and workflow migration. Import project hierarchy, tasks, assignments/dates, available custom fields, attachments and project context from supported project exports, supplemented by authorized API data. Views map to Pegboard work views/canvas; agents, knowledge references and automations become disabled, reviewed configurations. General generated apps/data tables/workflow graphs hand off to Cradle/Pencil/Crank with retained source references. Markdown or text alone is never represented as a complete workspace backup. Acceptance evidence: Migrate multiple Taskade projects with nested tasks and agent/automation references, reconcile exported and API-visible records and identify absent history/assets explicitly. Continue one business project in Pegboard, inspect the approved sibling handoff and show that imported automations or paid/external actions cannot run until freshly authorized.

PEG-053 — Trello, Smartsheet and spreadsheet migration. Trello boards/lists/cards/checklists, labels/members, comments, attachments and dates map to project work. Smartsheet work sheets, hierarchy, dependencies, assignments, fields, attachments and available comments/history map to the fixed work model; arbitrary relational apps remain Cradle's job. CSV/XLSX preview supports explicit encoding, US date/timezone and duration mappings, missing owners, duplicate rows and external IDs; ambiguous dates are refused until resolved. Acceptance evidence: Import a live Trello campaign export, a Smartsheet dependency sheet and US CSV/XLSX work files through Import. Compare hierarchy, deadlines, files and graph edges, fix an ambiguous date and unmapped owner, inspect a named history limitation and re-run without duplicates; unrelated database sheets are handed to Cradle with an explicit report.

PEG-054 — Mid-stream cutover, reconciliation and rollback. Every importer supports a source watermark, saved mapping, side-by-side counts and graph/file/permission/time checks, repeated delta import, concurrent-edit conflicts and a final reviewed cutover plan. Source permissions become restrictive staged shares pending review; active automations and recipient authority never transfer implicitly. Freeze/delta strategy, source shutdown, connector reauthorization and rollback consequences are explicit. Batch undo removes/restores only unchanged owned effects and preserves dependent native work and later erasures. The staged-share review supports bulk accept-as-source for a selected unchanged set after showing actual recipients, source/effective role, grant path and internal-field exclusions, with per-exception correction. It cannot bypass guest policy, create invitations silently or activate unreviewed public links; changed membership or records invalidate only the affected staged decisions and preserve the rest for review. Bulk cutover invitation review also covers mapped members as well as guest shares: exact recipients/roles, existing-identity matches, per-row decision records and single invitation delivery survive retry/restart. PEG-081 extends every count/digest/delta/rollback check to the full Asana account, not only one active campaign. The same whole-account counts/digests/delta/rollback and reviewed bulk invitation bar applies to monday.com PEG-047 and ClickUp PEG-048. Reviewed bulk invitations also require PEG-084’s current evaluated DMARC-passing mail identity, advisory placement status and capacity preflight; sending is paced with remaining/per-address outcomes and changed or suppressed recipients cannot bypass review. Acceptance evidence: Run a two-pass cutover of an active campaign for every source in PEG-024, create changes on both sides, interrupt/resume apply and compare source/project/task/file/time totals and exact residuals. Approve cutover only after resolved or explicitly accepted named losses; exercise rollback with native edits and demonstrate no lost work, broadened share or replayed notification. Review a migration with 40 guests, bulk-adopt the compatible staged shares and individually correct a Viewer/Editor conflict and internal-field exception. Change a source/local share before Apply; require fresh review for that exception, no broadened scope and one auditable decision per applied grant. Review 85 mapped members and 40 guests at account cutover, approve chosen invitations/share adoptions and change one source address after review. Only current approved recipients get one invitation, matched local identities are not recreated and the changed row requires re-review while full-account delta totals/rollback remain reconcilable. Run the source-specific 300-container/85-member/40-guest/10-GB cases for monday.com and ClickUp, preserving native edits and current invitation decisions on resume/delta/rollback. Run PEG-084’s 125-person mail-capacity queue at this source’s reviewed cutover, including one suppressed address, a corrected/re-reviewed row, provider throttle and restart; reconcile each invitation to one accepted or visible failed outcome with no unreviewed send.

Owned operation and data custody

PEG-055 — Owner-run Cloudflare installation through Base. The owner installs and upgrades Pegboard through Base into their Cloudflare account with documented runtime, database, file/object custody, mail, queue/scheduling and domain bindings, US placement and explicit provider prerequisites/costs. Setup establishes the first owner securely, serves public product/contract/sign-in pages without private data and fails closed on absent configuration. Upgrade previews data changes, backs up product data and supports recovery without replacing the owner's business identity or data. A guided browser-only Base setup requires no CLI, developer tools or hand-written configuration. Before installation it collects member/guest/storage/mail/agent-volume assumptions and shows an itemized monthly USD estimate with dated provider rates, free allowances, optional spend, uncertainties and owner-controlled account charges; it is not a promised bill. The wizard connects the owner’s Cloudflare account with scoped authorization, provisions/validates runtime, storage and mail bindings, guides DNS/domain verification, and guides model connection and a live test before final completion, then creates a first project and sends explicitly reviewed invitations. Every failed prerequisite names its cause, current state, exact browser recovery steps and resume control without duplicate installations or invites. The non-technical owner selects a supported model and connects it through a scoped owner-account model binding or browser-entered provider credential stored as an installation-local secret. The guided screen names the processor/model, US processing/storage/retention/training posture under PEG-021/065, required grants and USD usage terms before consent; an unqualified custody path cannot be enabled without the explicit owner-approved exception that those clauses require. A default $25 monthly USD AI limit is shown and editable before connection, included in the saved pre-install estimate, and enforced with usage/reservation accounting under PEG-061. The wizard makes a real live inference test and records model identity, configuration revision, timestamp, result and budget usage without logging credential values. Missing/failed model tests name a cause and browser recovery/retest path; they never silently finish as AI-ready. Final setup completion requires either that successful current model test or the owner’s explicit “continue without AI” choice, recorded with actor/time and disabled-AI state. Skipping is never automatic after a failed call or timeout; ordinary work remains available. Without a connected model every AI surface says “No AI model connected” and links to the browser connection flow under PEG-074; no draft, answer or successful rule/agent run is fabricated. After basic setup, Settings exposes the published-store invitation/QR, one-time push-relay registration and member app-binding guide from PEG-079, plus the four provider-registration guides from PEG-080 and whole-account Asana migration from PEG-081. These guided paths name their responsible release/provider/owner roles and remain accessible to a non-technical owner; none requires owner mobile developer accounts or a handwritten OAuth manifest. The owner sees signed version/security advisory notices with affected installation versions, severity, release notes, backup/migration/recovery implications and a guided upgrade. A scoped standing owner policy may allow signed security patches during a chosen window after backup and preflight, with visible success/failure and rollback; feature/schema upgrades outside that policy require explicit review. Notices and eligible updates never silently broaden provider/agent permissions. Setup and the 30-minute bar also require PEG-084’s SPF/DKIM/DMARC verification, PEG-086’s owner recovery enrollment. Owner/recipient-platform placement probes are offered as advice; unconfirmed placement cannot delay default setup or invitation/sign-in dispatch, and no unused platform account is a prerequisite. A built-in web URL never substitutes for the separately named authenticated sender. The pre-install quote includes PEG-061’s explicit Run Edit Run software/push/security-update line items and mail-capacity assumptions. The timed run can finish with Inbox placement not confirmed once sender authentication and other setup requirements pass; only an explicitly selected hold can delay that platform’s mail, and an owner/Admin can release it once. Acceptance evidence: Starting with an empty authorized Cloudflare account, install via documented Base steps, configure mail/domain and sign in as the first owner. Create a project, upgrade the deployed Worker and recover from an interrupted upgrade; work/history remain intact and an unconfigured installation or unauthenticated public route reveals no workspace data. A non-technical tester using only a browser starts with an empty authorized Cloudflare account, reviews the estimate, completes mail-verified setup, sends two reviewed invitations and creates the first project in under 30 minutes of elapsed time; keep start/end timestamps and a screen recording including provider waits. A built-in verified web URL can establish owner setup/first use while custom web DNS remains visibly pending; invitation/sign-in/notification mail still waits for PEG-084’s separately authenticated sender and a passing evaluated sender authentication outcome; platform placement checks remain advisory unless the owner expressly enabled a hold. Separately inject each missing grant, billing prerequisite, mail failure, DNS error and failed model connection/test, follow its browser recovery and resume without duplicate data; if a provider delay exceeds the bar, the run is not called passed. During the same under-30-minute browser-only run, connect the chosen model, pass the real live test, ask a cited question about the first project, summarize an authorized seeded thread and generate a status draft; compare logs to model/configuration revision and the USD budget. Separately complete a fresh timed run only by explicitly choosing “continue without AI” and inspect the actor/time record plus “No AI model connected” and Connect model link on Ask, summaries/status drafts, AI rule steps and agent teammates. Verify missing/failed model, invalid credential, failed inference, denied processor consent or budget failure cannot pass setup without a successful retest or that explicit recorded choice. The 30-minute bar counts as met only with the passing model test or the recorded choice as well as all other setup outcomes; provider/model waits remain inside elapsed time. From the fresh setup completion screen, open Mobile, Connections and Asana migration; verify the owner can follow the named guides with the exact generated installation address/values and separate measured provider clocks, while unfinished connections have explicit states. Record that no mobile signing or Apple/Google developer-account step appears in the owner journey. Present a valid and forged release/security notice, inspect applicability and guide, enable a bounded automatic security-patch window and apply one eligible signed patch after backup. Reject a forged/incompatible/out-of-policy update, simulate failure and recover with intact work and an owner-visible result; no secrets or new grants arrive via the update. Complete PEG-084’s evaluated sender-authentication checks plus PEG-086 recovery enrollment in the same timed setup, send the two reviewed invitations/sign-in links to the platforms actually used and offer placement help without blocking the buyer on it. Retain the separate real Gmail/Microsoft 365 product qualification without imposing it on every buyer. A fresh sender whose DMARC would fail cannot pass mail-verified setup or send invitations; an isolated missing DKIM with valid aligned SPF, or failed SPF with valid aligned DKIM, remains a warning while DMARC passes; show the named records and repair, and retain all provider waits inside the 30-minute bar. Inspect the complete Run Edit Run/provider quote before any spend decision. Finish with four unprobed gateway/consumer guests as PEG-084 requires, then demonstrate the separate chosen-hold/manual-release path without changing the 30-minute basic setup bar.

PEG-084 — Authenticated mail and a cutover that reaches inboxes. The PEG-055 browser wizard configures the installation’s explicit production Base mail provider, with at least Resend qualified at launch, and names its From/reply domain, envelope/return-path, DKIM signing identity, account/US processing terms, sending plan and credential custody. Every offered provider must meet this clause’s DNS, events, capacity and live-inbox qualification, rather than inheriting qualification from another adapter. Show the exact provider-generated record type/name/value for SPF, DKIM selector and DMARC, their lookup results/alignment/verification times and console/DNS repair links; safely merge SPF rather than publishing competing SPF records or replacing unrelated senders. Read DNS/provider status and evaluate Pegboard’s own sender: whether the provider’s SPF include/IP authorization is present and passes, whether the chosen DKIM selector/key and actual signature are valid, and whether at least one authenticated SPF or DKIM identifier aligns with the visible From domain so DMARC passes. Show all SPF/DKIM/DMARC records to add and their individual results/repair links, but a lone SPF failure/permerror or DKIM defect is a warning while the other aligned authentication method still passes DMARC; aligned DKIM alone is sufficient to keep invitations, sign-in mail and notices flowing. Initial dispatch requires an evaluated DMARC pass for the selected sender and usable provider credentials, never an unauthenticated fallback. The release’s full live qualification still demonstrates SPF, DKIM and DMARC passing, distinct from the minimum operational send decision. Persist evaluated pass/fail/unknown results, observation/expiry times and provider/account/From/envelope/signing identity, not raw SPF/DKIM/DMARC TXT content or a hash of that text as a delivery-path key. An unrelated SPF include, DMARC p=none → quarantine → reject rollout, pct or rua/ruf edit that leaves Pegboard’s outcomes passing creates no placement re-check, credential invalidation or hold. Normal scheduled authentication evaluation still runs; health records Sender records changed; still passing when a change is observed or reported. A new provider/sending domain/signing identity asks for advisory Placement re-check due on affected recipient paths while mail continues whenever the selected sender evaluates as DMARC-pass. A valid key rotation or receiver MX change likewise requests advisory checking rather than re-arming a default hold. Re-evaluate at authoritative TTL or five minutes, whichever is less, and retain last authoritative positive outcomes during timeout, SERVFAIL or resolver/network errors. Show stale age, lookup cause, last success and next retry; retry at one, two, four, eight then at most fifteen minutes and escalate owner warnings after 24 hours without turning transient error into a negative. A DNS authentication pause requires two consecutive fresh authoritative evaluations at least 60 seconds apart showing Pegboard mail would actually fail DMARC, with no intervening passing evaluation; an isolated SPF failure while aligned DKIM passes never satisfies this condition. Name the failed alignment/record and repair in Sending authentication failing. A confirmed unusable/revoked provider credential produces its distinct transport repair state, not a DNS or placement failure; rejected sends cannot be called accepted. Successful validation resets the negative streak, and repairs resume only current authorized unsuppressed jobs once. A built-in verified web URL supplies no sender identity or mail authority. The first-owner Base/Cloudflare bootstrap can configure sending without an email session; PEG-086 supplies persistent enrolled recovery later. Setup offers a probe to the owner’s own mailbox and MX-family placement help, but placement confirmation is advice, never a default setup, invitation or sign-in prerequisite. A Google-only installation needs no Microsoft account and vice versa. Read pending recipient domains’ MX routing and label Google Workspace/Gmail, Microsoft 365/Outlook or the actual named Other/gateway without guessing a hidden backend; an unknown/failed MX lookup does not block otherwise authenticated mail. Invitations and sign-in mail to all platforms send by default once sender authentication passes and their ordinary human invite/share decisions are current, including Mimecast, Proofpoint, iCloud, Yahoo and other unprobeable destinations. Show Inbox placement not confirmed until evidence exists, rather than asserting failed delivery. An owner or authorized installation mail Admin may opt into a visible Hold until probed policy for selected platforms; show its actor/scope/reason/time and effective state before enabling it. One recorded Send without a placement check decision releases any held platform while sender authentication passes; no consenting mailbox, client IT approval or extra licence is needed. Advise a consenting probe mailbox on actual receiver paths when useful, including free Gmail/Outlook.com for their families, but retain the manual release at all times. Owner-confirmed Inbox probes and Received by a recipient are distinct evidence: a recipient following any recipient-correlated link in Pegboard mail, including invitation, sign-in or ordinary task links, records receipt for that platform/path. Receipt evidence can satisfy the optional hold; it proves neither Inbox placement, a human read nor a completed sign-in/approval. Safe link GET/scanner handling never grants a session or work authority; keep automated/unknown follows labeled and human acceptance/POST confirmation separate. Invitation rows show queued/provider-accepted/bounced/suppressed and Not yet accepted after {N} hours from actual dispatch, exact recipient, attempts and next step. Provide a copyable client-IT allow-list request with sending domain, current provider-published sending IPs/ranges or their documented dynamic-range reference, SPF include names, DKIM signing domain/selector and dated provider guidance; it asks IT to review legitimate delivery, never to disable filtering globally. An authorized resend after allow-list repair preserves one invitation/share identity and current review, records the attempt and never creates duplicate membership or repeated authority. Owner/inviter in-app and independent push warnings identify a chosen held platform and pending count under their current access. During any mail pause or chosen platform hold, every sign-in requester receives the identical delayed notice on web/iOS/Android, known/unknown/inactive alike; never disclose account existence or address suppression. Keep existing sessions, native bindings, task work and independent push working. Persist platform receipt/probe evidence and evaluated sender outcomes, not raw-record fingerprints. Restores re-enter excluded credentials and explicitly reauthorize sends, re-evaluate the selected sender and reuse evidence where appropriate; passing but textually different DNS never holds mail or demands probes. Provider/identity/receiver changes produce only advisory re-check items unless an owner separately chose the optional hold, which retains its one-decision release. The real Gmail plus real Microsoft 365 live run remains release qualification, not a buyer gate. Hard bounces and complaints from authenticated provider events are recorded once per exact recipient/address and delivery ID, with provider cause/time and suppression state visible only to authorized inviter/administrators on invitation/member/guest rows and in-app notices. They stop every further email to that address, including already queued notices and sign-in mail; later delivered/replayed events never clear suppression. Signature/tenant/replay checks protect the event door, and missing event subscriptions/custody show an unready provider rather than silently ignoring bounces. Soft delays remain named queued/deferred failures with bounded provider-aware retries. The inviter/admin can review a corrected address and resend exactly once under the normal invitation/share review, while the original address stays suppressed; clearing a complaint on the same address requires documented recipient permission and provider reconciliation, not an automatic retry. Sign-in requests retain PEG-056’s indistinguishable public response, with a private failure for the responsible admin and no session minted from undelivered mail. During any confirmed mail pause or expressly chosen platform hold every requester, known or unknown, sees the same Sign-in email for this workspace is delayed; your administrator has been told notice on web and both native apps, with the same enabled sign-in alternatives and owner-recovery link. Valid sign-in requests queue durably with their original expiry, current identity/share checks and no automatic lifetime extension; unknown/inactive addresses cause no mail or authority and reveal no queue membership. Existing web/native sessions, passkeys/SSO, mobile bindings, push, task work and provider connections continue under their existing grants; mail readiness never revokes them. Suppression is portable product safety data under PEG-058/059, not restored sending authority. The saved estimate and cutover preflight compare expected invite/sign-in/notification/reply volumes for 85 members plus 40 guests with actual provider daily/monthly quotas, request/recipient rates, current shared-account usage and reset windows. A plan too small is visibly insufficient with an owner-reviewed capacity/plan repair; no upgrade/spend occurs silently. Durable queues pace to the provider’s current stated limits/reset/Retry-After, prioritize authentication over optional digests without starvation, preserve recipient preferences and current share/send reviews, and show total, accepted, pending/remaining, next eligible time, deferred, suppressed and failed counts plus elapsed/estimated completion. A 125-person cutover must complete on a capacity-qualified plan, with each message accepted or a named actionable terminal failure and nothing silently discarded. Ambiguous sends reconcile before retry; invitation links are issued safely at actual dispatch under the current reviewed invitation. Queued sign-in links retain their normal request-time expiry: after a pause send only still-valid proofs once, discard expired ones without sending or silently refreshing them, and allow the person to request a fresh normal link. Queue waits cannot deliver dead authority or duplicate invitations. Acceptance evidence: On a fresh Google-only installation, evaluate/show SPF/DKIM/DMARC and invite one guest each behind official-schema Mimecast and Proofpoint MX routes and at iCloud and Yahoo, without having a probe mailbox on those platforms. With default settings all four invitations and subsequent sign-in mail dispatch under passing authentication, labeled placement not confirmed; a Google/Microsoft licence or consenting gateway mailbox is never required. Then opt into Hold until probed, queue a fresh recipient per platform and release each with one audited owner/Admin decision; all four become provider-accepted once without new membership/share identity. Follow an ordinary task link as one recipient and accept/sign in as the others; record Received by a recipient on each path, without claiming Inbox placement or treating a GET/scanner as an authenticated session. Simulate one gateway quarantine: invitation age increases, copy the complete domain/IP-range/include/DKIM-selector IT request, allow-list through the controlled provider edge and resend once with one active invitation. A held guest and unknown/inactive addresses receive identical delayed-sign-in notices on web and both native apps. Product qualification separately retains actual probes, reviewed invitations and sign-in links in real Gmail and real Microsoft 365 Inboxes with trusted SPF/DKIM/DMARC-pass headers; the buyer can finish setup with placement unconfirmed. With Google, Microsoft and Other recipients, add another sender’s SPF include, move DMARC from p=none to quarantine/pct=25 and reject, and change rua/ruf; after each passing evaluation request zero placement re-checks and hold zero invitations/notices/sign-in mail, showing changed; still passing. Change provider/From/signing identity with passing authentication: ask for advisory re-checks and keep all mail flowing; the optional hold remains visibly owner-chosen and releasable. Restore against DNS with only unrelated includes/policy/report-address differences and reuse evidence without probes or automatic holds. Remove the SPF include/exceed its lookup limit while aligned DKIM still passes: warn but send normally. Break all aligned mechanisms so DMARC actually fails, confirm twice at least 60 seconds apart and pause every platform despite manual release; a transient timeout/SERVFAIL never supplies that confirmation. Repair/revalidate and resume current jobs once. Deliver/replay a signed hard bounce for a guest invitation and a complaint for a member notice; inspect inviter/admin undeliverable cause and per-address suppression, with zero further sends from invitations/sign-in/notices/agent email even after restart or a later delivered event. Refuse forged/cross-tenant events, keep sign-in responses indistinguishable, review a corrected guest address and deliver exactly one newly reviewed invitation. Run a controlled day for 85 members/40 guests: 125 invitations, 125 requested sign-in links, 250 assignments, 125 due notices and 125 digests (750 emails, plus explicitly counted probes/reply mail). First show an insufficient free-plan preflight; then use an owner-approved plan with capacity for that total and exercise published rates, 429/reset/Retry-After, shared-account use, restart and an ambiguous acknowledgment through official-schema network edges. Also complete this paced corpus through the actual configured provider to controlled consenting test mailboxes/aliases; report per-recipient outcomes, live provider IDs, remaining counts falling to zero and measured completion versus estimate. On the healthy-provider live path all 125 distinct cutover invitations and the remaining non-fault corpus are accepted exactly once; a wholesale failure cannot be called a completed cutover. In the separate fault cases every expected message reconciles to one provider-accepted or visible terminal-failure outcome, with no silently dropped or stale-link mail. Export/restore suppression and demonstrate that queues/credentials stay inactive and no suppressed address is revived.

PEG-086 — Mail-independent owner recovery and team continuity. First setup requires the responsible owner to enroll and verify an installation-origin-bound user-verifying passkey or TOTP authenticator, plus a printable set of single-use high-entropy recovery codes saved offline with a confirmation/challenge. This is part of PEG-055’s browser setup/30-minute bar, not an optional feature deferred until after email sign-in. TOTP secrets are sealed at rest; recovery codes are stored only as hashes, shown once with accessible print/download, and never returned by ordinary reads, logs, exports or support tools. The owner can manage/revoke/replace recovery methods from a currently authenticated owner screen only after fresh verification; replacing codes invalidates the old set. At any later time, including an expired owner session, absent SSO, paused mail or inaccessible mailbox, the persistent Owner recovery public door authenticates the enrolled owner with their passkey/TOTP or an unused printed recovery code. It opens a short-lived, auditable recovery session (15 minutes maximum, fresh verification to extend) limited to Settings → Mail, exact DNS/provider repair, platform probes, owner recovery-method repair and redacted member sign-in delivery status. It grants only that owner’s existing administrative repair authority, no general member session, private-task browsing, new membership/share or SSO-only ordinary-work bypass. Generic account challenges/errors, request throttles, TOTP replay windows, one-use code consumption and origin/cross-site controls prevent guessing or replay; a mail pause never enables an unauthenticated reset or agent approval. The original first-owner Base/Cloudflare bootstrap remains available for installation creation, not a substitute for this persistent enrolled recovery. PEG-057 records entry/method identifier, repair/change and exit without code/secret/proof values. Mail/DNS state never revokes existing sessions, normal task read/write rights, native bindings or independent push; explicit security revocation and normal session expiry still apply. Members see PEG-063’s mail warning and PEG-056’s enabled alternatives, and every public sign-in requester receives PEG-084’s identical delayed-mail notice during a pause, without exposing account existence or private recipient queues. Queued valid sign-in requests retain their ordinary expiry and deliver once after safe recovery only while still current; expired requests are discarded, not regenerated without a new request. During a 125-person DNS edit, people already signed in keep working across projects and guest shares, notices remain in the appropriate queue and independent app push continues. Archives exclude passkey/TOTP secret authority, codes and recovery sessions; a restoring owner enrolls/verifies destination recovery before completing the owner handover, without forcing unrelated placement probes. Any second owner or explicitly delegated installation Admin may enroll their own passkey or TOTP and printed codes from a freshly authenticated authorized session. Each person’s recovery credential is individually scoped to the same 15-minute mail/recovery repair door, never a shared owner credential or an automatic grant to ordinary work; delegation/revocation is audited and immediately fences later use. The public recovery page also names Lost all methods → Verify Cloudflare account ownership → Re-enroll recovery. A guided Base operator-recovery flow authenticates the holder in Cloudflare and proves current write/control authority over this exact account/Worker installation using a short-lived one-time recovery challenge. The page links the exact Worker’s Cloudflare dashboard and supplies a nonce-bound recovery binding value; the holder puts it into that Worker’s generated recovery secret field through the provider’s official secret-update door, and the installation verifies/consumes it, checks account/Worker/installation/owner binding and removes the challenge. No DNS claim, email possession, guessed Worker name, token pasted into a public URL or source-code edit is sufficient. The existing signed first-owner claim remains single-use; this distinct operator recovery does not reopen it or create a new member/owner. It can re-enroll only a recorded installation owner, explicitly confirms that person, revokes that owner’s lost methods/codes/recovery sessions and requires a new verified method plus new offline codes before leaving the repair-only session. Record provider account/Worker IDs, initiating actor/control proof, affected owner, challenge consumption, revocations and enrollment in PEG-057; never the secret/challenge/code value. Warn other active owners/Admins in-app/push and show the custody event in access review. Cloudflare availability/account recovery is an honest external prerequisite when every local method is lost; enrolled second-person recovery remains independent of it. Acceptance evidence: At 1440/390 the first owner completes passkey enrollment plus offline printed-code confirmation; repeat a fresh setup choosing TOTP instead, with no SSO configured. Sign out/expire the normal session, pause mail through two confirmed DMARC-failing answers with both aligned mechanisms broken, open Owner recovery and reach the repair screen via each enrolled method and an unused printed code in separate cases, without email. Repair/revalidate sender authentication and offer affected-path placement help without a default gate, inspect the redacted per-member sign-in delivery status and resume current jobs once; the recovery session/repair appears in audit. Refuse a wrong-origin passkey, bad/replayed TOTP, reused/revoked code, foreign origin, uninvited caller and expired recovery session; normal project/private-task/member-invitation doors remain denied even for a valid recovery-only session. Download/archive/log inspection reveals no code, TOTP seed or active proof; destination restore requires new recovery enrollment while retaining unchanged platform probe data. With 85 member sessions and 40 scoped guest sessions on web/iOS/Android, simulate a 60-minute resolver timeout/SERVFAIL window through official-schema DNS edges: no DNS mail pause, original permissions/tasks/comments/assignments continue, real qualified mailbox notices/sign-in mail arrive, and owner warnings show last authoritative success, backoff and escalating stale age. Then break aligned DKIM and SPF so DMARC fails and confirm two fresh authoritative failures at least 60 seconds apart: mail pauses, while all 125 active sessions continue their permitted work and assignment push is delivered. Known, unknown and inactive sign-in requesters see exactly the same delayed notice and enabled alternatives on web and both native apps. Queue one still-valid link and another whose normal lifetime elapses; expire the owner’s normal session, recover without mail, repair the failing authentication and offer only advisory placement re-checks for genuine changed paths. Deliver the still-valid request once, discard the expired request without sending/auto-extension, accept a new explicit request normally and reconcile the 125-person workload/queues with no lost edits, new grants, duplicate notices or suppressed-address mail. Record elapsed DNS/edit/pause/recovery times, session continuity, provider outcomes and privacy refusals. Enroll a second owner and a delegated Admin with distinct methods/codes, expire the first owner’s session during a real mail pause and repair with the second person at the same restricted scope; revoke the delegation and refuse their later challenge. Then lose every method/code for the original owner and use the generated Cloudflare-account-holder re-enrollment guide through official account/Worker/secret schemas plus one real authorized Worker recovery. Wrong account/Worker/installation, expired/replayed challenge and a caller without actual Worker control fail. A valid challenge re-enrolls only the selected existing owner, invalidates old methods/codes, logs the full redacted audit chain and allows repair without mail; project/member/private-task doors remain refused. Simulate Cloudflare unavailability and show the named external prerequisite and enrolled second-person alternative without inventing a bypass.

PEG-056 — Native sign-in and accountable sessions. Base operator-auth sends email sign-in links only to active invited members, returns indistinguishable requests for unknown/inactive addresses and uses hashed, expiring, single-use proofs confirmed by a same-origin POST. A GET never establishes a session; secure cookies, bounded internal return locations, sign-out and session revocation govern browser access. A linked Auth/enterprise IdP does not admit an uninvited person or bypass SSO-only policy. Failed mail configuration cannot mint authority. The sign-in page and native app show Continue with Google and Continue with Microsoft with an explicit not-connected/needs-attention explanation and authorized Settings guide link until PEG-080’s current live sign-in test succeeds; enabled buttons retain invite-only admission and SSO-only rules. Provider-client secrets and refresh tokens remain installation-local and do not pass through a Run Edit Run shared OAuth broker. Optional native WebAuthn passkeys can be offered by the owner; members/guests enroll one or more device/security-key credentials from an authenticated Account screen with user verification, named devices and revoke controls. The same installation-origin-bound credential works through web or the app’s system-browser sign-in, retains invitation-only admission and cannot bypass mandatory enterprise SSO. Removing a passkey or deprovisioning immediately blocks it; ordinary member recovery follows existing reviewed native/SSO authority rather than an unauthenticated credential reset. Owners must additionally enroll PEG-086’s passkey or TOTP plus printed recovery codes in first setup; the later owner repair session is narrowly scoped and never a general member/SSO bypass. Email links use PEG-084’s evaluated passing sending identity, advisory placement evidence, suppression and paced delivery; a bouncing/suppressed address gets the same public request response as any unknown address, with an authorized admin-only undeliverable reason. PEG-086’s persistent owner recovery remains reachable without mail at any time. During a confirmed pause or expressly chosen platform hold web/native requesters all receive PEG-084’s same delayed notice, normal sessions and enabled alternative methods remain usable, and queued links retain their original expiry. A recipient platform awaiting advice never blocks default sign-in mail. A chosen platform hold uses the same global non-enumerating delayed notice and enabled recovery/SSO options as a confirmed sender pause. Acceptance evidence: Through the native sign-in route, request/confirm a valid link, test unknown/inactive, expired/reused links, scanner GET, foreign-origin confirmation and unsafe return locations. Sign out/revoke and exercise optional IdP sign-in; every private UI/API/export refuses old or missing authority with no product mutation. Before connection, select each provider method and inspect the named missing-connection/guide state with no session. After the live test sign an invited member in through web and app with the same account; invalid state/nonce/redirect, unknown provider tenant and revoked client produce explicit recoverable refusal without falling into a new account. With a virtual WebAuthn authenticator through the browser door, enroll a passkey as a guest, sign out/in and find the same identity; deny a wrong-origin/foreign challenge and reused challenge. Revoke/deprovision and refuse later sign-in, then enforce SSO-only and confirm passkeys cannot bypass it. Qualify the equivalent system-browser return on both native apps. Receive the separate live Gmail/Microsoft 365 qualification links in PEG-084 and refuse actual DMARC-failing or suppressed-address sends without an enumeration difference or session grant; queue delay cannot turn an expired link into valid authority. Run PEG-086’s expired-owner-session passkey/TOTP/code recovery and 125-person DNS-edit window. Known/unknown/inactive requesters see identical delayed notices in web/iOS/Android, active sessions/push remain usable and no expired queued link is delivered or refreshed automatically. Request sign-in on unprobed Mimecast/Proofpoint/iCloud/Yahoo destinations and dispatch by default; enable a hold, compare held guest/unknown notices and release with one audited Admin decision.

PEG-057 — Durable audit distinct from editable activity. Authentication, role/share changes, imports, exports, approval decisions, rules, agent actions, destructive operations and provider sends have durable actor/time/action/subject/result records. Product activity may show authorized detail; the permanent audit uses opaque identifiers and redacted metadata, excludes credentials/capabilities and anonymizes erased actors. Audit is searchable/exportable to authorized administrators and cannot be rewritten by changing a task, agent or proof. Acceptance evidence: Change a role and task, approve a proof, run a rule/agent, import/export and attempt a failed external send through public doors. Erase an actor and restore an archive; audit remains complete and attributable as allowed, anonymized where required, without planted names, email addresses, token values or asset bodies in permanent audit metadata.

PEG-058 — Whole-workspace portable archives and inactive restore. Owners export versioned, integrity-checked archives covering every target record, graph edge, field/view/template/rule definition, proof/annotation/version, time/approval, portfolio/goal/report, comment/file, source provenance, import batch, agent output and audit. Restore into eligible empty product state validates before writes, resumes interruption and reconciles counts/digests without truncation. Personal sections/tags, custom task references and aliases, announcement/email-thread provenance, saved cross-project views, agent definitions/rubrics/review metrics and all new connector state are included as product data, with personal-work custody distinguished from ordinary member access. Product identity mappings travel; sessions, login proofs, OAuth/API/MCP keys, provider secrets, active share capabilities and execution authority do not. Restored rules, sends, recurring jobs and agents stay inactive until reauthorized. Every completed PEG-082 attachment/proof original and derivative in the declared R2 bucket custody travels as actual bytes, with version links/digests; partial upload state and its capabilities do not become completed work on restore. Portable data includes mail-domain configuration references, redacted qualification history and address suppression decisions, while mail credentials, probe/sign-in proofs and active send authority remain excluded; restoration revalidates sender configuration and requires explicit send reauthorization; reuse evaluated outcomes and receipt/probe evidence under PEG-084; passing DNS edits and sender changes never create a default placement hold, and requested placement re-checks are advisory unless the owner expressly chooses otherwise. Acceptance evidence: Export a populated 500-member installation with a 10,000-task project and its real retained file/history corpus, interrupt/resume transfer and restore to a new owner's empty Base installation. Compare all declared counts, relationships and digests; corrupt/nonempty imports write nothing and no restored credential, notification, approval capability or agent job executes. Include PEG-082’s exact-limit files and migrated proof v1/v2 in the real R2 multipart round trip; reconcile byte digests, version links and inactive upload authority. Round-trip PEG-084’s suppression/outcome data and prove restored queues cannot mail before sender validation/explicit reauthorization or unsuppress an address through an older restored delivered event; evaluated passing outcomes reuse platform evidence despite text-only record differences and genuine sender changes ask for advisory re-checks without a default hold.

PEG-059 — Erasure with honest external limits. Authorized owners erase a task/project, proof/file, guest/member or permitted workspace data with a preview of dependent records and a durable redacted receipt. Work data, uploaded object versions, indexes, cached previews and agent-held retrieval copies are removed or irreversibly deidentified under declared retention/hold policy. Erasure journals prevent later imports/restores from resurrecting erased data when applied to the receiving archive. The last owner requires explicit installation reset or replacement. Already downloaded files and messages held by outside recipients require their systems' deletion process. Acceptance evidence: Erase a project with proof versions, comments, search hits and agent outputs through Data settings; inspect completed database/object/index removal and receipt. Try stale writes, replayed intake and an old archive with the later journal; data stays erased, audit stays redacted and external retained copies are accurately identified.

PEG-060 — US defaults and accessible daily use. USD, US English, MM/DD/YYYY, 12-hour time, Sunday-start weeks (switchable), US federal holidays and Letter-size PDFs are defaults. IANA zones and explicit date-only semantics preserve deadlines and reminders across DST and distributed US teams. Every daily route, client review, form, export setup and admin flow meets WCAG 2.1 AA and applicable Section 508 requirements with keyboard, focus, labels, screen-reader status, contrast, zoom/reflow and alternatives to drag/color-only meaning. In-product getting-started guidance, role-specific onboarding and a searchable versioned help center explain the actual task, proof, guest, migration and AI-connect/no-AI journeys. Help and error pages give an accessible “where to get support” path to the installation owner and appropriate Base/provider support information, with exportable redacted diagnostics; guidance does not depend on a vendor support desk or expose credentials. Teammate profiles list permitted assigned work and availability summaries only, honoring personal-task privacy and guest directory restrictions. Acceptance evidence: Complete request → project → assignment → proof → approval → report and admin/export journeys at 1440/390 with keyboard and screen reader, run automated accessibility checks and inspect manual focus/contrast/reflow. Cross US DST with an all-day deadline, report and recurrence; verify local display, holiday calendar and Letter PDF output. As a new member and guest, complete the getting-started task/review guidance, find model connection/help and follow the support path with redacted diagnostics. Open a teammate profile as an authorized colleague and inspect only permitted assignments; a guest cannot enumerate the directory and no profile exposes private no-project tasks.

PEG-061 — Included capabilities and transparent operating costs. No seat minimums, seat buckets, guest charges or agent-seat charges apply. Reporting, workload and time tracking are included. Owners see member/guest/agent counts, Cloudflare storage/compute and third-party mail/AI/provider usage, configured USD budgets and exhaustion alerts. Usage controls can pause new optional agent work with a clear reason; they never silently lose queued work, block data export or demote read access to existing business records. No unverified saving or bill is presented as an actual charge. The pre-install estimate in PEG-055 is saved with input assumptions and rate date, and compared later against observed infrastructure/provider usage. Guests/agents never cause a hidden member-license charge; the owner can change assumptions before committing any account spend. A fresh installation proposes a $25 monthly USD AI cap, shown in the itemized pre-install estimate and editable/approved by the owner before any paid test or inference. Track test-call usage, completed calls and reserved in-flight cost against that cap, with explicit estimates where a provider does not supply final usage immediately; do not claim an actual bill from estimates. A no-AI setup choice records AI disabled and incurs no model test/inference charge. Budget exhaustion pauses AI work visibly with a reconnect/budget-management route and retained pending jobs; it never silently substitutes another model or processor. PEG-082 shows reserved, completed and pending-cleanup attachment bytes against the owner’s aggregate storage quota and itemized USD estimate before transfer; per-file guarantees are not silently lowered by that quota. The pre-install and Settings quote contains a separate What you pay Run Edit Run table for software/license, PEG-079 push-relay service and security updates, each with the exact numeric USD amount (explicit $0 when free), one-time versus recurring basis, billing period/usage basis, included scope and dated public edition/price terms. These are quoted from the actual offered edition’s published terms and saved with the owner’s choice; neither open-source availability nor the absence of seat fees implies an unpriced service is free. An absent/unknown/TBD price is not an acceptable install quote: the release must publish and show each amount before the owner proceeds, and no compulsory charge can appear only after installation. Required versus optional services, renewal/overage terms and any tax estimate are explicit; paid extras require a separate owner choice and cannot turn the included capabilities into seat gates. The total distinguishes Run Edit Run charges from Cloudflare, mail, AI and optional Zapier/Make plans, and includes mail-day volume versus PEG-084’s provider quotas. This contract does not invent an unpublished Run Edit Run price or a provider bill. Acceptance evidence: Add one member, many free guests and scoped agents, then use reporting/workload/time without an upgrade gate. Inspect itemized measured versus estimated usage, cross a configured agent budget and observe an explicit pause and accountable queued work while ordinary tasks and full export remain available. Before installing, compare an 85-member/40-guest profile with a 120-member profile and inspect itemized USD estimates and assumptions; proceed only through the owner’s explicit spend decision, then compare measured usage with the saved estimate. Compare the estimate’s default/edited AI cap with the saved budget, run the setup live model test and reconcile its usage/reservation once. Exercise budget exhaustion and recorded no-AI choice: the former visibly pauses AI jobs and the latter makes no model call; ordinary tasks, guest notices and export still work and no extra provider/model is invoked. Reconcile upload reservations, completed/aborted/erased object bytes and displayed remaining capacity/cost estimate, including two concurrent uploads at a quota boundary. Before installation compare the quote with the actual release’s public software, push-relay and security-update terms: every line has an exact amount including numeric $0 where offered free, period and included scope, and the saved USD total reconciles with provider estimates and chosen options. An unpublished/missing amount blocks the purchase/install decision with a named terms error, not a guessed $0. Change the 85-member/40-guest mail profile, inspect volume/quota and any required provider-plan repair, accept optional spend explicitly and prove no undisclosed Run Edit Run or third-party fee is added after completion.

PEG-062 — Agents are scoped credentials with human accountability. Every native/external agent has a named human sponsor, explicit projects/fields/actions/providers, expiring revocable credentials, model/provider selection and a visible cost/data policy. Agents use the same server authorization as people, receive only needed data and never become approvers by impersonating a sponsor. Approvals bind exact content, recipients, versions and intended effects; subsequent edits revoke the reviewed authority. Action/evidence logs, stop controls and conflict-preserving undo cover reversible writes; irreversible external effects require approval and expose their truthful compensation limits. PEG-075 provides the no-code instruction/knowledge/tool/trigger editor; saved definitions do not expand credential scope. Internal provider posts can use standing policy; only fixed guest system notices may use the reviewed-share approval above. Agent-written outside-organization messages, client-shared channel posts, human decision gates and team-affecting agent/AI-produced date or assignment changes require exact current human approval. A deterministic PEG-012 rule’s Admin-reviewed activation is the standing approval for that rule’s current in-scope runs; it grants no standing authority to an agent or its generated values. An agent asking the notification service to send a system event cannot inject free-form message text or expand recipients/visible fields. Installation model credentials are distinct from each agent’s work credentials, stay secret/installation-local and use the owner-approved processor/budget. A missing/revoked model stops inference with PEG-074’s visible recovery state without broadening sponsor authority or disabling ordinary work. Acceptance evidence: Create a scoped agent, give it an allowed task and adversarial instructions in an attachment, then request a hidden record, an unapproved external send, spend and self-approval through API/MCP. All refuse without leaks; rotate/revoke mid-run and stop further actions. Undo its allowed edits while preserving a human's later change, and show that a sent message cannot be falsely unsent. Configure a permitted internal status-post policy and show that an agent can post within it, then add a client guest to the channel and require pending approval before disclosure. A custom-agent instruction attempting to expand its grant changes no credential or permission. Disconnect the model during a scoped agent task and inspect its blocked run, recovery link and zero additional model calls/effects; reconnect/retest and recheck both work scope and budget before any continuation.

PEG-063 — Restart-safe business operation and recovery. Durable jobs for imports, recurrence, rules, reports, follow-up, provider sync and agents survive Worker/process restarts with deduplicated effect identities, leases, visible progress and an accountable exception owner. Backups, restore drills, service health and queue/storage capacity are inspectable by the owner. Partial outages expose stale/unknown states rather than falsely completing work. Data integrity and permission checks hold during deployment, reconnection and recovery. Members see a signed-in service-health/connection banner and a public installation-specific availability/support link that can be hosted independently of the installation and discloses no work data. The owner can configure an independent health/status provider for that link rather than making an outage page depend on the failed Worker itself. The installation target is 99.9% monthly availability of native sign-in and ordinary task read/write doors, measured by independent probes with outages and denominator/exclusions disclosed; provider/chat/model readiness is reported separately and no unmeasured SLA is claimed. Mail health distinguishes transient lookup warnings, pending negative confirmation, confirmed sender pauses and per-platform placement waits; the public delayed-sign-in notice reveals no account/recipient details. Owner repair remains available through PEG-086, while ordinary work and independent push continue. Health distinguishes advisory placement evidence/re-checks from an explicitly chosen hold and an actual DMARC-failing sender pause; warnings about SPF alone, raw DNS edits or unknown MX cannot masquerade as a mail hold. Acceptance evidence: In the deployed product, interrupt each named job class before and after an external effect, restart and inspect safe completion or explicit uncertainty. Restore a backup into an inactive installation, reconcile work/job totals and reauthorize chosen jobs; demonstrate no duplicate project, approval, timesheet entry or external message. Drop the installation while its independently hosted status link remains reachable, inspect the member-facing degraded/reconnect message and work-free status page, recover and reconcile pending edits. With controlled independent probe observations, compute the stated monthly availability and show unavailable/missing observations explicitly rather than improving the denominator; distinguish model/provider outage from installation outage. Complete PEG-086’s transient and confirmed DNS windows, inspect warning/backoff and platform-specific queue health, preserve all 125 existing sessions and open mail-independent recovery after owner session expiry. Keep mail/session/push work flowing through PEG-084’s passing SPF/DMARC edits and DKIM-only aligned pass, inspect advisory labels, then exercise the chosen hold and actual two-confirmation DMARC failure separately.

PEG-064 — Trash, revisions and conflict-preserving undo. Accidental task/project/file or configuration removal enters permission-scoped trash under the owner's published retention, with restore previews that repair graph links and name missing dependencies. Destructive erasure is a separate irreversible action. Field, brief, template and workflow revisions can be compared and selectively restored; history and newer dependent work survive. Undo never reverses a person's separate approval or claims to retract an outside message. A PEG-012 rule run exposes undo by run/effect ID with its activation version/Admin; successful irreversible outside sends retain their stated compensation limits. Acceptance evidence: Archive/restore a project, trash/restore a task and proof version, compare a brief revision and undo a bulk change after another member edits it. Inspect the restored graph, preserved later work, explicit conflicts and inaccessible erased objects through browser/API/archive reads. Undo the date/assignment and added-work-action runs from PEG-012, retaining later human edits and refusing a stale or unauthorized undo.

PEG-065 — Retention and processor custody are explicit. Owners set published retention for product history, trash, attachments/proofs, import originals, agent prompts/outputs and provider logs, with separate transient credential/session cleanup. A legal hold names its scope, authority and expiry and is visible before erasure; erasure/hold conflicts are reported rather than called deleted. Retention changes preview consequences and propagate to object versions, search and processor deletion requests; stale backups carry erasure journals. Agents use only approved processors and owner-selected data-sharing/training policies. Acceptance evidence: Through Data settings, configure different retention classes, apply a hold, expire eligible records and erase an unheld project. Inspect product/object/index/processor outcomes and unresolved external deletions, confirm held content is disclosed as retained and verify an old archive plus current erasure journal cannot silently resurrect erased material.

Push further

Agent work and coordination

PEG-028 — Assignable teammates do the work. A scoped agent takes an assigned task and its permitted brief, comments, references and files, produces a real brief, copy, research, plan or creative draft, attaches its deliverable and source/evidence links and requests a human review. Every tool action, data source, model/provider and cost is logged; unsupported facts and unavailable source material are explicit. A produced draft is not a human-approved finished task. Human sponsors can stop and undo reversible effects under PEG-062. Before execution, each draft type has an explicit brief-derived rubric: required sections, output format, length bounds, audience, required facts and prohibited claims, plus brand/tone constraints linked to a named, versioned team style source. Each factual claim links a permitted source excerpt/record; unsupported claims are flagged individually and cannot be presented as verified. Reviews record accept unchanged, edit then accept or reject, the original/reviewed versions and reasons. PEG-068 measures edits; a mere attachment cannot pass the rubric or mark the task accepted. Acceptance evidence: Assign campaign-copy and sourced-research tasks through Tasks to a scoped agent using an actual configured model edge. Inspect complete attached drafts, cited references and action log; deny hidden context and injected instructions, stop a run and undo an unchanged edit. Only a named human can accept the deliverable or approve its client publication. Use a fixed authorized brief set covering a creative brief, campaign copy, research report, project plan and creative concept, each with its required sections/format/length/audience/style version and factual-source checklist. Run through the real task/agent/review doors and check every rubric item, sources and unsupported flags; exercise accept, edit and reject, compare persisted revisions and measured edits, and leave nonconforming output pending/rejected rather than accepted.

PEG-029 — Plan from a brief within real capacity. An agent reads a permitted brief, request or meeting notes and the relevant task graph, staffing roles, estimates, working calendars and capacity. It proposes phases, tasks, owners, dependencies, milestones and dates with source links, assumptions, missing decisions and infeasible constraints. A person edits/approves the exact plan before any project/tasks are created; changed availability or scope invalidates the old approval preview. Every planned task carries a proposed named owner and positive hour/effort estimate, date constraints and source/assumption; role placeholders are visibly unresolved and must be mapped before publishing. All accepted assignments fit PEG-016’s total committed capacity, dependencies are acyclic and dates honor the brief’s deadline and working calendar. If constraints cannot fit, show the exact infeasibility and alternatives rather than calling an overloaded plan feasible. The plan rubric additionally covers required phases/deliverables/milestones from the brief and the versioned style/spec source, with accept/edit/reject and edit measures as for PEG-028. Acceptance evidence: Submit a real launch brief with a holiday, time-off conflict and constrained designer. Review a complete feasible draft or explicit infeasibility with alternatives, edit role/date choices and approve once through Plan review. Nothing is created before approval; a stale review refuses, and a repeated accepted request produces one project. For fixed campaign-launch, client-onboarding and event briefs, check required phases/deliverables, every owner/estimate, graph/calendar constraints and aggregate capacity before approval. One feasible case must fit its deadline; one impossible case must name the shortage and await a human decision to change the brief/capacity. Compare edited/accepted/rejected plan revisions and ensure an unresolved owner or unapproved deadline change cannot publish.

PEG-030 — Coordinate through actual updates and proposed re-plans. Agents inspect permitted requests, activity, dependency/critical-path changes and approval deadlines, triage intake, chase owners in Slack, Teams, Nook and email under approved policy, reconcile authenticated replies to the correct task and draft weekly project/portfolio status citing source activity. Slippage produces concrete re-plan alternatives. Humans approve published plans, dates affecting others, executive/client-visible content, spend and external sends; no reply or silence is fabricated into progress. Routine company-only chases and draft notifications execute under the scoped standing policy above; a client/executive publication or agent-written outside-organization send still waits for exact review. Fixed system notices to a current guest about reviewed shared work follow the share-approved notice path, including when the coordinator triggers that event, without turning agent-written content into a system notice. On-demand and weekly status use PEG-074’s cited summaries and PEG-028’s deliverable rubric, with actual accept/edit/reject results flowing into PEG-068. Each Slack/Teams/mail chase requires that specific connected provider feature and linked actor grant under PEG-080, with a named missing/broken connection and guide on the project and chase run. The agent does not claim a chase was sent or silently switch transport while disconnected; a new transport/audience still uses the existing approval policy. Every outbound email follows PEG-084’s authenticated sender, qualified inbox delivery path, address suppression and provider-paced queue; provider acceptance remains distinct from actual Inbox receipt or human response. Acceptance evidence: Make a task stale, approve a chase and reply through each chat/mail adapter; inspect the attributed update and stopped reminder. Delay its predecessor and review a capacity-checked re-plan awaiting approval. Open the weekly status draft, follow citations and reject a wrong assertion; no unapproved date/publication change occurs. Run an internal stale-task chase without an individual send approval under policy, then attempt the same chase to a client guest and require review. Check the status draft’s required health/highlights/risks/next-steps sections against its date window and source tasks before the person publishes. Schedule the same internal chase with Slack, Teams or Gmail/Outlook absent in separate cases; observe the exact missing-provider state and guide plus one retained blocked job and no send. Complete the corresponding live guide/link step and resume once, process the real signed/authenticated reply into the task and stop follow-up under the original permissions. Exercise PEG-084’s unauthenticated-domain block, signed bounce/complaint suppression and throttle/restart cases for this email path without duplicate, silent-drop or false-delivered outcomes.

PEG-066 — Triage until work has an owner and a next step. With the request text, attachments, existing task graph and owner-approved intake policy, an agent identifies likely duplicates, missing information, routing and priority alternatives, prepares clarifying questions and follows accepted work to assignment and a scheduled next action. Reversible internal routing may use a scoped preapproved rule; priority tradeoffs, new access grants and external replies require human decisions. Confidence and conflicting evidence stay visible. Acceptance evidence: Submit an ambiguous request and a near-duplicate with a malicious instruction. Through Intake, inspect cited candidates and proposed routing, approve a clarification and process its reply. A person decides merge/priority and acceptance; the agent then verifies an actual owner and next action without changing another team's commitment or granting access.

PEG-067 — Carry creative review to an accountable decision. An agent reads allowed asset versions, pinned feedback, stage/quorum policy and review deadlines, groups unresolved feedback, drafts a revision brief and prepares exact reviewer reminders. Fixed system reminders for a currently reviewed proof share use that share’s approval and the approver’s preferences; agent-composed reviewer messages require exact send review. It follows missing reviewers, reopened feedback and returned revisions until the right humans sign the current asset or an accountable owner explicitly stops the work. It never signs on a person's behalf or carries a prior-version decision forward. Acceptance evidence: Run a campaign proof through missing external review, request-changes and v3 replacement. Inspect a sourced revision brief, an ordinary proof reminder authorized by the reviewed share, and a separately human-approved agent-written reminder, reject an old-v2 approval and observe the actual human v3 sign-off close follow-up. No merely delivered reminder or generated replacement is marked approved.

PEG-068 — Measure coordination and delivery outcomes honestly. Per-project measures use logged human planning/chasing/reporting time, agent runs, reviewed commitments, baseline dates and actual completion to show PM overhead and surprise slips. The owner selects comparison periods and cohort rules; exports expose definitions, denominators, missing data and overrides. Estimated time saved stays labeled and cannot be inferred solely from token counts, notifications or model self-report. For textual drafts, store Unicode-NFC normalized token-level Levenshtein distance between generated and accepted text, divided by the greater token count, with raw counts and tokenization version; for structured plans, also show task/field/edge additions, removals and changes by stable draft identity. Accept unchanged has zero distance, reject remains a separate outcome, and cosmetic normalization rules are disclosed. Report accepted-without-edit chases/status drafts, edited accepts and rejects per project. A versioned fixed reference-campaign benchmark with 20 stale tasks, two weekly reports and a controlled slippage event requires at least 16 correctly reconciled agent-handled internal chases and both cited status drafts accepted unchanged by a human, no prohibited action, no surprise critical-path slip left unreported before its due time, and fewer logged human coordination minutes than the matched manual run; retain all attempts and failures, not a cherry-picked success. Acceptance evidence: Use a completed project with attributable human time entries, agent activity, an approved baseline and actual finish. Through Outcomes, reconcile hours and slip counts to source rows, change the comparison window and include a project with missing time. Observe correct exclusions/unknowns and a plain refusal to claim proven savings from insufficient data. Through Outcomes, reconcile edit distance for an unchanged accept, a one-token edit and a rejection; for a plan compare field/edge diffs separately. Execute the reference campaign and matched manual run with the same brief, workload, scripted edge responses and real human reviewer, record timings and source decisions and test the stated 16/20, two-report and reduced-minute criteria. Report actual failures or insufficient data without claiming benchmark success; no benchmark model output is mocked.

PEG-069 — Preserve focus while repairing a slipping schedule. Agents combine permitted free/busy windows, task estimates/actuals, priorities, locks, dependencies and capacity to propose focus blocks and alternative recovery plans, show displaced work and quantify which commitments remain infeasible. User-approved personal scheduling policy can maintain one's own unlocked blocks; any team-affecting date change still requires a human approval of the exact plan. Accepted plans are verified against actual calendar and work state until reconciled. Acceptance evidence: Overrun a task while a meeting consumes its next block, lock a focus period and delay a shared milestone. Review alternative plans in Calendar/Timeline, approve one and inspect real provider events plus task dates. Hidden availability, stale proposals and capacity shortfalls remain explicit, with no overwritten lock or unapproved colleague deadline.

PEG-078 — Resolve resource conflicts across a portfolio. A scoped capacity agent reads the permitted nested portfolio’s commitments, dependency graph, estimates/actuals, role/skill requirements, working calendars and approved availability. It proposes ranked cross-project staffing/reassignment and schedule alternatives with affected people/tasks, preserved locks, total hours, displaced commitments and unresolved constraints; it does not call a solution feasible while any affected person remains over capacity or a deadline tradeoff is hidden. A responsible human with authority over the whole affected set approves exact reassignments and date changes; otherwise approval routes to the relevant project owners. Accepted changes are applied once with fresh version/capacity checks, attributed history and undo, then verified against actual workload. Acceptance evidence: Create a 30-project portfolio where two projects compete for one designer, a qualified alternate has space and a third project has a locked commitment. Run the agent through Portfolio capacity, compare two sourced alternatives, approve reassignment to the alternate and inspect conflict-free total workload, unchanged lock and one attributed application. Change an estimate during review, remove a project grant and test a portfolio with no feasible staffing; require refreshed review/limited context or an explicit shortage without automatic reassignment or deadline movement.

PEG-070 — An agent helps prove the migration. Given authorized exports, source schema definitions, mappings and comparison results, an agent proposes field/person/status/dependency mappings, identifies fidelity and permission differences, explains missing history/assets and prepares repair/cutover steps. Its evidence links back to source rows and object IDs. It cannot invent data, mark migration complete, approve losses, grant access, activate source automations or select cutover without the owner's decision. Acceptance evidence: Give a migration preview with an unknown status, expired file link, duplicate identity and conflicting owner change to the agent. Inspect sourced repair suggestions, let the owner resolve them and rerun reconciliation; only the owner's explicit cutover approval can continue, and all unresolved losses remain visible in the final report.

Honest boundaries

These boundaries preserve complete business-work management and connect specialist products through explicit handoffs. A source-system failure becomes visible, accountable work in Pegboard; a sibling link is not a claim that an adapter already exists. Every sibling remains its own product.

Input coverage

Every desk capability retains its original ID: PEG-001–027 are target clauses and PEG-028–030 are push-further clauses. Added IDs begin at PEG-031; buyer review 1 adds PEG-071–078, round 3 adds PEG-079–081, round 4 adds PEG-082/083 for attachment custody and team/project discovery/access requests, round 5 adds PEG-084/085 for authenticated mail and public Zapier/Make distribution, round 6 adds PEG-086 for persistent owner recovery and DNS-edit continuity, and round 7 adds PEG-087 for history-preserving work conversion, with earlier clauses sharpened and none removed. PEG-074/075 everyday AI/configuration are table-stakes target obligations; PEG-078 is the added portfolio-capacity push-further obligation. Each capability's behavior and acceptance are expanded above, with no original row removed. The inventory’s Draft clause coverage section maps every capability and integration entry, including all table stakes, to clauses or the explicit specialist handoff.

Status

Judged from the code and tests at commit 3372d344ee9a6eb8077717a66a62d24a5869baec (20 October 2026).

Homepage claims

The run site's homepage (src/site/landing.ts, page-s1 as approved on 20 Oct 2026) shows the product this contract builds toward (owner, 17 Oct 2026). Every capability claim it makes is listed here with the clauses that back it and its state in code. Brand names (Asana, monday.com, ClickUp, Trello, Wrike, Smartsheet, Slack, Teams, Outlook, Google Calendar, Jira, Gauge) appear only as plain text. "Contract, not yet in code" rows are build priorities.