Reference Apps

Use reference apps to prove the stack handles real product pressure. One smoke app proves setup. One realistic app proves the hard parts.

Reference App Policy

App	Required?	Purpose
Tiny smoke app	Yes	Proves create, dev, one test, and one build path
Realistic app	Yes for serious stack picks	Proves persistence, navigation, platform APIs, packaging, and release checks
Production clone	Optional	Useful only when licensing, setup, and maintenance cost are understood

Tiny Smoke App

Field	Answer
Name	`[stack]-smoke`
Goal	`[one sentence]`
Feature	`[one route/screen/command]`
Data	`[none
Required commands	`create`, `dev`, `test`, `build`
Evidence path	`[screenshots, logs, artifact path]`

Smoke Acceptance Criteria

Fresh scaffold works from an empty directory.
App runs on the target platform.
One test fails if the main screen, route, or command is broken.
Production build or package command succeeds.
No unreviewed third-party starter scripts run without approval.

Realistic App

Field	Answer
Name	`[stack]-reference`
Goal	`[real user task]`
Persistence	`[local db, file, cloud, sync, backup]`
Navigation	`[routes, screens, deep links]`
Platform APIs	`[camera, notifications, file system, background work, network, clipboard]`
Test shape	`[unit, integration, E2E, device, browser]`
Packaging	`[apk, app bundle, installer, container, static output, store artifact]`
Release check	`[manual, CI, store upload, deployment, signed artifact]`

Realistic Acceptance Criteria

The app covers at least one persistence path.
Navigation or screen flow exercises more than one user state.
A platform-specific API is used only if the stack claims platform strength.
Tests cover the critical path, not only compile success.
Build artifacts can be named, inspected, and reproduced.
Release blockers are explicit, even if not solved yet.

Scenario Harness

For high-use stacks, add lightweight eval fixtures after the pack is used in a real app build.

scenarios:
  - name: smoke-app-from-scratch
    prompt: |
      Create the tiny smoke app described in this stack pack.
    expected_patterns:
      - "[entry point or command]"
    forbidden_patterns:
      - "[known bad import, deprecated command, or unsafe workaround]"
    required_evidence:
      - "create command output"
      - "test command output"
      - "build artifact path"

Tip: Start with two or three realistic eval prompts. Expand only after failures reveal useful patterns.