Skip to content

exploratory-planning.md

Latest commit

 

History

History
62 lines (42 loc) · 2.37 KB

exploratory-planning.md

File metadata and controls

62 lines (42 loc) · 2.37 KB
Raw

Exploratory Planning

Use this guide when the user provides an estimated performance goal but lacks full endpoint, auth, or SLA detail, or when the workspace appears to contain the application under test.

Activation Rules

Activate exploratory mode only when all of these are true:

  1. The request contains a concrete test intent such as concurrency, duration, throughput, sustained validation, or named business flows.
  2. scenario is explicit or directly inferable from the user's wording.
  3. target, sla, auth, or exact journey details are incomplete.

Do not activate exploratory mode when scenario is still ambiguous after one interpretation pass.

Evidence Order

Use evidence in this order:

  1. Explicit user requirements
  2. Direct workspace evidence from the application code
  3. Deterministic profile defaults already documented in the skill
  4. [assumption-based] placeholders for unresolved execution details

Never skip over stronger evidence to use weaker assumptions.

Application-Context Exploration

When the workspace likely contains the system under test:

  1. Inspect API routes, controllers, service entry points, frontend navigation, HTTP clients, auth middleware, queues, streaming paths, and dashboards.
  2. Prioritize flows that are business-critical, write-heavy, auth-gated, or frequently repeated.
  3. For each inferred candidate, record:
    • name
    • type: endpoint, journey, rpc, websocket, or mixed
    • evidence
    • why_this_flow_matters
  4. Keep the list short and ordered by likely business impact.

Output Requirements

Exploratory plans must include:

  1. plan_mode: exploratory
  2. assumption_basis
  3. inferred_targets
  4. inferred_flows
  5. pending_clarifications
  6. ready_for_builder: false

Use pending_clarifications to mark what still blocks runnable artifacts or validation-complete output.

Suggested SLA Rules

  1. Suggested SLAs must come only from sla-defaults.md or from explicit user placeholder values.
  2. Label every non-confirmed threshold as suggested_sla.
  3. If multiple candidates are offered, explain the comparison briefly and keep the number of candidates low.

Handoff Limits

  1. Do not present exploratory plans as executable-ready.
  2. Do not set ready_for_builder: true while target, auth, or SLA blockers remain unresolved.
  3. Preserve all inferred or [assumption-based] markers in downstream handoff metadata.