A living village.
Real things you can use.

Product decision

Crew should turn an intention into something immediately useful, let people use or change it in place, and make passing it to a friend as understandable as passing a video. On the next visit, the useful thing should be ready in a familiar place. The village provides personality and continuity; the work itself provides the reward.

The recommended architecture is living apps with contextual Crew. A workout is an activity with a timer and a truthful weekly history. A game is a board with another person and a visible turn. An episode is something to watch. A quick answer stays a quick answer. These share reliable input, ownership, correction, and sharing behavior; they do not share one generic title–list–confirmation screen.

The current 39-flow proposal should not be repaired by improving its subtitles. Its central failure is that people must interpret the product's machinery before understanding what they receive. Direct inspection reproduced the duplicate waveform in typing mode and confirmed the generic invitation-sender, empty request, and nested Shelf-list patterns. Those findings are specific to the review demo; they are not assertions that identical defects exist in the installed native build.

The recommended first proof joins four moments: obtain a useful personal routine; correct it directly; send a clean usable copy; return to its real progress on Shelf. A second proof starts and finishes a game with an actual friend. A third connects a real short episode to a usable or playable creation. These are validation slices within the retained all 39 intent. They do not authorize a smaller B67 release. Build 66 is already VALID in App Store Connect; the next build number is 67. Product implementation, the held hosted attempt, and release remain paused pending reconciled scope.

The full recommendation below distinguishes documented reference behavior, observations of the rejected demo, and proposed Crew behavior. No reference product proves Crew demand. No cost, conversion, retention, or latency target is presented as an achieved result.

Feedback decisions and acceptance

The preserved export contains 26 decisions: 11 like, 8 change, 7 no. The accompanying instruction explicitly says that a negative verdict is not feature cancellation. Features 27–39 were not reviewed. Positive verdicts with notes still require those notes to be addressed. Evidence: original crew-feature-feedback.json, review crew-all 39-20260910, and Crew messages84618/84623.

Direct observation of the rejected demo

At desktop viewport 1440×1000, the social entry presents an anonymous generic sender row and a separate review-invitation step. The next state advances to an invite-only-room row and an Inspect safety action. It does not establish who invited the viewer, what is being played, or the reward for joining. The creation entry displays a Request placeholder beneath a “Describe a tool” heading. Shelf repeats an owned-app category inside the already-selected Yours surface. Activating the keyboard in row 09 renders the small composer waveform and the full lower voice capsule simultaneously.

Retained screenshots before-social.png, before-create.png, before-shelf.png, and before-keyboard.png were opened and visually inspected. These are evidence of the rejected experience, not proposed replacements. The exact text-boundary defect reported in row 07 has not been attributed to a specific CSS/native root cause; its acceptance remains open rather than declared fixed.

Reference research and product implications

The benchmark is a set of strong reference patterns, not a claim that a market-wide best product has been proven. Sources were read on 10 September 2026. Current help pages take precedence over older announcements where their detailed behavior differs. Publisher screenshots and interactive help are distinguished from authenticated hands-on sessions.

Conflicts and evidence limits

Apple's invitation headline and its detailed help are compatible only if “without an account” is distinguished from “without verification.” Spotify and Discord likewise refute a blanket claim that modern social flows require one total tap. The design target is one obvious action at a familiar moment, with the total journey and any consent counted honestly.

No authenticated production TikTok, Instagram, Discord game, Spotify Jam, Gemini voice session or purchase was completed during this research. Public publisher behavior, viewed reference imagery, current help, research papers and the observed Crew demo support the recommendations. Before implementation acceptance, actual device reference walkthroughs should verify the chosen interaction in the relevant region/version. That limitation must not become a fabricated competitor-performance claim.

Direct English TikTok help returned empty/index-only responses through both available readers. A localized official search result corroborates the familiar share→recipient→send pattern, but it is not used as the sole evidence for a critical requirement. Exact current TikTok reward rules and rates are deliberately not adopted. Failed/empty responses are retained and not counted as successful source reads.

Grok and Astra: decisions after comparison

Two independent concept critiques inform this recommendation: Astra's complete eight-journey review and Grok's full 39-row replan. Their agreement is useful design judgment, not consumer validation. Original responses and their provenance are retained with this report.¹²

Convergence adopted: keep the village/native foundations; make Shelf useful from actual behavior; use one composer/capsule system; put correction on the changed object; share the recognizable thing; make protection and accounting support the activity rather than dominate its first screen. Both critiques reject turning an internal acceptance ledger into 39 nearly identical consumer destinations.

The response file enumerates all 39 row titles in order; that enumeration was checked against the canonical source. Its feedback descriptions were checked against the original 26 decisions. Grok's interface reported an attachment-reading inconsistency despite its detailed enumeration; therefore the response is not relied on as the authority for any feedback verdict. The sealed export remains authoritative. Both model recommendations remain proposals until tested and approved.

Alternatives and recommendation

Choose B as the product architecture, using A's smallest vertical slice to test it. Keep village presence without making users walk to a building to complete an action. C is not recommended. No permanent new destination or new product name is needed.

Experience architecture

There are a few stable places and varied things to do inside them.

• Village: the familiar arrival, residents, compact voice capsule, keyboard icon, and Shelf icon. Cold launch reaches a usable scene. Real night art, smoke, water, wind, and grass create atmosphere without hiding readiness or requiring exploration. Conversations remains the full-screen top-right destination. Residents express identity and accountable work; they do not require care, feeding, or activity streaks.
• Shelf, provisional existing name: the owned mini-apps place. Show a handful of frequently used apps with their actual current state, plus small summaries grounded in use. A workout might show the last three sessions and its next start action; a shared game shows the board and whose turn it is. It is not a conversation list. A user's pinned positions stay stable; contextual suggestions occupy a bounded area. Frequency alone must not reward compulsive use or bury a useful infrequent app. Removal and restoration never resurrect a stale live instance.
• Explore within the same mini-apps destination: search and compact three-item highlights remain. Entries show what can be done, not abstract descriptions. A puzzle exposes a real playable preview; a routine shows its steps and duration. Creator identity, actual signals, and sponsorship disclosure sit with the object. There is a viable new-user selection before personalization has learned anything.
• The open experience: expands inline as already agreed where appropriate. A timer, board, chart, or video is the primary content. Crew's common composer stays available with the correct selected account, topic, and app context. Full-page destinations reach the top; true Back restores the actual previous state. Avoid using an extra nested card as a universal container.
• Conversations: full-screen human-readable topics, messages, and agents. This is where conversation history belongs. It can reopen the relevant app at its current state without becoming the owner of that app's data.
• TV: a real viewer reached through the same product/catalog context, with a channel identity and link back to the associated creator/app. TV has its own media grammar: play, captions, channel switching, and a contextual use/remix action. No unrelated fifth navigation system is proposed.

Stable placement and simple controls matter more than novelty. “Adaptive” means useful content changes; it does not mean every launch moves the controls. Default to at most one unsolicited suggestion per visit and no social push notifications before someone has chosen to participate. These are proposed limits to test.

Interaction grammar: use verbs tied to outcomes. “Start workout,” “Play a round,” “Send this,” “Use mine,” “Make it easier,” “Keep this,” and “Watch next” are examples. They are not a required permanent taxonomy. A viewer must understand the object without knowing that it is generated, installed, claimed, or versioned.

Effort accounting: count meaningful user decisions, text entry, permission prompts, and time waiting. “One click” should apply to an already-understood, reversible action. Choosing a recipient still costs an action; entering a payment commitment still needs clear authorization. Do not hide those costs by counting only the final button. OS permissions are counted separately and requested only when needed. Times below are proposed experience budgets, not measured system capability.

Eight complete journeys

J1. A useful first minute, then a useful week

Situation: a person wants a quick home workout and has no Crew history.

Sees: a ready village and working composer, without compulsory profile fields. A small optional starter can demonstrate “A 10-minute workout.” No empty Shelf tour or questionnaire is required.

Does: says or types “Make me a 10-minute home workout.” Crew uses an ordinary low-intensity starter with clearly editable assumptions; it does not infer a medical condition or claim personalized clinical advice. If equipment is necessary to choose the shape, offer one compact choice such as “No equipment.” The workout itself opens: one exercise at a time, a timer, pause/skip, and visible overall progress. The user starts it directly.

Gets: an activity they can complete, with completion saved in that app. On returning, Shelf shows the same app and a small actual weekly summary. A spoken “Log 20 minutes from yesterday” goes into the same tracker, marked as user-entered. It is not another conversation item called “Workout request.”

Effort budget: one utterance or starter tap; at most one material clarification before a usable first result. Proposed target: first usable interaction within 60 seconds, excluding permission denial recovery. Reuse is one tap from Shelf. Starting a workout never requires opening a chat.

Recovery/privacy: if generation fails, keep the request and offer the reliable starter rather than an empty shell. Do not pretend a sample workout was generated for the user. If logging fails, show the unsaved session with retry; do not mark it completed in the chart. Health-related context is not automatically shared or promoted into general memory. A first useful action precedes optional profile enrichment.

Test: unaided users begin, complete one step, leave, and return to the same app. They correctly explain where completion is stored and distinguish recorded activity from generated advice. Compare total effort with their actual existing routine.

Rows:4–9,12,19,33–36,38–39.

J2. Make something by changing something, then send a usable copy

Situation: the person now says “Make a version my sister can do in five minutes.”

Sees: the real workout shorten in a preview. The change is perceptible in the exercise sequence and duration. A discreet “Back to 10 minutes” action makes undo concrete. No generic “Correction controls” screen appears.

Does: tries it, then taps the familiar share affordance. The share preview names the real object, shows a recognizable first state, identifies creator and sender, and says that the recipient receives a fresh copy. The native recipient picker follows. No folder, workspace, permission role, or access checklist is on this route.

Gets: the sister opens a browser link and can begin the clean five-minute workout without signing up. Completion stays in her guest session. “Keep this” is offered after value, creating an owned copy through authentication with a resumable claim. Original history, personal notes, and profile information are excluded from the shared definition. A real eligible activation can later appear in creator accounting according to the chosen funded rule.

Effort budget: sender: share affordance plus recipient selection and the platform's normal send, all counted. Recipient: open link, one action to use. Account creation cannot precede the first permitted use. If changes will expose personal material, a specific preview and confirmation is additional work that must be counted.

Recovery/privacy: the link identifies an immutable revision. Repairing the sender's app does not silently alter what was sent. Publish an update deliberately; an existing owner can accept it without losing personal records. Revoking the link stops new access; it cannot promise to erase an already-owned copy. An interrupted claim resumes the same state and does not create duplicate copies. Report is reachable from the object menu.

Test: show recipient-only participants the link with no explanation. They name the object, begin it, understand whose data they are seeing, and keep it successfully. Deliberately change the source while the recipient is active; verify stability. Count unintended shared fields: target zero in the test cases.

Rows:13–16,19,26,35,39.

J3. One friend, one round, no room-management ritual

Situation: “Make a quick picture-pair game for me and Maya.”

Sees: a playable board immediately, with a short solo try available. The invitation previews the actual game and challenge: “Play a round with me.” An invitation is clearly different from sending a clean reusable copy in J2.

Does: taps play-with-friend and chooses Maya. Maya opens the link, sees the sender and board, and taps “Join.” The current game begins. Small participant indicators and the board's state show whose turn it is. A move is direct manipulation, not a confirmation card. A chosen display name can be lightweight; joining still creates a server-recognized participant identity.

Gets: two people complete a real shared round and see the same score. “Again” begins a new round with the same invited participant. Keeping the game on Shelf lets the user play again later; it does not expose the old private room to everyone who finds the game.

Recommended bounded model: initially two-player, asynchronous turns with a live presence indicator when both are present. This satisfies real multiplayer while giving a testable model; it is a proposed breadth decision, not approval to erase a previously ratified player requirement. Confirm the canonical agreed player count before implementation. Keep larger groups as explicit scope reconciliation if required.

Effort budget: sender selects the game and recipient; recipient uses one join action after opening. No contact import, friend-request acceptance chain, safety setup, or room settings before the first move. No forced signup for allowed guest participation.

Recovery/privacy: server decides valid moves, turns, revisions, and score. A conflicting move updates the board with “Maya moved first,” preserving the player's ability to act next. Disconnect retains the round; return restores the current state. No penalty or manipulative streak break for inactivity. Invitation is limited to one joining slot by default; if forwarded and taken by the wrong person, host removes them and renews the invite. Explain this product behavior plainly where needed, never imply that a bearer link cryptographically identifies Maya. Block/report/leave are contextual participant actions. Blocking immediately stops new invitations from that identity; abuse handling must address guest identity rotation.

Test: simultaneous moves, double taps, reconnect, forwarded invitation, revoked invite, blocked participant, room expiration, and abandoned round. Every client converges on one valid result. A novice knows who is present and can leave without help.

Rows:13,16–19,35,39.

J4. Talk while doing; remember a correction without becoming creepy

Situation: during trip preparation, “Add these to the packing app,” with two photos and a long pasted itinerary. Later: “I always pack contact lenses, not glasses.”

Sees: the selected app's name/context remain evident while composing. A compact centered waveform uses the capsule effectively. Typing replaces the voice presentation; only one active input surface exists. Long text scrolls and both attachments remain visible. The waveform reflects listening; task feedback changes only when actual work begins.

Does: keeps talking, pauses, and corrects in ordinary language. Crew adds the items to the current trip rather than creating another packing app. “Remove the second bag” previews/removes the specific bag, with an intelligible undo. Crew asks “Remember contact lenses for future packing?” once, next to the correction. The user can say “Just this trip.”

Gets: a packed state they can inspect and use. Next trip, an accepted memory is applied and can be traced to the earlier correction. A small note such as “Used your contact-lens preference” opens its source and edit/remove action. The notebook contains actual lessons and outcomes. A weekly scene can show “Packing remembered; restaurant request needed correction,” with links, not fake XP or invented competence.

Voice contract: default quiet execution with visual/haptic confirmation. Spoken responses are an explicit mode. Team-call mode is separate: one named agent speaks at a time, a coordinator controls turn order, and the user can interrupt or direct another agent by name. Renaming preserves identity. Never simulate coordination by generating several personas agreeing with one another. Provider routing is evaluated backstage; optional provider detail remains available.

Effort budget: one toggle begins/ends listening, with continuous dispatch inside that explicit session. No repeated Send/Stop ritual. No more than one clarification when target context is ambiguous. Memory consent should cost one choice and should not be requested for every trivial correction.

Recovery/privacy: input and attachments survive Back, keyboard transitions, interruption, and temporary network loss in the same account. Account switching hides and fences them. Every accepted action has an outcome receipt; cancellation cannot claim to reverse an external effect already completed. Do not process another person's nearby speech as authorization; if speaker certainty is inadequate, keep it as uncommitted input and ask the account holder. Raw mic diagnostics are never the main surface. Microphone unavailable has a concise explanation and immediately usable typing. Removing a learned preference stops future use and updates its source/retention state; clearing one visible chip cannot falsely claim all retained data is erased.

Test: barge-in, named-agent switch, team turn interruption, background speaker, denied mic, uncertain transcription, attachment retry, long-input completeness, account switch, app switch mid-utterance, and correction reuse a week later. Establish measured latency budgets against the current control; do not market low latency from an animation.

Rows:6–9,11–12,14,19,33–39.

J5. Discover something useful, with sponsorship that cannot distort the answer

Situation: “Something quick to cook tonight” in Explore.

Sees: a small actual catalog of relevant experiences. The visible content is food, time, and a usable cooking sequence, not a list of tools. Search and the compact three-item highlight preserve their accepted roles. A clearly labeled sponsored highlight can exist separately for eligible free users. It must not masquerade as the best answer.

Does: opens the cooking experience, changes servings by direct interaction, and starts the timer. “Use what I have” can accept a photo or typed ingredients. The app remains useful with no purchase. If the user explicitly seeks a delivery or shopping option, a relevant commercial option can appear with the reason it fits, price/source freshness where available, and affiliate/sponsor disclosure.

Gets: dinner help first. “Hide sponsored suggestions” vetoes that class of suggestion in the current context and persists according to the selected preference contract. A sponsor never changes the ranking of personal recommendations. Payment disclosure is attached to the actual option; source and ranking rationale can be inspected without becoming the main screen.

Effort budget: one open from discovery to a usable experience; one tap for a normal direct action. No sign-in, credit screen, or advertisement gates opening or ordinary use of an existing app. Any paid generation triggered within an app must be distinguished before it runs.

Recovery/privacy: if ingredient recognition is uncertain, let the person correct visible ingredients before consequential changes. Sponsored inventory empty means no fake placeholder or invented promotion. Paid users see no ads. Respectful placement: proposed launch default is small disclosed Explore sponsorship only, with an explicit per-session cap and no repeats after dismissal; no village, personal app, active voice, game turn, or TV interruption. The precise cap remains a commercial/product decision. Outcome commerce stays in scope as the explicit-intent case above, never as covert sponsored ranking.

Test: blind relevance comparison with and without a paying sponsor, paid/free account transitions, sponsored disclosure comprehension, veto persistence, and “no suitable sponsor.” A higher-paying worse option must never displace the selected best option. Real money/event trace must support every claimed reward.

Rows:10,15,19–25,29,35–36,39.

J6. Earn because someone got value; spend only on understood work

Situation: someone makes a genuinely useful cooking timer, shares it, and later creates a more complex variation.

Sees: ordinary use stays free. At a creation boundary requiring paid work, a concise quote is attached to the requested result: “Create this variation: up to N credits,” using an actual server quote. N is not a proposed commercial price. A first meaningful free creation comes before the first limit prompt. Opening, normal using, and sharing an existing app show no balance ceremony.

Does: accepts the quoted creation once. If out of included work, chooses a clear plan offer or an optional eligible sponsored reward in the appropriate discovery/reward context. It states the actual reward and eligibility, and returning restores the original draft. Payment uses native purchase and the same plan catalog as the server. Restore appears where a returning payer needs it. Cancel/refund consequences are stated in the purchase context and owned account controls.

Gets: a completed result and a plain receipt. A creator can see “Three people started using your timer” when verified, and separately any funded pending/available reward. A creator's first result is usefulness, then an earned-value receipt, not an unexplained coin waterfall. Withdraw appears only when that account and earned balance are actually eligible.

Recommended economy concept: one named credit unit and one authoritative balance ledger, with provenance for included, purchased, sponsored, promotional, and creator-earned credits. Provenance is required to prevent purchased or promotional credits pretending to be withdrawable earnings. Available-to-use and eligible-to-withdraw are views over ledger entries, not two invented exchangeable currencies. No unratified cash-conversion rate, split, threshold, plan price, or provider is displayed.

Funding hypothesis: choose a capped creator pool funded from settled retained revenue after measured costs and reserves, with adoption/conversion as audited allocation signals. Eligible net ad value may contribute a defined allocation. Adoption alone never mints uncapped money. Referral bounties, direct sales, and ad share remain candidate mechanisms to reconcile, not simultaneous entitlements. A coherent selected funding model fulfills row 28; the exact approved contract is still needed. Zero funded pool means zero distributable earnings, with truthful pending analytics. A launch that advertises creator earning must demonstrate a real funded eligible event before calling row 13/26 complete.

Effort budget: one explicit acceptance for newly chargeable work. No repeated debit for transport retry or a repair of the same failed promise within the stated included repair budget. Plan purchase includes its native confirmation; do not describe it as frictionless one-tap free use. Creator earnings are optional to inspect, not a required daily workflow.

Recovery/privacy: reserve at accepted job, settle only against delivered work under the quoted contract, release/refund failed or duplicate work as specified. Quotes expire visibly without losing the draft. Required paid upstream work inside an existing app must have a distinct preflight; basic app use cannot silently become metered. Reward only on validated eligible provider events; no credit for opening an ad surface or tapping retry. Record gross event, deductions, attribution, shares, reversal, and payout eligibility. Reinstall, offline restore, refund/revoke, self-referral, device farms, duplicated receipt, and forged client balance all need real verification. Anti-farming may delay or reject a reward with a plain reason and appeal route; it must not block normal use or silently seize unrelated balance.

Test: consumer predicts free vs charged behavior in at least 9 of 10 scenarios; ledger reconciliation exact on duplicates/failure/refund; one real eligible ad event credits the correct parties exactly once; paid accounts excluded; one real permitted restore and withdrawal route proven before claiming those capabilities. The numerical comprehension target is proposed, not observed.

Rows:13,20–29,39.

J7. Crew TV: a show worth watching, then something worth doing

Situation: a person opens TV after seeing a creator's “Three tiny dinner tricks” episode.

Sees: an immediately playable published episode with channel/creator identity and captions. The player fills the viewing surface. A small contextual affordance appears only when relevant: “Try the timer,” opening the same usable timer shown in the episode. Returning resumes the episode at its previous position. Switching channels is simple and does not start an invisible generation job.

Does: watches, skips, replays, changes channels, uses the attached timer, or shares the episode. Cold start uses a small explicitly curated selection plus optional interests; no social import is required. “Less of this” is available in context. The sequence ends or offers a deliberate next choice rather than assuming endless autoplay is the goal.

Gets: an enjoyable short show that can connect entertainment to personal utility or play. Taste adapts from the account's actual watch/skip/replay/create/play/remix/share behavior. One accidental swipe or a shared-household session must not permanently define taste. Reset/turn-off controls are accessible. Interest in workout videos is not permission to infer sensitive health status.

Creator continuation: from a working timer, “Make a short episode showing how this helps.” Crew proposes a short storyboard using rights-cleared/owned material, a preview, and an actual bounded generation quote. User or authorized agent-owned channel can create a real episode, preview it privately, and explicitly publish to that channel. Human and agent channel ownership is disclosed; do not pass generated hosts off as people. Share the real episode, receive actual watch/use attribution and any eligible earned value in the same economy. The creator's private usage cost and earnings never appear in the public player.

Recommended technical/product boundary: bounded generated episodes prepared and cached before publication. No new expensive video per channel swipe. A channel may schedule generation only within an explicit private budget and publishing authority; no default perpetual agent broadcast. This still requires real generated content and real playback, not stock mockups dressed as delivered TV. Model/provider/rights/moderation and pricing remain unapproved implementation decisions.

Effort budget: viewer opens and plays with at most one extra action when playback needs user initiation. Creator supplies a sentence and makes at most one meaningful revision before preview; generation latency is separate, honestly shown, and the user can leave. Publishing always remains an explicit action unless the owner deliberately grants a bounded recurring publishing permission. Do not flatten making a show into the same effort claim as watching one.

Recovery/privacy: failed generation preserves storyboard and source material, releases eligible reserved work, and offers a limited repair with no unannounced spend. Interrupted upload resumes. Removed episode leaves a truthful unavailable state; associated owned app need not disappear. Viewer has report/block channel; owner can unpublish. Public episode versions remain tied to their actual sources, creator, attached app version, and content policy status. Imported private app data is excluded by default; specific public preview is required if deliberately included.

Test: real device/channel playback, switching, caption use, resume from associated app, no-spend-on-swipe, bounded scheduled generation, own-behavior cold start, meaningful reset, private-cost isolation, unpublish/report, and actual creator attribution. Compare repeat watching and subsequent voluntary use with a plain feed of unrelated generated clips. This is a test hypothesis, not a claim that utility-linked TV will retain users.

Rows:13,16,19–20,22,26–32,35,39.

J8. A small social success becomes a durable, controllable relationship

Situation: after two enjoyable rounds with Maya, the user wants to play again next week without a contact-directory project.

Sees: the completed game, Maya's chosen identity, and an optional “Play together again” relationship action after success. No social graph is demanded at onboarding. If accepted, the participants can find each other for future invitations within the defined relationship; it grants no access to private apps or memory.

Does: chooses the relationship and, optionally, a notification preference tied to this game. Later says “Open Maya's game,” which resolves the actual relevant owned/shared item, with a brief chooser only if ambiguous. The history behind an invitation is inspectable without pulling the user through safety administration.

Gets: less effort for future play and understandable boundaries. When the user wants to leave, participant menu provides mute, block, report, and remove relationship. Account controls provide export, deletion, and service disconnect. These controls remain easy to find even though they are not the app's opening experience.

Effort budget: no required relationship action for the first round; one optional action to preserve a future connection after value. Block/leave is immediately reachable from the participant. Export/disconnect/delete naturally require clear scope and confirmation; the one-click aspiration does not justify deleting data by accident.

Recovery/privacy: no phone-contact upload unless separately requested and consented to. New invitations from blocked identities stop; an existing shared artifact gets a defined read/play outcome and does not silently reopen access. Export includes owned app definitions/state, conversations, accepted memories, economy receipts, social records and TV metadata as applicable, with others' private information excluded. Disconnect stops future access and separately explains what imported data remains. Delete communicates actual retention obligations, public copies, outstanding payout/refund handling, and completion status. It cannot promise recall of a recipient's exported copy. Guest data has a defined expiry and claim boundary. Provider disclosures cover real voice, model, media, ads, and social processors without a mic diagnostic card on the village.

Test: re-invitation works only under intended consent; identity rename does not bypass block; guest-to-account merge does not expose prior owner's data; export/delete cover every new table and provider; removed memories do not reappear through old app context; abandoned account deletion resumes or reports a precise incomplete state.

Rows:7,9,16–19,21,27,35,37–39.

Before and after: the six immediate experience changes

Cross-journey service contracts

These are engineering and review requirements, not proposed consumer menus.

1. A result must identify what it is. Supported answer, one-off artifact, ongoing app/tracker, game, and episode shapes have distinct interaction contracts. Unsupported requests receive an honest closest option or limitation. Do not output an inert UI and call it an app.
2. Context belongs to the account and object. Every action binds to the selected owner, topic, app revision, and intended participant context. Switching account clears/fences the active context; changing an agent's display name does not change authorization.
3. App definition, personal records, and shared session state differ. Sending a reusable definition starts clean personal records. Inviting joins a shared live session. Immutable share versions preserve recipient meaning. These distinctions are visible through the preview and the resulting behavior, not a permission matrix.
4. Correction is local and understandable. Undo a specific change, preserve private records across app revision, and state when an external action cannot be undone. Repair uses a stated bounded budget and cannot enter an unattended paid retry loop. A failed repair preserves the last working version.
5. Personalization has evidence and limits. Shelf recommendations, memories, agent competence, and TV tastes cite actual owned events when inspected. No fake XP, synthetic popularity, invented social proof, or unsupported cash equivalents. Suppression, correction, and reset work.
6. Money follows validated events. Quote/reserve/settle/reverse and attribution are idempotent. Real incurred cost reconciles with revenue, subsidy, and eligible payout; clients cannot mint or upgrade. A model-route change cannot silently exceed a user's accepted quote.
7. Social joins require understandable participation. Invites expire/revoke under a defined contract, membership is authoritative, score is server-determined, and participants can leave/block/report. Any age-specific design or publishing restriction must be settled explicitly rather than assumed away.
8. Failure is useful. Keep the draft, show what completed, preserve the working object, allow retry without duplication, and separate failed work from pending work. Partial provider failure cannot appear as completed output because an animation finished.
9. Native craft is a correctness condition. No clipped text, overlap, duplicate waveform, stale Shelf state, hidden attachments, or false Back. Dynamic Type, keyboard, safe areas, reduced motion, VoiceOver and touch targets receive device evidence. Compact does not mean hard to touch: preserve an accessible whole-pill target while correcting visible empty space and waveform prominence.
10. Broad capability is not a breadth claim. TV playback, coordinated voice, score authority, source learning, provider routing superiority, subsidy, and earning all need separate runtime proof. A beautiful concept board cannot establish any of them.

Decisions recommended for review

These defaults are review recommendations. Existing approval of all 39 does not establish new ad terms, payout rules, UI designs, provider spend, or deployment authority.

Priority, dependency and scope

Scores below are ordinal planning judgments, not measured impact estimates. Reward/effort/risk use1–5, with 5 highest. A high-reward feature is not automatically cheap or ready. Risk includes loss of user trust, privacy, money and operational breadth. Dependencies determine sequencing rather than a misleading single “impact score.”

Smallest coherent proof for consideration: one personal routine with state, one direct correction, stable Shelf return, a clean shared copy opened by a guest, optional durable claim, and one two-person game invitation/round. This is the smallest set that tests the product's central utility and social promise together. A mocked share button is insufficient. TV/creator economy/voice each retain a separate complete proof chain; they cannot be marked accepted through this slice.

If a smaller release were later chosen, it would require explicit scope reconciliation. Until then, B67 remains all 39. The recommended sequencing is internal learning and dependency order; it is not a silent deferral of outcomes27–39 or any negative-feedback row.

What to remove, merge, defer or reframe

All 39 traceability

All 39 now have an existing row-specific Linear issue verified by readback on 10 September 2026. The research intake remains CREW-591; earlier umbrella issues remain related. An issue link establishes traceability, not assignment or completion. The canonical source snapshot is dated6 September and is not current runtime proof. Row-specific proofs below augment canonical acceptance, never replace it.

Failure tests for the recommended architecture

Strongest argument for this architecture: an object can carry state, action, memory, and social participation together. The user does not need to repeat their intention or reconstruct context each time. A friend receives something immediately useful. Over time, Shelf can show a phone experience shaped by actual life rather than app installation history.

Why that still might fail:

• A general generator may be worse at each daily task than a simple established app. A customized workout that occasionally loses a log is worse than a reliable timer and note. Native craft cannot compensate for distrust in saved state.
• The user may want an answer once, not a permanent app. Automatic persistence can create digital clutter. Save by deliberate choice or clear repeat use, and let infrequent apps remain findable without forcing Shelf prominence.
• Adaptive Shelf can become a dashboard that demands attention. If users hunt for moved apps or feel watched by unexpected summaries, stability and transparency must beat personalization.
• “Creation without effort” can hide substantial correction labor. Measure total effort over a week, including repairing outputs and cleaning data. If keeping three personal apps useful costs more than their baseline workflow, the central promise fails.
• Shared utility is not automatically a social habit. A good workout link may be used once and never create another relationship. Do not count link opens or copies as retained demand, creator success, or economic value.
• A useful app is not automatically a good show. TV could dilute the product with expensive low-quality clips. Finite episodes, creator choice, watch satisfaction, and return use must earn the feature's prominence. Retaining TV in scope does not mean claiming it deserves default homepage attention.
• Creator earnings can invite optimization for fraud and acquisition rather than useful experiences. Funded, bounded rewards reduce exposure but do not prove a sustainable ecosystem. If rewards exceed retained value after real costs and reversals, stop the harmful payout mechanism and redesign it while retaining honest creator earning as the outcome.
• Village residents may be liked as art and still be irrelevant to getting things done. The resident layer should remain an optional route to expertise and understandable authorship, not a mandatory delegation game. If people ignore the team, do not fabricate agent progress to force engagement.
• Privacy friction cannot disappear just because the interface looks simple. Clean copies, public preview, guest scope, and known participants must be correct. One accidental publication of personal workout/itinerary data can invalidate the claimed ease of sharing.

Evidence that would change the recommendation: if an equally polished conversation-first experience achieves lower total effort, better unaided understanding, and equal repeat use for the same tasks, prefer A for more tasks. If personal apps win but TV produces no voluntary repeat viewing, revise TV's show format and entry point rather than pretend watch time exists. If playful social use wins while routines do not, lead acquisition with games but keep utility and all 39 as delivered capabilities with appropriate prominence. Do not preserve a favorite metaphor at the expense of observed value.

Validation and implementation sequence

All numbers here are proposed pass/fail thresholds for formative work, not statistical proof or existing results. Start with 12 people in six real friend pairs, including novices and returning users. Use their own non-sensitive routine and an actual friend invitation. Record assistance, clarification, errors, elapsed time, retries, abandonment, and successful later reuse. Report individual failures as well as medians; a small sample cannot establish broad demand.

1. Comprehension before polish: three distinct concept flows: living routine, shared game, TV-to-usable-app. Present them without explanation. Proposed gate: 10/12 can say what the object is, what the primary action does, and whether data is private, a fresh copy, or shared live. If they still say “What am I looking at?”, revise the object/interaction, not the subtitle.
2. Real first-value slices: connect J1/J2 and J3 to actual state and fresh-browser use. Proposed gate: 10/12 get a useful first result within 60 seconds under stated conditions; at least 5/6 recipients begin without help or signup; all tested ownership/version boundaries hold. Zero silent duplicate charges or cross-account disclosures is a hard correctness gate, not an average target.
3. One-week maintenance test: compare the same task with each person's existing tools. Record cumulative minutes creating, correcting, finding, repairing, and using; distinguish fun exploration from required labor. Proposed signal: at least 8/12 voluntarily return to a saved experience on three separate days and total required management effort is lower than their baseline. If not, investigate object choice and maintenance burden before adding visual richness.
4. Economic proof in an authorized test environment: demonstrate free first win, one paid-work quote/settlement, failure/refund, native restore, one real eligible ad allocation, creator activation/settlement and eligible withdrawal where supported. Commercial choices must be ratified first. Prove cost coverage; do not use demand research as permission to spend or publish.
5. TV and voice proofs: complete J7's generation-to-playback chain and J4's continuous voice/coordination/learning chain. Measure real latency and behavior against the selected controls. Compare TV's voluntary return and satisfaction with an equal-quality simple feed; do not equate autoplay minutes with value.
6. Full regression and ownership lifecycle: traverse all 39 in the ledger on the actual intended device/runtime, including low connectivity, typography/accessibility, keyboard/Back, guest claim, account switches, privacy lifecycle, money reversals and abuse. Independent QA and existing release gates remain required.

These are dependency stages within the same all 39 outcome. A row remains incomplete until its own acceptance is proven. Passing the first slice cannot justify claiming the whole product ready.

Current disposition: product and design review of this strategy precedes any new visual artifact or implementation. The next approved mockup set should show complete journeys and one meaningful recovery per journey, with distinct task grammar; it should not ask for39 repeated feature-screen verdicts. Human study recruitment and runtime experiments described here are proposed validation work, not activity already performed or permission to contact people. No new visual direction, financial contract, provider budget or release scope is ratified by this document.

Sources

All web sources were accessed 10 September 2026. Dates below are publisher dates where explicitly available; “undated help” means no reliable publication date was established. Publisher descriptions establish their documented behavior, not independently measured usability or Crew performance.

Primary Crew records

• crew-feature-feedback.json: original downloaded export,26 timestamped decisions, preserved unchanged. Its SHA-256 is c0a58da8ed9154f6b32025a61f0cdffb5c2d1b2d150ee70fe8b51f16f9c2b503. Notes inform product principles directly; unwritten explanations are never invented.
• Crew Telegram84618: all 39 concept quality reset; negative verdicts do not cancel features. Telegram84623: explicitly requests Grok and Astra.
• features-source.json, review artifact source4400d8c02cce0bf17fb853dce9532442734f06a4: canonical39 titles/outcomes and earlier issue mapping; readiness fields explicitly remain6 September snapshots.
• linear-all 39-owner-readback.json: current row-specific issues CREW-543–577, CREW-542, CREW-578–580; CREW-591 anchors the new research request. Original umbrella relationships remain.
• demo-observation-events.json and four before-*.png images: observed rejected UI states. Screenshots were viewed, not only captured.
• reference-discord-join.png and reference-apple-widgets.png: publisher images with source URLs above. These are reference evidence, not Crew assets or new design mockups.

Evidence still required

This is a product research and planning recommendation. There is no new approved design, authenticated comparative user study, native acceptance, economic settlement proof, TV production proof, or delivered B67. The proposed usability thresholds, cohort, effort budgets, funding model, defaults and validation slices remain hypotheses for review. Keep the all 39 acceptance ledger open until each real outcome is demonstrated.