RAPP Work organization seed · public synthetic data

The Product Launch Company

Coordinate product strategy, design, engineering, creative, distribution, and customer success around Agenda Pocket, an original usable local demo with explicit acceptance and approval-gated launch work.

6 teams · 7 scoped workspaces · 12 tasks · 34 package files

This package is not an activated organization, a membership grant, or a running service. Native SDK plans and starter-file effects require owner approval. Joining never executes downloaded code.

Chant: fathom-verge-hazel-furrow-nook-quarry-drift

Locator-only join QR for The Product Launch Company
Give this QR to your AI to inspect the exact seed and its declared protocol.

Your first engagement

Agenda Pocket: make a 60-minute meeting fit without hiding required topics

Agenda Pocket is an original offline agenda-budget planner. A SYNTHETIC library-kit meeting has 68 topic-minutes, a 60-minute session, and a five-minute wrap. The working demo reserves all required topics, includes optional topics in input order when they fit, and explains what remains unscheduled. It runs by opening a local HTML file. This case prepares a launch candidate and honest support; no users, conversions, videos, or public launch are claimed.

An actual work scope for every team.

The Organization routes through native workspace pointers. Team ownership stays in team workspaces; shared case data stays in the separate casework workspace.

Starter work and acceptance.

Approve a proposed product boundary for review · product-strategy · Ready to claim

Refine the supplied problem hypothesis into a decision brief covering who might benefit, what the local demo actually does, what it excludes, and what would disconfirm usefulness. Do not claim user validation.

Inputs: starter/docs/product-brief.md, starter/data/sample-agenda.json, starter/docs/launch-checklist.md

Outputs: deliverables/product-boundary.md

Depends on: No prerequisites

  • Time budgeting is separate from calendar scheduling and meeting facilitation.
  • The brief preserves the synthetic nature of the sample.
  • A measurable disconfirmation criterion and owner approval boundary are included.
Plan the editable-agenda walkthrough · design · Waiting on prerequisites

Inspect the local demo and design spec. Create a walkthrough for loading the sample, editing topic minutes and required flags, recovering from a blocked plan, importing a local JSON file, and exporting an explicitly requested result.

Inputs: deliverables/product-boundary.md, starter/docs/design-spec.md, starter/docs/test-protocol.md, starter/demo/index.html, starter/demo/app.js, starter/demo/styles.css

Outputs: deliverables/interaction-walkthrough.md

Depends on: product-boundary

  • The walkthrough can be completed without a server or account.
  • Keyboard and error-recovery observations have explicit pass/fail criteria.
  • Unperformed manual checks remain labeled not observed.
Reproduce the agenda acceptance cases · engineering · Waiting on prerequisites

Run the authored Node standard-library tests and JavaScript syntax checks. Compare every structured case against the core result and record commands and observed results rather than asserting a production launch.

Inputs: deliverables/interaction-walkthrough.md, starter/demo/core.js, starter/demo/app.js, starter/reference/test_agenda.cjs, starter/data/acceptance-cases.json, starter/data/sample-agenda.json, starter/docs/test-protocol.md

Outputs: deliverables/numerical-evidence.json

Depends on: interaction-plan

  • All structured numerical cases pass, including blocked capacity and midnight bounds.
  • The pure core does not mutate imported input.
  • Automated results do not stand in for browser or assistive-technology observations.
Prepare truthful starter launch copy · creative · Waiting on prerequisites

Adapt the supplied landing copy to the agreed product boundary. Clearly distinguish the usable reference demo from planned polish, validation, and public availability.

Inputs: deliverables/product-boundary.md, starter/docs/landing-copy.md, starter/docs/product-brief.md, starter/demo/index.html

Outputs: deliverables/launch-copy.md

Depends on: product-boundary

  • Headline, short description, three feature statements, limitations, and CTA agree with the demo.
  • No claim of customers, time saved, certification, AI behavior, or a generated video is invented.
  • The CTA is an owner-reviewed local-demo invitation, not an unapproved external post.
Prepare the first support kit · customer-success · Waiting on prerequisites

Turn the support playbook and observed numerical behavior into a quickstart, troubleshooting flow, and issue-intake fields. Do not request private meeting content by default.

Inputs: deliverables/numerical-evidence.json, deliverables/launch-copy.md, starter/docs/support-playbook.md, starter/data/sample-agenda.json

Outputs: deliverables/support-kit.md

Depends on: numerical-verification, launch-copy

  • Instructions explain blocked plans, unscheduled optional topics, and explicit local export.
  • The intake requests reproduction with synthetic topics before personal content.
  • No retention, support response SLA, or staffed service is promised without an owner decision.
Prepare a reversible channel approval request · distribution · Waiting on prerequisites

Select proposed distribution surfaces and describe exact content, audience, publication owner, success measurement, and takedown route. Produce a request only; do not publish, spend, collect analytics, or contact people.

Inputs: deliverables/product-boundary.md, deliverables/launch-copy.md, starter/docs/launch-checklist.md

Outputs: deliverables/channel-approval-request.md

Depends on: launch-copy

  • Every proposed external effect has an explicit approval gate.
  • A local zip or static-file delivery is distinguished from a hosted service.
  • Tracking is off by default and no distribution outcome is fabricated.
Observe keyboard and error recovery · design · Waiting on prerequisites

Perform the manual protocol if an authorized local browser is available. Record each actual observation; otherwise record not observed and keep the release gate conditional. Never infer screen-reader behavior from unit tests.

Inputs: deliverables/numerical-evidence.json, deliverables/interaction-walkthrough.md, starter/docs/test-protocol.md, starter/demo/index.html, starter/demo/app.js, starter/demo/styles.css

Outputs: deliverables/accessibility-observations.csv

Depends on: numerical-verification

  • Each protocol item records environment and observed pass/fail/not-observed.
  • Blocked-plan messaging and keyboard-only edit/import/export are covered.
  • No accessibility certification or unperformed user test is claimed.
Prepare an evidence-linked demo candidate · engineering · Waiting on prerequisites

Review numerical tests, support issues, and accessibility observations. Produce a candidate manifest listing exact local source paths, content hashes, unresolved defects, and release blockers; do not hide not-observed manual gates.

Inputs: deliverables/numerical-evidence.json, deliverables/accessibility-observations.csv, deliverables/support-kit.md, starter/demo/index.html, starter/demo/styles.css, starter/demo/core.js, starter/demo/app.js, starter/docs/launch-checklist.md

Outputs: deliverables/demo-candidate.json

Depends on: accessibility-walkthrough, support-readiness

  • All four demo files are identified with locally computed public-source hashes.
  • No unresolved or unobserved gate is represented as passed.
  • The candidate includes no credentials, remote dependencies, or invented signatures.
Prepare a video production brief, not a video claim · creative · Waiting on prerequisites

Adapt the original storyboard to the actual candidate behavior. Supply timing, captions, screen states, and truthful narration copy for later approved production; do not call a storyboard a rendered asset.

Inputs: deliverables/demo-candidate.json, deliverables/launch-copy.md, starter/docs/storyboard.md

Outputs: deliverables/video-production-brief.md

Depends on: demo-candidate

  • The proposed sequence totals 24 seconds.
  • Every product behavior shown exists in the candidate or is explicitly marked proposed.
  • The handoff says no video, voiceover, or public distribution has been generated by this task.
Record the conditional go-or-no-go recommendation · product-strategy · Waiting on prerequisites

Evaluate the candidate, support kit, observed interaction evidence, and channel request. Write a decision recommendation with outstanding owner approvals and a no-go path.

Inputs: deliverables/demo-candidate.json, deliverables/support-kit.md, deliverables/accessibility-observations.csv, deliverables/channel-approval-request.md, starter/docs/launch-checklist.md

Outputs: deliverables/launch-decision.json

Depends on: demo-candidate, channel-approval

  • The recommendation names numerical, manual, support, and publication gates separately.
  • No public launch is claimed from a local test or decision draft.
  • An unresolved mandatory gate produces no-go or conditional status, never unconditional approval.
Assemble the approval-gated launch runbook · distribution · Waiting on prerequisites

Create a sequenced runbook for later owner-approved delivery, verification, and withdrawal. Treat any video production as pending until an actual rendered file is verified.

Inputs: deliverables/launch-decision.json, deliverables/channel-approval-request.md, deliverables/video-production-brief.md, deliverables/demo-candidate.json, starter/docs/launch-checklist.md

Outputs: deliverables/launch-runbook.md

Depends on: launch-decision, storyboard-handoff

  • Each publication step requires the appropriate owner's explicit approval.
  • The runbook has verification and takedown steps for every proposed surface.
  • Storyboard, rendered video, published demo, and observed usage are separate evidence states.
Prepare a minimal consent-aware learning instrument · customer-success · Waiting on prerequisites

Draft questions to learn whether people understand required versus optional time budgeting. Use synthetic examples and do not collect responses or personal agendas as part of this seed.

Inputs: deliverables/launch-runbook.md, deliverables/support-kit.md, deliverables/product-boundary.md, starter/docs/support-playbook.md

Outputs: deliverables/feedback-instrument.csv

Depends on: launch-runbook

  • Questions separate comprehension, task completion, and usefulness.
  • Each field has a purpose and optionality; no personal agenda text is required.
  • Responses and customer validation remain absent until an authorized study occurs.

Included starter artifacts.

These are files in the ZIP, not promises to generate them later. Reference examples do not mean the engagement is complete.

Package SHA-256: 5bd39ca17e4bc4900fd1b7d851a76d9e2528dca0dec40f6a3c81f0cd427318e4

Initialize with the RAPP Work SDK.

  1. Inspect seed.json, initialize.json, and the exact dependency pins.
  2. Choose your owner label and a new destination. Use the installed, verified SDK to plan the Organization and member Workspaces.
  3. Approve complete native plans and their exact digests before applying. Review declared template copies and pointer registrations separately.
  4. Claim a ready task with a capable authorized AI host, produce the requested output, and attach actual acceptance evidence.

No private membership, signing, spending, external communication, publication, or federation activation is granted by this seed.