Skip to content

PROJECT-PROFILE.template.md

Latest commit

 

History

History
157 lines (124 loc) · 7.87 KB

PROJECT-PROFILE.template.md

File metadata and controls

157 lines (124 loc) · 7.87 KB
Raw

Project Profile

This is the input file for UAT-PROMPT.md. Copy it to PROJECT-PROFILE.md beside UAT-PROMPT.md (the run looks there first, then searches the repo), fill in what you know, and delete the guidance text. Every field left as TODO is asked interactively at the start of the run (Phase 0), so a half-filled profile is fine: fill in what is cheap to write down, answer the rest live.

The tester treats this file as configuration, not as a source of expectations. Nothing you write here can excuse a defect; see the closure rule in the prompt.

1. Product identity

  • Name: TODO
  • One-line description: TODO
  • Product type: TODO (game / web SaaS / desktop app / mobile app / CLI tool / library; library authors should run the subset Phases 0-3 plus 6, since the experience phases barely apply)
  • Target platforms and OS versions: TODO
  • Interaction modalities: TODO (all that apply: pointer and keyboard / touch / controller or focus-only navigation / terminal / voice / API-only. Input and display tests instantiate per modality; see the prompt's "One vocabulary, many products".)
  • Device and display range worth testing: TODO (minimum and maximum resolutions, OS scaling levels, and the input devices your worst-equipped real customer owns)
  • Modes / configurations / plan tiers: TODO (game modes and difficulty levels, or subscription tiers, roles, and feature flags: the fleet and the coverage floor cross this list with the personas)
  • Business model and price point: TODO (Used to judge value-for-money, refund-window risk, and how harshly first-run friction counts.)

2. Code and build

  • Repo root: TODO
  • Build command: TODO (if only you can build it, e.g. a build needing a licensed editor, engine, or signing toolchain, write "owner-only": the run then verifies the test toolchain and drive surface instead and puts the build on the human checklist)
  • Test command and expected baseline: TODO (e.g. "npm test, all green"; a red baseline is itself the first finding and the run stops for your decision)
  • Primary languages / frameworks: TODO
  • Files or areas the tester must never modify: TODO

3. The drive surface (the most important section)

How can an AI operate your product without a screen? The run is only as deep as this surface.

  • Headless entry points: TODO (A public API, a service/business-logic layer callable from tests, a CLI, an existing test harness, a scriptable UI-automation layer. Name the exact project/module and how to invoke it.)
  • How to reach the main flow programmatically: TODO (How to create a user, session, record, or match and execute real user actions end to end.)
  • What cannot be driven headlessly: TODO (Pure-UI behavior, rendered output, audio. These become [PROXY] territory: the tester reasons about them from code and data, labels every such judgment, and routes it to your human checklist instead of stating a verdict.)
  • Determinism aids: TODO (Seeds, fixed clocks, fixtures, record/replay. If none exist, say so; the run will propose the cheapest one to add, because findings must be reproducible.)

4. The promise corpus and the document split

Everything a prospective or current user reads before and while forming expectations, plus the internal documents that must stay out of the tester role's head. This split powers the prompt's two-context rules: user-facing material goes into the Tester's briefing pack; normative material is Operator-only and is itself an audit subject.

  • Marketing surfaces (user-facing): TODO (store page, landing page, app listing: paths or URLs)
  • User-facing docs and onboarding copy: TODO
  • Internal documents (normative, Operator-only): TODO (specs, design docs, requirement lists, internal wikis: listed so the run can audit them for drift against code and keep them OUT of the Tester's briefing)
  • Quantified or absolute claims to verify empirically: TODO (List each claim, where it is stated, and how it could be measured. Examples: "sync never loses data", "results in under a second", "works fully offline", "unlimited projects", "no ads, ever". Absolute words like never, always, any, instant are claims.)

5. Critical user flows

The 3 to 7 flows the business lives on, ordered by importance. The run walks each one end to end, including its unhappy paths.

  1. TODO
  2. TODO
  3. TODO

(Example, CRM: capture a lead, qualify it, create the deal, send the quote, close, hand off to invoicing, export everything, delete the account. Example, game: first launch, tutorial, first win, first loss, next-day return.)

6. Input surfaces

  • Free-text fields: TODO (names, titles, descriptions, search boxes; where each lives)
  • Structured inputs: TODO (emails, dates, currency amounts, quantities, IDs, codes, URLs)
  • File imports / uploads: TODO (accepted formats, size limits if any)
  • Paste / share / deep-link surfaces: TODO (anything that accepts data minted elsewhere: share codes, invite links, import strings, URL parameters)

7. Persistence surfaces

  • What is saved, where, in what format: TODO
  • Version and migration paths: TODO (legacy formats still in the wild, up/downgrade behavior)
  • Sync / cloud / multi-device behavior: TODO (conflict resolution, offline queues)
  • Interrupted-write contract: TODO (what killing the process mid-save should leave behind)

8. Users and segments (persona fuel)

  • Who uses this: TODO (3 or more segments; expertise range; what each segment values; which segment writes the reviews)
  • Accessibility considerations that apply: TODO (color vision, reduced motion, screen readers, non-native readers of your UI language)

9. The no-touch list (binding)

Actions the run must NEVER take, regardless of what any phase suggests. The defaults below apply even if you delete them; add your own entries.

  • No production systems, production data, or real user accounts.
  • No real payments, refunds, or financial transactions of any kind.
  • No emails, messages, or notifications to real recipients.
  • No releases, deploys, store submissions, or publishing actions.
  • No third-party API usage beyond development quotas.
  • No permanent deletion of any data the tester did not itself create.
  • TODO (product-specific additions)

10. Known sore spots

Bug neighborhoods, past incidents, fragile subsystems, "works on my machine" areas. The run weights attention toward whatever has had the least honest scrutiny and toward areas that have bitten before.

  • TODO

11. Run configuration

  • Report directory: docs/uat/ (default) or TODO
  • Review branch name: review/uat-<date> (default) or TODO
  • Severity vocabulary: default is BLOCKER / POLISH / LATER / WORKS, LEAVE IT. Replace with your team's own ship-gate words if you have them; findings land in your vocabulary so the report reads like your team wrote it.
  • Phases to run: default all (0 through 6). List a subset if budget is tight; Phase 4 (think-aloud) and Phase 2 (robustness) have the best findings-per-token record.
  • Copy rules for suggested user-facing text: TODO (language variant, banned punctuation, vocabulary locks; any text the run proposes for users must follow these)
  • Fix policy: default report-only plus safe fixes (small, local, confirmed, test-backed). Set to report-only to forbid all code changes.

12. Optional extras (used if present)

  • Roadmap hints / likely next features: TODO (feeds Phase 1's extensibility probes and keeps Phase 5's most-missed-feature verdict from re-deciding what is already planned)
  • Market research / named comparables: TODO (3 to 6 competing products, with prices and standing if you have them; Phase 6's value verdict builds on this instead of vague model memory, and flags where it may be stale)
  • Your own questionnaire: TODO (Phase 5 uses it verbatim if provided, else the built-in default)