@somacheck/vibecheck 0.6.9 → 0.6.11

package/recipes/maze-research-reflection.md

@@ -0,0 +1,325 @@
+---
+title: Maze + SomaCheck Research Reflection
+recipe_id: maze-research-reflection-v1
+status: P1 researcher-side read-only reflection; authenticated Maze MCP capability required
+audience: Researchers using Maze with an MCP-capable agent
+updated: 2026-09-05
+required_mcp_servers:
+  - maze
+  - vibecheck
+---
+
+# Maze + SomaCheck Research Reflection
+
+This recipe gives a Maze researcher one private SomaCheck check-in while
+shaping the researcher's own interpretation plan for one named Maze study.
+The researcher stays the only person who reads, decides, or acts. The recipe
+reads only study metadata or aggregate summary and performs no Maze write.
+
+Maze is a hosted read-only MCP surface (`https://connect.maze.co/mcp`,
+OAuth 2.1). Setup happens in the AI host rather than through a toggle in the
+Maze product UI. Maze's current help pages are inconsistent about Maze-plan
+eligibility, so the authenticated MCP capability response is authoritative for
+the connected account. A team reporting `mcpAccess: true` is an eligible live
+connection regardless of its displayed plan label.
+
+The SomaCheck reading is context for the researcher's own interpretation
+plan. It is not truth, diagnosis, authorization, evidence about a Maze
+participant, or a research decision. The researcher remains the authority.
+
+## Capability and access boundary
+
+Maze documents the hosted MCP as read-only and OAuth 2.1 authenticated at
+`https://connect.maze.co/mcp`. The product or integration owner provisions it
+in a supported MCP host and makes an authorized organization connection or
+partner sandbox available to the researcher. Verify the provisioned access by
+calling the runtime account/team-details capability and requiring
+`mcpAccess: true` for the selected team. Do not infer access from a plan name
+or look for a Maze-side MCP toggle. Running this recipe never asks the
+researcher to sign up, upgrade, administer access, or populate Maze data.
+
+This P1 recipe is researcher-side only. Do not use it to:
+
+- ask a Maze participant, respondent, tester, employee, candidate, patient,
+  or student to complete a SomaCheck;
+- retrieve transcripts, session recordings, heatmaps, click maps, mission
+  answers, participant identifiers, contact fields, demographic exports,
+  free-text fields, or any row-level Maze data;
+- use a reading for participant recruitment, targeting, eligibility,
+  payment, ranking, stress detection, truth detection, deception
+  detection, preference quality, survey validity, research validity,
+  employee engagement, performance, mental health state, authenticity,
+  or quality scoring;
+- write a SomaCheck reading, confidence, gesture, confirmation, or hidden
+  score into Maze, a hidden field, a webhook payload, a comment, a tag, a
+  highlight, an insight, an automation, or any analytics record;
+- create, edit, publish, delete, archive, export, share, duplicate, or
+  otherwise mutate any Maze study, block, mission, prototype, folder,
+  report, insight, or theme; or
+- run a live participant workflow.
+
+Participant-facing use stays blocked until a `respondent_private`
+architecture prevents researcher or platform access to individual readings,
+methodology and ethics review is complete, and Sensie gives explicit
+privacy/legal approval. Maze MCP access, plan status, or participant consent
+alone does not satisfy these gates.
+
+## Experience a researcher can run
+
+The researcher holds the phone and selects one existing study supplied by the
+workspace owner. The agent reads only that study's safe metadata (name,
+description, status, mission list, block list, settings) or one aggregate
+summary (mission completion rates, time on task, success-rate aggregate,
+summary counts). It does not open transcripts, response rows, participant
+identifiers, recordings, or free-text fields. The agent offers two defensible
+interpretation framings and one short first-person proposition about the
+researcher's own interpretation plan. After the researcher's typed choice,
+the agent stops. There is no Maze write.
+
+## Starter prompt
+
+```text
+Use Maze and SomaCheck to help me reflect on my own interpretation plan
+for one named Maze study. I am the researcher and I am holding the phone.
+The study is: [STUDY NAME OR ID PROVIDED BY THE WORKSPACE OWNER]. Use only
+the preconfigured official hosted read-only Maze MCP at
+https://connect.maze.co/mcp. Read only that study's safe metadata (name,
+description, status, mission list, block list, settings) or one aggregate
+summary (mission completion rates, time on task, success-rate aggregates,
+summary counts). Do not retrieve
+transcripts, session recordings, heatmaps, click maps, mission answers,
+participant identifiers, contact fields, demographic exports, free-text
+fields, themes, highlights, or any row-level Maze data. Propose two
+defensible interpretation framings. Then offer one short first-person
+proposition about my own interpretation plan and wait for my acceptance
+before any proactive SomaCheck ask. Treat Aligned or Unaligned plus
+confidence as context, not truth, diagnosis, authorization, or evidence
+about a Maze participant. Ask what I choose in words. Keep the
+proposition, reading, confidence, and my confirmation out of Maze. Do
+not create, edit, publish, delete, archive, export, share, tag, comment,
+or write to Maze, a hidden field, a webhook, or any analytics record.
+Continue when the authenticated selected team reports `mcpAccess: true`.
+Otherwise label the Maze half untested, return the copy-ready plan, tell the
+integration owner what capability is missing, and stop. Do not ask me to sign
+up, upgrade, administer access, or populate Maze data.
+```
+
+## Prerequisites and account access
+
+1. The researcher can complete a normal SomaCheck request through the connected
+   `vibecheck` MCP server (`request_vibecheck` and
+   `get_vibecheck_result`).
+2. A product or integration owner has provisioned an authorized organization
+   connection or partner sandbox. Its authenticated Maze MCP reports
+   `mcpAccess: true` for the selected team. Do not reject an authenticated team
+   because its returned plan label is `Personal`, and do not claim access
+   merely from documentation or UI.
+3. The provisioned MCP client is connected to exactly
+   `https://connect.maze.co/mcp` and authenticated through the OAuth 2.1 flow
+   Maze publishes. Do not substitute a different host, path, or non-Maze
+   endpoint.
+4. The workspace owner supplies one named existing Maze study (by name or ID)
+   that does not require row-level participant data, transcripts, recordings,
+   contact fields, or free-text fields for the reflection task. The researcher
+   is not responsible for creating or populating it.
+5. No credential, OAuth token, study ID containing PII, or participant
+   identifier appears in chat, logs, prompts, or the SomaCheck
+   proposition.
+
+## Maze tool policy
+
+Maze publishes a hosted, OAuth 2.1, read-only MCP. The recipe uses the
+smallest tools that answer the researcher's request. Treat the live tool
+list as runtime-discovered; do not assume undocumented tool names.
+
+| Purpose | Allowed surface | Rule |
+| --- | --- | --- |
+| Resolve the named study | runtime-discovered study lookup or list | Read only the named study; never list every workspace study or participant row |
+| Read study metadata | runtime-discovered study detail / mission list / block list / settings | Read only the named study's metadata; treat status, description, mission list, and block list as metadata |
+| Read one aggregate summary | runtime-discovered aggregate or summary tool, if exposed | One aggregate read (counts, completion rates, time-on-task aggregates, success-rate aggregates); never row-level data |
+| Create, edit, publish, delete, share, archive, export, duplicate, tag, comment | any mutation tool | Prohibited in this recipe |
+| Transcripts, recordings, heatmaps, click maps, mission answers, participant identifiers, contact fields, demographics, free-text fields, themes, highlights, insights | any row-level or participant-bearing tool | Prohibited in this recipe |
+| Webhooks, automations, exports, analytics writes | any write side-effect tool | Prohibited in this recipe |
+| Private reflection | `request_vibecheck`, optional `get_vibecheck_result` | One decision, one request, one stable pending handle |
+
+Do not broaden a connection to a root or all-tools endpoint to make this
+recipe work. If the runtime does not expose a study-metadata or aggregate
+read, label the Maze half untested and stop.
+
+## Exact cross-MCP workflow
+
+1. **Confirm the subject and scope.** State that the researcher is the phone
+   holder and the subject of the proposition. Name the one existing Maze study
+   supplied by the workspace owner (by name or ID).
+2. **Verify Maze access honestly.** Call the authenticated account/team-details
+   capability. Continue only when the selected team reports `mcpAccess: true`.
+   Treat the runtime capability as authoritative rather than inferring access
+   from the plan label or searching for a Maze-side settings toggle.
+3. **Read only metadata or one aggregate summary.** Call the smallest
+   runtime tool that returns the named study's metadata (name,
+   description, status, mission list, block list, settings) or one
+   aggregate summary (counts, completion-rate aggregates, time-on-task
+   aggregates, success-rate aggregates). Do not call any tool that
+   returns transcripts, recordings, heatmaps, click maps, mission
+   answers, participant identifiers, contact fields, demographic
+   exports, free-text fields, themes, highlights, or insights.
+4. **Separate evidence from interpretation.** Label what the Maze study
+   literally contains, what the agent infers, and what the researcher's
+   own judgment must still decide.
+5. **Propose two framings.** Offer two defensible interpretation
+   framings the researcher could choose from, with the tradeoff for each.
+6. **Choose one first-person proposition.** It must be short,
+   first-person, and about the researcher's own interpretation plan. Do not include
+   Maze IDs containing PII, participant data, transcript text, contact
+   fields, free text, themes, or highlights.
+7. **Establish one-ask consent.** If the researcher explicitly requested a
+   SomaCheck check-in in the current message, use
+   `consent_basis: "user_requested_vibecheck"`. Otherwise show the
+   exact proposition, wait for acceptance, and use
+   `consent_basis: "user_approved_statement"`.
+8. **Request once.** Call `request_vibecheck` with the approved statement
+   and a fresh UUID `idempotency_key`. Reuse it only to retry the
+   identical request after an ambiguous create failure.
+9. **Handle the real lifecycle.** A terminal response from
+   `request_vibecheck` uses `state: "completed"`; a later read uses
+   `status: "answered"`. If the initial response is `pending`, retain the
+   returned `live:<uuid>` handle and call `get_vibecheck_result` with
+   it once later. If it is still `pending`, `expired`, `cancelled`, or
+   errors, continue without a result. Never issue a replacement ask.
+10. **Return authority.** Separate observation (a valid gesture was
+    captured), interpretation (`aligned` or `unaligned` plus model
+    confidence), confirmation (what the researcher says), and choice (what the researcher
+    decides). `unaligned` may indicate possible inner conflict relative
+    to the proposition; it does not name a cause, choose an interpretation,
+    or justify a research claim.
+11. **Ask for words.** Ask the researcher which framing they choose, whether they
+    want a third option, or whether they want to stop. Follow their typed
+    choice.
+12. **Keep the signal out of Maze.** Do not call any Maze write, mutation,
+    export, webhook, comment, tag, highlight, insight, analytics, or
+    hidden-field tool. Do not store the proposition, reading,
+    confidence, confirmation, or gesture metadata in Maze.
+13. **End the test.** Report the exact Maze tool names used and the
+    exact metadata or aggregate fields returned, or report the
+    copy-ready plan when the Maze half is untested. Do not create,
+    edit, publish, delete, archive, export, share, duplicate, or
+    otherwise mutate any Maze object.
+
+## Proposition examples
+
+Allowed:
+
+- "I can interpret this Maze study without reading individual
+  transcripts."
+- "I have a clear interpretation plan for the aggregate success-rate
+  summary."
+- "I am ready to use only metadata and one aggregate summary for this
+  study."
+- "I want to keep the participant data out of my interpretation
+  decision."
+- "I can explain what this Maze study is showing without overclaiming."
+
+Not allowed:
+
+- "This Maze participant is telling the truth."
+- "These Maze testers are engaged."
+- "This mission result is high quality."
+- "These respondents should be paid or rejected."
+- "This Maze study proves my hypothesis."
+
+## Visible success condition
+
+The test passes when:
+
+- the researcher selects one existing Maze study supplied by a workspace owner
+  in a team whose authenticated MCP response reports `mcpAccess: true`;
+- the agent reads only that study's metadata or one aggregate summary
+  through the hosted read-only Maze MCP and reports the exact tool
+  names used;
+- the agent never calls a row-level, transcript, recording, heatmap,
+  click map, mission-answer, participant-identifier, contact, free-text,
+  theme, highlight, insight, automation, or write tool;
+- the researcher receives at most one optional SomaCheck check-in on their phone
+  on an exact first-person proposition about their own interpretation plan;
+- the agent presents the result as context, asks the researcher to state their
+  choice in words, and follows the typed choice;
+- the agent makes no Maze write, mutation, export, share, tag,
+  comment, or analytics call; and
+- no Maze participant, respondent, or employee data enters the
+  cross-MCP flow.
+
+## Failure and degraded paths
+
+- **Authenticated team lacks MCP access:** Label the Maze half untested. Return
+  the copy-ready interpretation plan and stop. Never substitute a plan label,
+  documentation walkthrough, static/local fixture, or non-Maze endpoint for an
+  authenticated organization or partner-sandbox pass.
+- **OAuth 2.1 failure or absent scope:** Report the missing capability to the
+  product or integration owner; never request a token in chat or ask the
+  researcher to sign up, upgrade, or administer access. Return the copy-ready
+  plan and stop.
+- **Runtime exposes only row-level or participant-bearing tools:** Do
+  not call them. Label the Maze half untested and stop. Do not broaden
+  the connection to make this recipe work.
+- **MCP returns row-level data, participant identifiers, transcripts,
+  recordings, free-text fields, themes, highlights, or insights:** Stop
+  immediately. Discard the row-level content from the agent context.
+  Report the exact fields received and ask the product or integration owner to
+  revoke or limit the scope. Do not use the row-level content in any
+  proposition, framing, or interpretation.
+- **SomaCheck unresolved:** Use the same `live:<uuid>` handle once
+  later, then proceed without a reading if still unresolved.
+- **Unreadable capture:** Offer a retry only if the researcher wants it;
+  unreadable is not a third interpretation.
+- **Researcher disagrees with the reading:** Follow the researcher's typed choice
+  without reconciliation or repetition.
+
+## Privacy boundary
+
+- Raw phone motion never reaches Maze or the agent.
+- Maze receives no proposition, reading, confidence, confirmation,
+  gesture metadata, or row-level participant data through this recipe.
+- SomaCheck receives no Maze study ID containing PII, mission text,
+  participant data, transcript, recording, contact field, free-text
+  field, theme, highlight, or insight.
+- No Maze participant, respondent, or employee data is read into the
+  agent conversation, prompt, proposition, framing, or memory.
+- The Maze workspace remains unchanged. No mutation, write, export,
+  share, tag, comment, automation, webhook, or analytics call occurs.
+
+## Test checklist
+
+- [ ] The researcher is the phone holder and the subject of the proposition.
+- [ ] The authenticated Maze team reports `mcpAccess: true`; its plan label is
+      recorded only as context and is not used to override the capability.
+- [ ] The MCP client is connected to exactly
+      `https://connect.maze.co/mcp` through Maze's OAuth 2.1 flow; no
+      other host, path, or non-Maze endpoint is used.
+- [ ] No Maze credential or OAuth token appears in chat, logs, or the
+      SomaCheck proposition.
+- [ ] The agent reads only metadata or one aggregate summary of the
+      named study and reports the exact runtime tool names used.
+- [ ] The agent does not call any transcript, recording, heatmap,
+      click map, mission-answer, participant-identifier, contact,
+      free-text, theme, highlight, insight, automation, or write tool.
+- [ ] The proposition is first-person and contains no Maze IDs
+      containing PII, participant data, transcripts, contact fields,
+      free-text fields, themes, or highlights.
+- [ ] At most one SomaCheck request is created for the choice.
+- [ ] Observation, interpretation, confirmation, and choice remain
+      separate.
+- [ ] The researcher states a choice in words and the agent follows the typed
+      choice.
+- [ ] The agent makes no Maze mutation, write, export, share, tag,
+      comment, or analytics call.
+- [ ] No Maze participant, respondent, or employee data enters the
+      cross-MCP flow.
+
+## Sources
+
+- [Maze MCP support article](https://help.maze.co/articles/3603930517-maze-mcp)
+- [Set up Maze MCP](https://help.maze.co/articles/8675970764-set-up-maze-mcp)
+- [Maze product help](https://help.maze.co/)
+- [SomaCheck MCP setup and tool behavior](../README.md)
+- [SomaCheck immediate-request contract](../LIVE-ASK-CONTRACT.md)
+- [MCP Customer-Testable Experience Catalog](../../../docs/agent-adoption/customer-experience-catalog.md)

package/recipes/prolific-research-reflection.md

@@ -0,0 +1,215 @@
+---
+title: Prolific + SomaCheck Research Reflection
+recipe_id: prolific-research-reflection-v1
+status: P1 researcher-side only
+audience: Researchers using Prolific with an MCP-capable agent
+updated: 2026-09-03
+required_mcp_servers:
+  - prolific
+  - vibecheck
+---
+
+# Prolific + SomaCheck Research Reflection
+
+Use this recipe when a researcher wants a private, consented signal about their
+own response to a Prolific study or recruitment plan. It supports reflection on
+study framing, audience rationale, reward and time assumptions, and readiness
+to revise a draft. It does not evaluate participants or authorize a study
+launch.
+
+The reading is context for the researcher. It is not truth, a diagnosis,
+authorization, evidence about a participant, or a research decision. The
+researcher remains the authority.
+
+## Launch boundary
+
+This P1 recipe is **researcher-side only**. The person holding the phone and
+receiving the SomaCheck result must be the researcher interacting with the
+agent.
+
+Do not use this recipe to:
+
+- ask a participant or employee to complete a SomaCheck;
+- export a participant reading, confidence, or confirmation to Prolific or a
+  connected survey platform;
+- use a SomaCheck result in recruitment, screening, eligibility, allow/block
+  lists, reward, payment, bonus, rejection, quality, authenticity, submission,
+  or performance decisions;
+- score or rank a participant, response, cohort, study, or researcher;
+- automatically create, publish, pause, or transition a study; or
+- run a live respondent workflow.
+
+Participant-facing use stays blocked until a `respondent_private` architecture
+technically prevents researcher or platform access to individual readings, a
+methodology and ethics review is complete, and Mike gives explicit approval.
+Prolific access or participant consent alone does not satisfy these gates.
+
+## Prerequisites
+
+1. The researcher has linked the `vibecheck` MCP server to their own SomaCheck
+   account and can see `request_vibecheck` and `get_vibecheck_result`.
+2. The researcher has installed Prolific's official open-source MCP server from
+   `prolific-oss/prolific-mcp` and can see its study-planning tools. Prefer a
+   reviewed, pinned package version rather than an unbounded install.
+3. `PROLIFIC_TOKEN` is stored only in the MCP client's environment or secret
+   configuration. Never paste, echo, log, or place it in a proposition. Prolific
+   states that researcher tokens do not expire and carry the researcher's
+   permissions, so rotate a token if exposure is suspected.
+4. The researcher names one workspace, project, or draft study in scope. The
+   recipe does not retrieve submissions, participant messages, participant
+   identifiers, response exports, or demographic exports.
+
+The official server currently exposes study-design and launch tools but no
+participant-response tools. Do not bypass that boundary with direct REST calls,
+a browser, another connector, or pasted exports.
+
+## Prolific tool policy
+
+Use read-only planning tools for this recipe.
+
+| Purpose | Prolific MCP tools | Rule |
+| --- | --- | --- |
+| Resolve researcher-owned scope | `list_workspaces`, `list_projects`, `list_studies`, `view_study` | Read only the workspace, project, or study the researcher names. |
+| Inspect recruitment options | `get_filters`, `get_filter_sets`, `get_eligibility_count` | Planning context only. Never combine a SomaCheck reading with participant eligibility, filtering, or cohort scoring. |
+| Create or change platform state | `create_filter_set`, `create_study` | Not part of this recipe; require a separate, explicit, reviewed request. |
+| Spend or launch | `publish_study` | Never call in this recipe. Publishing can spend real money and make a study immediately available. |
+
+## Exact cross-MCP workflow
+
+Follow these steps in order. The Prolific and SomaCheck calls must not form an
+automatic decision gate.
+
+1. **Confirm the subject and scope.** State that the researcher is reflecting
+   on their own recruitment or study-design choice. Name the one Prolific
+   workspace, project, or draft study to inspect.
+2. **Retrieve the minimum planning context.** If the researcher supplied an
+   exact study ID, call `view_study` directly. Otherwise use `list_workspaces`
+   only if the workspace is unresolved, `list_projects` only if the project is
+   unresolved, and `list_studies` only to resolve the named study before calling
+   `view_study`. Do not retrieve or request participant-level data.
+3. **Inspect feasibility without scoring people.** If needed, use `get_filters`,
+   `get_filter_sets`, or `get_eligibility_count` to describe available filters
+   and aggregate pool feasibility. Keep this separate from the SomaCheck result.
+   Do not recommend a filter merely because a proposition returns Aligned or
+   Unaligned.
+4. **Separate evidence from interpretation.** Summarize the draft's literal
+   study framing, audience, estimated time, reward, and status; label agent
+   inferences; and present two or more reasonable options. Flag missing ethics,
+   budget, method, or institutional approvals without inventing them.
+5. **Choose one first-person proposition.** It must express the researcher's
+   present experience or choice, not a claim about a participant or cohort. Do
+   not include study IDs, participant attributes, Prolific content, or secrets.
+6. **Establish one-ask consent.** If the researcher explicitly requested a
+   SomaCheck vibecheck in the current message, call `request_vibecheck` with
+   `consent_basis: "user_requested_vibecheck"`. Otherwise show the exact
+   proposition, wait for acceptance, and use
+   `consent_basis: "user_approved_statement"`.
+7. **Request once.** Call `request_vibecheck` with the approved statement and a
+   fresh UUID as `idempotency_key`. Reuse that UUID only to retry the same
+   statement after an ambiguous create failure. Never repeat an ask to obtain a
+   preferred result.
+8. **Handle the exact result.** `request_vibecheck` reports a terminal answer as
+   `state: "completed"`; a later `get_vibecheck_result` read reports the same
+   lifecycle point as `status: "answered"`. Treat either as the terminal result
+   and keep four layers distinct: observation (a valid gesture was captured),
+   interpretation (`aligned` or `unaligned` plus model confidence), confirmation
+   (what the researcher says), and choice (what the researcher decides).
+   `unaligned` means possible inner conflict relative to the proposition; it
+   does not identify a cause. If the initial response is `pending`, retain its
+   `live:<uuid>` handle and call `get_vibecheck_result` with that exact handle
+   once later. Do not create a replacement request. If that read is still
+   `pending`, is `expired` or `cancelled`, or errors, continue without a result;
+   do not infer one or start another request.
+9. **Return authority and stop before mutation.** Offer revise, investigate,
+   proceed to separate review, pause, or leave unchanged. Do not call
+   `create_filter_set`, `create_study`, or `publish_study`. If the researcher
+   chooses a change, produce a reviewable draft outside Prolific; platform
+   mutation is a new action requiring explicit instruction. A typed researcher
+   choice overrides the signal.
+10. **Keep the signal private.** Do not write the verdict, confidence, gesture,
+    confirmation, or inferred meaning to Prolific or another research platform.
+
+## Proposition examples
+
+Good propositions are short, first-person, and about the researcher:
+
+- “I can explain why this recruitment plan fits the research question.”
+- “I am comfortable defending the current time and reward assumptions.”
+- “I want to narrow this audience for methodological reasons.”
+- “I am ready to send this draft for ethics and budget review.”
+- “I want to investigate an alternative sampling plan before I proceed.”
+
+Never send propositions such as:
+
+- “This participant should be eligible.”
+- “This cohort will produce high-quality data.”
+- “This submission deserves payment.”
+- “These respondents are authentic.”
+- “This study should publish automatically.”
+
+## Trigger and anti-trigger rules
+
+Trigger this recipe when the researcher explicitly asks to reflect with
+SomaCheck. The agent may also **offer** one check when the researcher is choosing
+between defensible recruitment plans, cannot articulate what feels off about a
+draft, or wants to examine their own readiness before a formal review. An offer
+must include the exact proposition and must not call the tool until accepted.
+
+Do not trigger when:
+
+- the task is routine Prolific retrieval or administration;
+- the proposed subject is a participant, employee, cohort, or respondent;
+- the result would affect eligibility, filtering, payment, bonus, rejection,
+  submission quality, authenticity, or performance;
+- the researcher has already made a clear typed choice;
+- the agent is being asked to publish, gate, or automate a launch; or
+- a vibecheck was already used for the same decision.
+
+## Consent, privacy, and failure behavior
+
+Linking the MCP servers is setup, not blanket consent. A proactive check always
+requires acceptance of its exact wording. Never send Prolific records,
+participant data, identifiers, secrets, or diagnostic claims to SomaCheck. Raw
+phone motion never goes to the agent or Prolific. Do not persist a researcher's
+reading or confidence in Prolific.
+
+If Prolific authorization fails, ask the researcher to repair or rotate the
+connection; never request that they paste a token. If the requested scope would
+require participant-level data, stop. If SomaCheck reports an unreadable
+capture, request a retry only if the researcher wants one; unreadable is not a
+third interpretation. If the request expires, is cancelled, or errors, continue
+without a reading. Never infer a result. If the result and the researcher's
+words differ, follow the researcher's words and preserve the difference rather
+than reconciling it into a score.
+
+## Verification checklist
+
+- [ ] The `prolific` server is the reviewed official implementation and the
+      `vibecheck` server exposes the expected tools.
+- [ ] No Prolific or SomaCheck credential appears in chat, config examples,
+      propositions, or logs.
+- [ ] The agent names one researcher-owned workspace, project, or study and uses
+      only minimum read-only planning calls.
+- [ ] No submission, participant message, identifier, response, or demographic
+      export is retrieved or pasted into the flow.
+- [ ] The proposition is first-person and contains no Prolific or participant
+      content.
+- [ ] A proactive ask waits for acceptance; an explicit user request does not
+      add a redundant consent prompt.
+- [ ] One decision creates at most one `request_vibecheck` request and preserves
+      its stable pending handle.
+- [ ] The response distinguishes observation, interpretation, confirmation, and
+      choice.
+- [ ] No result affects eligibility, payment, quality, filtering, scoring, or
+      launch decisions.
+- [ ] `create_filter_set`, `create_study`, and `publish_study` are not called.
+- [ ] Participant-facing behavior remains blocked by the `respondent_private`,
+      methodology/ethics, and Mike-approval gates.
+
+## Sources
+
+- [Prolific MCP server](https://github.com/prolific-oss/prolific-mcp)
+- [Prolific API fundamentals](https://docs.prolific.com/documentation/get-started/api-fundamentals)
+- [Prolific studies API](https://docs.prolific.com/api-reference/studies)
+- [SomaCheck MCP setup and tool behavior](../README.md)
+- [SomaCheck immediate-request contract](../LIVE-ASK-CONTRACT.md)