Идеи
Product Digital Twin/PROMPT.md

Act as a Senior Software Architect and Product Strategist specialized in Enterprise Headless CMS solutions, TypeScript ecosystems, and Clean Architecture (SOLID, GRASP, Domain-Driven Design).

1. CONTEXT & PROBLEM STATEMENT

I am developing and managing a highly dynamic web product built on Next.js (App Router) and Payload CMS. The core of the project is a "marketing page builder/constructor" where marketing teams can autonomously create, reorder, and link flexible sections and content blocks via the Payload admin panel.

The Reality of the Project:

  1. Business Chaos: Internal clients/stakeholders often don't know what they want until they see it. Requirements are gathered "by crumbs," and design flaws are fixed on the fly by developers during the adaptation process.
  2. Cascading Side Effects: Because the CMS acts as a fully dynamic block-constructor with complex conditional logic, changing a single section schema, field relation, or admin setting often silently breaks rendering logic, visual constraints, or business rules in Next.js components.
  3. Engineering Integrity: As a developer, I heavily care about code cleanliness, SOLID/GRASP principles, strict TypeScript typing, and automated testing. However, the business demands rapid marketing flexibility.

2. THE VISION: PRODUCT DIGITAL TWIN

I want to design a static-analysis tool/framework — a Product Digital Twin (Product Knowledge Graph) — that operates purely during the development stage (not in runtime) to track product consistency and evaluate the impact of changes.

The Golden Source of Truth (The Anchor): The system must anchor itself around Initial Specs, Seed Files, and Real Code configs. We assume that the initial designs/requirements are materialized into a "Seed JSON" (mock data structure) that perfectly maps to the expected initial layout.

What the Digital Twin Must Track (Core Entities & Nodes):

  • Business Layer: Text-based business requirements, functional rules, and SEO demands (e.g., "SEO contractor requested H1 to H2 swap on Section X").
  • CMS Schema Layer: Payload CMS Collection and Block definitions, fields, and conditional admin logic.
  • Engineering Layer: Next.js UI components, domain interfaces, and custom hooks.
  • Validation Layer: End-to-End (Playwright) and Unit (Vitest/Jest) tests.

3. WHAT THIS SYSTEM IS NOT (Exclusion of Over-engineering)

To prevent tool fatigue, false positives, and over-engineering, we are STRICTLY EXCLUDING the following features:

  • NO automatic Figma parsing or Figma API sync. (Design shifting is too volatile for strict graphs).
  • NO automatic screenshot/pixel-perfect visual comparison via AI. (Layout fluidity and responsive design generate too much noise).
  • Only text/code/schema contracts and business logic mapping are tracked.

4. CORE OBJECTIVES & USE CASES

I need the system to parse our workspace and automatically surface the following anomalies:

  1. Impact Analysis (What will break?): If a SEO contractor or marketer modifies a text requirement or a Payload CMS field, the system should trace the graph edges and show exactly which Next.js components, TypeScript types, and Playwright tests are impacted.
  2. Dead / Blind Code Detection: Spotting code components or Payload schemas that have no links to actual business requirements, or business goals that are completely missing implementation.
  3. Architectural Contamination: Identifying when a dynamic marketing block violates SOLID/GRASP (e.g., a simple layout section suddenly starts tightly coupling with global context or independent data domains).

5. YOUR TASK

Based on this context, help me design the Technical Specification and Data Standard for this system.

  1. Propose a lightweight specification format (e.g., a Frontmatter YAML Markdown structure) for a feature_passport.md that links Business Requirements to Payload schemas, TypeScript Types, and Next.js code paths.
  2. Design a conceptual system architecture for an offline CLI tool/parser that scans src/payload/blocks/* configurations, extracts data contracts, compares them against the feature_passports, caches the state in a graph.cache.json, and outputs a diff/consistency report.
  3. Provide a critical analysis of how this parser can natively leverage Payload's auto-generated TypeScript types as a "natural graph" to catch data contract violations before code compilation.