The First-Party Rapplication Company

Read the operating model and templates. Propose an original persona label, one product focus, role separation and effect boundaries. Obtain configuration review through the owner's existing environment; unfilled identities and permissions remain explicit blockers, not made-up authority.

Inputs: starter/docs/operating-model.md, starter/docs/pipeline.md, starter/templates/founder-ceo.json, starter/templates/ceo-charter.md

Outputs: deliverables/company-configuration.json

Depends on: No prerequisites

• Seven team roles plus separate casework are preserved without copying team content into the Organization.
• CEO self-approval, direct publication and merge remain disallowed.
• Real role bindings and owner decisions are private, externally validated references or visibly unfilled; no identity is fabricated.

Turn the synthetic proposal into a reviewable product boundary. Select the intended authorized chat host or record it as unavailable; state adapter work, exclusions, acceptance, budgets and a disconfirmation criterion. Do not claim research or runtime access.

Inputs: deliverables/company-configuration.json, starter/templates/product-spec.md, starter/docs/chat-acceptance.md, starter/data/acceptance-cases.json

Outputs: deliverables/product-spec.md

Depends on: configure-company

• Fixed grammar and any proposed host intent translation are distinct.
• Persistence, external effects and release authority are not silently added.
• Missing host access and unperformed user research remain explicit.

Define empty, add, list, completion, duplicate, refusal and restart behavior. Specify host keyboard and announcement checks without claiming they were observed. Keep every action inside the product scope.

Inputs: deliverables/product-spec.md, starter/docs/chat-acceptance.md, starter/docs/craftsmanship-rubric.md

Outputs: deliverables/chat-design.md

Depends on: specify-product

• Each journey has expected output, failure behavior and a verification method.
• Reference process memory is never presented as durable storage.
• Unobserved host accessibility is labeled not observed.

Write help and failure/restart guidance consistent with the proposed product. Define consent-aware intake using synthetic reproductions and minimum necessary data. Do not promise a staffed service.

Inputs: deliverables/product-spec.md, deliverables/chat-design.md, starter/docs/support-playbook.md, starter/templates/feedback.json

Outputs: deliverables/support-kit.md

Depends on: design-chat

• Unknown commands, duplicate IDs, limits and session loss have actionable explanations.
• No credential, full transcript, real checklist or private path is required by default.
• Any service level, retention or outreach commitment awaits owner approval.

After separate local execution approval, run the authored Python standard-library suite and command examples. Record exact commands, source hashes and observed results, including negative cases. This is source-level evidence, not live chat qualification.

Inputs: deliverables/product-spec.md, deliverables/chat-design.md, starter/README.md, starter/reference/checklist.py, starter/reference/test_checklist.py, starter/data/acceptance-cases.json

Outputs: deliverables/reference-evidence.json

Depends on: design-chat

• Acceptance fixtures and mutation/refusal/determinism tests actually pass or retain their failures.
• Only process memory changes; no external runtime or publication is claimed.
• Blocked execution is reported honestly instead of inventing results.

Implement the approved host integration using existing native interfaces only if authorized capabilities exist. Bind source, candidate, dependencies, support, suite and proposed public distribution with exact relative-path inventories and hashes. Run local checks and list every unproven gate.

Inputs: deliverables/reference-evidence.json, deliverables/support-kit.md, deliverables/chat-design.md, deliverables/product-spec.md, starter/templates/candidate-manifest.json, starter/docs/pipeline.md, starter/data/pipeline-gates.json

Outputs: deliverables/candidate-manifest.json, deliverables/build-evidence.json

Depends on: reference-baseline, prepare-support

• All six subject components are bound, including an explicit dependency lock even when empty.
• The selected chat adapter is implemented and tested or the task stays blocked.
• Canonical record checks use pinned native tools; structural success is not authenticated acceptance.

Request and verify owner permission for a specific internal channel. Distribute only the bound candidate with support and recovery instructions using trusted native tooling. Record the actual result and whether the channel is signed; an unsigned channel requires explicit policy.

Inputs: deliverables/candidate-manifest.json, deliverables/build-evidence.json, deliverables/support-kit.md, starter/docs/pipeline.md

Outputs: deliverables/internal-release.json

Depends on: build-candidate

• Actual internal artifact hashes match the complete candidate subject.
• Unsigned delivery is never labeled a signed Hive release.
• No public write, authority grant or channel access is inferred from the seed.

Using an authorized observer distinct from builders and CEO, run the candidate through its intended chat host. Cover normal, negative, duplicate and recovery journeys. Record evidence and timings with minimal synthetic content; stop if the host or authority is absent.

Inputs: deliverables/internal-release.json, deliverables/candidate-manifest.json, deliverables/chat-design.md, starter/docs/chat-acceptance.md, starter/templates/dogfood-scorecard.json

Outputs: deliverables/dogfood-scorecard.json

Depends on: internal-release

• Every observation binds candidate, internal artifact, runtime and qualification suite.
• Not-observed and failed journeys are not converted into passes.
• A unit run or mocked chat cannot satisfy the actual chat-use gate.

Turn observed dogfood issues into minimal reproducible feedback. Preserve failures, separate hypotheses from observations, and request no additional private data without need and consent.

Inputs: deliverables/dogfood-scorecard.json, deliverables/support-kit.md, starter/templates/feedback.json, starter/docs/support-playbook.md

Outputs: deliverables/feedback.json

Depends on: dogfood-chat

• Each finding has a candidate binding, reproduction, expected/observed behavior and evidence reference.
• No feedback or customer satisfaction is fabricated.
• Raw chats, identities and private locations stay outside public artifacts.

Review actual evidence with the craftsmanship rubric. Produce a recommendation and a preserved punch list with concrete loci, severity, ownership, expected behavior and evidence. Name one focus; a ship recommendation has no approval force.

Inputs: deliverables/feedback.json, deliverables/dogfood-scorecard.json, deliverables/candidate-manifest.json, starter/docs/craftsmanship-rubric.md, starter/templates/punch-list.json, starter/templates/ceo-charter.md

Outputs: deliverables/review.json, deliverables/punch-list.json

Depends on: triage-feedback

• Unobserved dimensions remain not-observed; criticism targets the work, not people.
• The review inspects recovery, test quality, claims, licenses and simplicity as well as chat copy.
• The recommendation is ship/iterate/stop, never a self-issued release approval.

Prioritize the review's one focus and required repairs. Plan bounded changes with acceptance and disjoint ownership. If no change is justified, record no-change explicitly; do not invent a defect or pretend that an iteration happened.

Inputs: deliverables/review.json, deliverables/punch-list.json, deliverables/product-spec.md, starter/docs/pipeline.md

Outputs: deliverables/iteration-plan.md

Depends on: review-craftsmanship

• Every proposed repair links to an observed finding and verification method.
• Blocker/major findings cannot be deferred through shipment.
• A changed subject requires new internal release, dogfood, review and verification.

Apply approved repairs and rerun affected and regression checks. Freeze the new complete subject and link its predecessor without editing old evidence. For an approved no-change assessment, preserve every subject hash and explicitly record that no successor was built.

Inputs: deliverables/iteration-plan.md, deliverables/candidate-manifest.json, deliverables/build-evidence.json, deliverables/support-kit.md, starter/templates/candidate-manifest.json, starter/docs/pipeline.md

Outputs: deliverables/final-candidate.json, deliverables/iteration-evidence.json

Depends on: plan-iteration

• All changed bindings invalidate previous qualification; none is inherited by version label.
• Failed observations and predecessor artifacts remain available privately.
• The result is build evidence, not independent approval.

Repeat authorized internal distribution for changed bytes. Reference an earlier distribution only if every subject binding is unchanged and its authority remains current. Keep the signed/unsigned qualification visible.

Inputs: deliverables/final-candidate.json, deliverables/iteration-evidence.json, deliverables/internal-release.json, starter/docs/pipeline.md

Outputs: deliverables/final-internal-release.json

Depends on: revise-candidate

• Final internal artifact and full subject hashes match exactly.
• Any absent permission or failed delivery blocks dogfood.
• No public channel or fabricated signed receipt substitutes for internal evidence.

Repeat actual chat qualification for every changed candidate and the final suite. Compare earlier failures without erasing them. Unchanged evidence can be referenced only with exact current bindings; unobserved work stays blocked.

Inputs: deliverables/final-internal-release.json, deliverables/final-candidate.json, deliverables/dogfood-scorecard.json, starter/docs/chat-acceptance.md, starter/templates/dogfood-scorecard.json

Outputs: deliverables/final-dogfood.json

Depends on: final-internal-release

• All mandatory final journeys have actual pass evidence or shipment remains blocked.
• Identity separation from builders and CEO is validated by the trusted host.
• Reference fixtures are never represented as live qualification.

Review the final subject, dogfood and iteration evidence. Carry every prior finding forward with an evidenced disposition. Recommend ship only with mandatory criteria met; otherwise request successor tasks and retain the blocked gate.

Inputs: deliverables/final-dogfood.json, deliverables/final-candidate.json, deliverables/iteration-evidence.json, deliverables/review.json, deliverables/punch-list.json, starter/docs/craftsmanship-rubric.md, starter/templates/punch-list.json

Outputs: deliverables/final-review.json, deliverables/final-punch-list.json

Depends on: final-dogfood

• No open blocker/major finding is hidden, deleted, or relabeled to allow shipment.
• Current-subject evidence supports every resolution.
• A favorable recommendation still requires independent verification and a separate decision.

Select only the authorized public payload, matching the final subject's intended projection inventory. Prepare truthful PR copy and a reversible publication proposal, not a public write. Never use a private organization or Hive root as the input distribution.

Inputs: deliverables/final-candidate.json, deliverables/final-review.json, starter/docs/promotion-checklist.md, starter/templates/promotion-request.json

Outputs: deliverables/public-projection.json, deliverables/pr-draft.md

Depends on: final-review

• Outgoing filenames and byte hashes match the frozen public-projection inventory.
• The proposal excludes private records, identities, native stores and conversations.
• No submission, merge or publication is claimed.

Scan every outgoing filename and byte, decoded form, nested archive and draft PR text with bounded fail-closed tooling. Supply private denylist values only at runtime. Review all source/dependency/asset licenses and required notices.

Inputs: deliverables/public-projection.json, deliverables/pr-draft.md, deliverables/final-candidate.json, starter/docs/promotion-checklist.md

Outputs: deliverables/privacy-report.json, deliverables/license-review.json

Depends on: prepare-projection

• Zero findings cover complete contents and archive members; unreadable or unscanned inputs block.
• Reports bind exact projection and PR text without including private denylist values.
• Licenses and notices are complete with no unresolved redistribution conflict.

Have authorized verifiers distinct from all builders and CEO independently reproduce acceptance, inspect final findings, verify public safety and record real evidence through the existing trusted native mechanism. Filling the template is not issuing an authenticated record.

Inputs: deliverables/final-candidate.json, deliverables/final-dogfood.json, deliverables/final-review.json, deliverables/final-punch-list.json, deliverables/privacy-report.json, deliverables/license-review.json, starter/templates/independent-verification.json, starter/docs/pipeline.md

Outputs: deliverables/verification.json

Depends on: review-projection

• Distinct verifier identities and current grants are actually checked; duplicate labels do not increase the count.
• Verification binds all subject components, review and actual checks.
• A structural RAPP/1 pass is labeled separately from authenticated acceptance; failed verification cannot approve.

Assemble a request for the owner-selected external decider. Obtain a separate actual decision after verification through the trusted native host. The decider is neither a builder nor the CEO; release merely retains the reference and cannot fill an approval on their behalf.

Inputs: deliverables/verification.json, deliverables/final-review.json, deliverables/final-candidate.json, deliverables/company-configuration.json, starter/templates/decision-receipt.json, starter/docs/pipeline.md

Outputs: deliverables/decision-reference.json

Depends on: independent-verification

• A real separate decision references the exact review, verification and subject, and follows them.
• No template, CEO statement or failed verification is accepted as approval.
• Absent or refused decisions leave promotion blocked.

After exact publication approval, revalidate the decision, outgoing bytes, PR copy, privacy/licenses, all local suites and current required CI. Use existing authorized access to prepare a non-draft PR. If submission is unavailable or unapproved, retain only the local proposal and report the blocker.

Inputs: deliverables/decision-reference.json, deliverables/public-projection.json, deliverables/pr-draft.md, deliverables/privacy-report.json, deliverables/license-review.json, starter/templates/promotion-request.json, starter/docs/promotion-checklist.md

Outputs: deliverables/ready-pr.json

Depends on: request-separate-decision

• The actual PR's exact head, diff and text match owner-reviewed artifacts and current passing required checks.
• Changed bytes or text trigger fresh affected checks; pending/missing/skipped/failed required checks block.
• The handoff says ready for owner merge, not published or shipped.

Wait for the owner's separate merge decision and action; do not merge or infer consent. After an actual merge, verify the checked head and published artifact against the approved projection and record a sanitized reference plus withdrawal procedure.

Inputs: deliverables/ready-pr.json, deliverables/public-projection.json, starter/templates/promotion-request.json, starter/docs/promotion-checklist.md

Outputs: deliverables/owner-merge-reference.json

Depends on: ready-public-pr

• Completion requires an observed owner-merged PR and verification of the resulting artifact.
• Release does not perform automated merge or claim a still-open PR as shipped.
• Missing authority, head drift or publication mismatch is retained as a blocker.