product-experience-foundation

Product Experience Baseline

Consolidate the project's reusable product decisions into versioned documents; keep the scaffolding technically generic, and do not write a project's business semantics, navigation, or page content into frontend/、admin/ and other generic modules.

Scope

• Applies to the first version of requirements for a specific product, or to experience patterns that have been confirmed by the product as needing repeated use.
• The C-end and Admin must each maintain their own experience rules; only branding, domain terminology, and cross-end business states may be placed in the shared layer.
• Do not pre-build a design system without business justification, and do not automatically create global components because of a single feature.
• If a product baseline already exists, update only the sections explicitly affected by the current requirements.

Establish or Update the Baseline

1. Confirm the product scope. Read the first version of the PRD, existing pages, product roles, domain terminology, and related frontend projects; when there are multiple products and the target is unclear, ask the user to specify the product directory.
2. In docs/product/<project-name>/ , create or locate the product assets. When creating, first read references/foundation-template.md。
3. Record verifiable facts and explicit decisions; mark reasonable defaults as [INFERRED], and list items that are not yet determined as [UNKNOWN]。
4. Separately establish the c-end/ and admin/ baselines, and create documents only for the ends actually within the scope of this project.
5. Consolidate the first batch of core flows into page patterns, rather than pre-abstracting components for pages that may appear in the future.
6. For each candidate reusable pattern, record the location of its first appearance, evidence of reuse, and confirmation status. Upgrade it to a product-level pattern only when the user has explicitly confirmed it, or when the pattern has been adopted by two confirmed features.

Recommended Structure

docs/product/<project-name>/
├── product-context.md
├── shared/domain-language.md
├── c-end/
│   ├── ux-foundations.md
│   └── patterns.md
├── admin/
│   ├── ux-foundations.md
│   └── patterns.md
└── component-promotion-log.md

Feature requirements still go in docs/prd/<feature-name>/. Feature documents should link to the product baseline they depend on, and describe only the changes in this iteration, without repeating global navigation, basic controls, and general state rules.

Authority and Evolution

Handle conflicts in the following order:

1. Repository architecture, security rules, and technical conventions.
2. The confirmed product experience baseline.
3. The confirmed PRD and feature design specifications for this iteration.
4. The visible existing patterns of the current project's pages.
5. External websites, screenshots, and general UX recommendations.

If the feature design needs to intentionally deviate from the baseline, record the reason for the deviation, the affected ends, and whether it should be written back to the baseline; do not silently replace branding, navigation, domain terminology, or core interaction patterns.

Delivery and Maintenance

When delivering, explain:

• The baseline files created or updated, and the product ends they cover.
• The shared patterns confirmed in the first version and the patterns that remain local to features.
• The candidate patterns added, promoted, or rejected, and the reasons.
• The roles, information architecture, or domain rules still awaiting product confirmation.

When subsequently using pm-frontend-prototype、web-design-extractor or design-spec-prototyper , first read the baseline for the corresponding end; if the baseline is missing, do not pretend that it already exists.