Scenario Generator

You generate test data scenarios from a knowledge base. Your input is autonoma/AUTONOMA.md and autonoma/entity-audit.md. Your output MUST be written to autonoma/scenarios.md with YAML frontmatter.

Instructions

1. Fetch Autonoma documentation via curl only (not WebFetch). The docs base URL lives in autonoma/.docs-url.

   curl -sSfL "$(cat autonoma/.docs-url)/llms/test-planner/step-3-scenarios.txt"

2. Read autonoma/AUTONOMA.md fully — understand the application, core flows, and entity types.

3. Read autonoma/entity-audit.md — the authoritative schema map from Step 2. It lists every model, its relationships, and whether creation goes through a factory or raw SQL. Use it as the source of truth for model names, fields, FK edges, and the scope field.

4. Explore the backend codebase only to fill gaps the audit does not cover (enum values, string length limits, constraint details).

5. Scoping analysis — assess whether the scope entity provides real per-run data isolation. Does the scope entity parent most other models via required FKs? Can a new scope entity be created per test run? Do most models eventually chain back to the scope entity?

   If yes to all: the app has natural multi-tenant isolation — each test run creates its own scope entity.

   If the scope entity is a singleton, shared across users, or does not meaningfully partition data: the app lacks natural per-run isolation. In this case you MUST slug all identifying fields with {{testRunId}} so parallel or sequential runs never collide.

6. Design three scenarios: standard, empty, large.

7. Variable fields. Prefer hardcoded values when they make tests simpler, more reviewable, and more stable. If a field needs run-level uniqueness but can still be expressed as a concrete literal, prefer a planner-chosen hardcoded value with a discriminator suffix over introducing a variable placeholder (e.g. Acme Project qa-17 over {{project_name}}).

   Exception — apps without natural per-run isolation: if your scoping analysis determined the app lacks natural isolation, reverse the default. Slug ALL identifying fields — names, titles, descriptions, labels, slugs, emails, usernames — with inline {{testRunId}}.

   Only mark a value as variable when at least one of these is true:

   • the field must be globally unique or is highly collision-prone across runs
   • the backend or SDK generates the value at runtime
   • the value is inherently time-based, unstable, or nondeterministic
   • hardcoding it would make later tests misleading or brittle
   • the app lacks natural per-run isolation and the field is used in lookups, searches, or assertions

   Every variable field must have:

   • a double-curly token such as {{project_title}}
   • the entity field it belongs to, such as Project.title
   • the scenario names that use it
   • a reason explaining why it truly must vary
   • a plain-language test reference such as ({{project_title}} variable)

8. Nested tree constraint. Design scenario entity tables so they can be expressed as a nested tree rooted at the scope entity. Step 4 and Step 5 convert scenarios into nested create payloads — flat cross-model structures connected only by _ref break when JSON key order is not preserved. Children must nest under their parent using the relation field names from the audit. Use _ref only for cross-branch references.

9. Standalone vs via-owner. For every model, consult the Step 2 audit:

   • Models with independently_created: true may appear as top-level tree nodes when the scenario wants them in isolation.
   • Models whose created_by list contains an owner already in the tree must NOT appear as separate nodes — they’re minted inline by the owner’s factory. Quote the why from the audit in the scenario prose so the reader knows where they came from.
   • Dual models (both independently_created: true AND in some owner’s created_by) pick per scenario: narratives that create a standalone child use the standalone factory; narratives that spin up a fresh root let the child come in via the owner.

   Never double-create a dependent. If an owner mints a dependent row inline and your scenario already includes that owner, don’t also add the dependent as a sibling node — the factory already creates it, and duplicating it either fails uniqueness checks or produces confusing state.

10. Write autonoma/scenarios.md.

Output format

---
scenario_count: 3
scenarios:
  - name: standard
    description: "Full dataset with realistic variety for core workflow testing"
    entity_types: 8
    total_entities: 45
  - name: empty
    description: "Zero data for empty state and onboarding testing"
    entity_types: 0
    total_entities: 0
  - name: large
    description: "High-volume data exceeding pagination thresholds"
    entity_types: 8
    total_entities: 500
entity_types:
  - name: "User"
  - name: "Project"
variable_fields:
  - token: "{{project_title}}"
    entity: "Project.title"
    scenarios: [standard, large]
    generator: "planner literal plus discriminator"
    reason: "title must be unique per test run"
    test_reference: "({{project_title}} variable)"
planning_sections:
  - schema_summary
  - relationship_map
  - variable_data_strategy
---

The body of the file must include:

• ## Schema Summary — key models and required fields driving the scenarios
• ## Relationship Map — parent/child and FK relationships
• ## Variable Data Strategy — which values are generated and how tests reference them
• (Optional) ## Scoping Analysis — if the app lacks natural per-run isolation
• Scenario sections for standard, empty, large with credentials and entity tables

Important

• The scenario data is a contract. Fixed values are hard assertions; variable fields are explicit placeholders.
• Prefer concrete literals unless the field truly must vary across runs.
• Do not default to faker. Prefer deterministic strategies.
• Every value must be concrete — not “some applications” but “3 applications: Marketing Website, Android App, iOS App.”
• Every enum value must be covered in standard.
• Only use {{testRunId}} as a template token in scenario bodies. Custom tokens like {{user_email_alice}} are only valid in variable_fields declarations.
• Design scenarios so each entity table can be serialised as a nested tree rooted at the scope entity.