Add 5 pi extensions: pi-subagents, pi-crew, rpiv-pi, pi-interactive-shell, pi-intercom
This commit is contained in:
@@ -0,0 +1,64 @@
|
||||
```markdown
|
||||
# {Project Name} — Test Case Coverage Map
|
||||
|
||||
## Overview
|
||||
- Project: {project name}
|
||||
- Total features: {N} covered
|
||||
- Total test cases: {N}
|
||||
- Estimated full regression: ~{X} minutes
|
||||
- Last updated: {YYYY-MM-DD}
|
||||
- Commit: {commit-hash}
|
||||
|
||||
## Portal Summary
|
||||
|
||||
### {Portal Name} ({N} features, {M} TCs, ~{X}m)
|
||||
| Feature | Module | TCs | High | Med | Low | Smoke | Est. Time |
|
||||
|---------|--------|-----|------|-----|-----|-------|-----------|
|
||||
| {Feature Name} | {MOD} | {N} | {h} | {m} | {l} | {smoke count} | ~{X}m |
|
||||
|
||||
## Project-Wide Smoke Suite
|
||||
{Minimum TCs across ALL features for quick project-level sanity check}
|
||||
|
||||
| Portal | TC ID | Feature | Title | Est. Time |
|
||||
|--------|-------|---------|-------|-----------|
|
||||
| {portal} | TC-{MOD}-{NNN} | {feature} | {title} | ~{N}m |
|
||||
|
||||
**Project smoke total: ~{X} minutes**
|
||||
|
||||
## Cross-Feature Coverage
|
||||
{Areas that span multiple features — verify these when cross-cutting changes are made}
|
||||
|
||||
| Cross-Cutting Area | Features Involved | TCs Covering |
|
||||
|-------------------|-------------------|-------------|
|
||||
| {e.g., Payment Processing} | {Order Mgmt, Invoice Mgmt} | TC-ORD-001, TC-INV-003 |
|
||||
|
||||
## Priority Distribution
|
||||
| Priority | Count | Percentage |
|
||||
|----------|-------|-----------|
|
||||
| High | {N} | {X}% |
|
||||
| Medium | {N} | {X}% |
|
||||
| Low | {N} | {X}% |
|
||||
|
||||
## Uncovered Areas
|
||||
{Features or sub-areas without test cases — flagged for future work}
|
||||
- {uncovered area} — {reason: not yet generated / out of scope / deferred}
|
||||
|
||||
## Phantom Features (Backend-Only)
|
||||
{Backend endpoints with no frontend exposure — skipped during generation. Populated from _meta.md data when available.}
|
||||
- {controller/endpoint group} — {reason: platform API / webhook / deprecated / sub-service}
|
||||
|
||||
## Test Data Requirements
|
||||
{Aggregate test data needs across all features. Populated from _meta.md Test Data Requirements sections when available.}
|
||||
- {e.g., "Stripe test mode with valid API keys (Order Mgmt, Invoice Mgmt)"}
|
||||
- {e.g., "At least 2 published products with inventory (Order Mgmt, Product Mgmt)"}
|
||||
```
|
||||
|
||||
**Portal Summary** groups features by application/portal for QA team assignment. Each portal section includes aggregate stats. Portal names come from `_meta.md` `portal` field when available, or default to "General" when features were generated in standalone mode.
|
||||
|
||||
**Project-Wide Smoke Suite** selects the highest-priority TCs from each feature's smoke subset — typically 1-2 per feature. A QA tester should be able to run the project smoke suite in under 30 minutes.
|
||||
|
||||
**Cross-Feature Coverage** identifies shared concerns (payment, email, auth, inventory) and which TCs from different features exercise them. Useful when a cross-cutting change is made — QA knows exactly which TCs to re-run. Built by scanning postconditions across all regression suites for shared keywords.
|
||||
|
||||
**Phantom Features** documents what was NOT covered and why. Populated from `_meta.md` data (pipeline mode). In standalone mode, populated from phantom detection results. If no phantom data is available, omit this section.
|
||||
|
||||
**Test Data Requirements** consolidates prerequisites across all features so QA can set up a test environment once. Populated from `_meta.md` `## Test Data Requirements` sections. If no _meta.md data is available, omit this section.
|
||||
@@ -0,0 +1,63 @@
|
||||
```markdown
|
||||
# {Feature Name} — Regression Suite
|
||||
|
||||
## Overview
|
||||
- Feature: {feature name}
|
||||
- Module: {module abbreviation}
|
||||
- Total test cases: {N}
|
||||
- Estimated execution: ~{X} minutes
|
||||
- Last updated: {YYYY-MM-DD}
|
||||
- Commit: {commit-hash}
|
||||
|
||||
## Smoke Test Subset
|
||||
{Minimum set of TCs that cover critical paths — run these for quick sanity checks}
|
||||
|
||||
| Priority | TC ID | Title | Est. Time |
|
||||
|----------|-------|-------|-----------|
|
||||
| high | TC-{MOD}-{NNN} | {title} | ~{N}m |
|
||||
|
||||
**Smoke total: ~{X} minutes**
|
||||
|
||||
## Full Regression
|
||||
|
||||
### High Priority
|
||||
| TC ID | Title | Type | Est. Time |
|
||||
|-------|-------|------|-----------|
|
||||
| TC-{MOD}-{NNN} | {title} | {type} | ~{N}m |
|
||||
|
||||
### Medium Priority
|
||||
| TC ID | Title | Type | Est. Time |
|
||||
|-------|-------|------|-----------|
|
||||
| TC-{MOD}-{NNN} | {title} | {type} | ~{N}m |
|
||||
|
||||
### Low Priority
|
||||
| TC ID | Title | Type | Est. Time |
|
||||
|-------|-------|------|-----------|
|
||||
| TC-{MOD}-{NNN} | {title} | {type} | ~{N}m |
|
||||
|
||||
**Full regression total: ~{X} minutes**
|
||||
|
||||
## Coverage Map
|
||||
{Which areas of the feature each TC exercises}
|
||||
|
||||
| Area | TCs Covering |
|
||||
|------|-------------|
|
||||
| {sub-area} | TC-{MOD}-001, TC-{MOD}-003 |
|
||||
|
||||
## Gaps
|
||||
{Areas of the feature NOT covered by any test case — flagged for future work}
|
||||
- {uncovered area — reason}
|
||||
```
|
||||
|
||||
**Smoke test subset** picks TCs that cover the highest-risk paths in minimum time. Typically 2-4 TCs per feature. A QA tester should be able to run the smoke suite in under 15 minutes.
|
||||
|
||||
**Execution time estimates** based on step count:
|
||||
- Simple flow (3-5 steps): ~3 minutes
|
||||
- Medium flow (6-10 steps): ~5 minutes
|
||||
- Complex flow (11+ steps): ~8-10 minutes
|
||||
|
||||
**Coverage map** cross-references TCs against feature sub-areas. Helps QA identify which TCs to re-run when a specific area changes. Sub-areas are derived from Web Layer entry points discovered during analysis.
|
||||
|
||||
**Gaps section** flags areas the skill identified but chose not to generate TCs for — either explicitly excluded during checkpoint or insufficient code detail for generation.
|
||||
|
||||
**Commit** tracks which code version was analyzed. Compare against current HEAD to detect when regression suite may be stale.
|
||||
@@ -0,0 +1,65 @@
|
||||
```markdown
|
||||
---
|
||||
id: TC-{MODULE}-{NNN}
|
||||
title: "{flow description}"
|
||||
feature: "{feature name}"
|
||||
priority: high|medium|low
|
||||
type: functional|regression|smoke|e2e|edge-case
|
||||
status: draft
|
||||
tags: ["{tag1}", "{tag2}"]
|
||||
commit: {commit-hash}
|
||||
---
|
||||
|
||||
# {Title}
|
||||
|
||||
## Objective
|
||||
{What this test verifies — 1-2 sentences describing the user goal and what the test proves}
|
||||
|
||||
## Preconditions
|
||||
- {User role and permissions required}
|
||||
- {System state required before starting — e.g., "at least one product exists in catalog"}
|
||||
- {Test data requirements — e.g., "valid credit card in Stripe test mode"}
|
||||
- {Navigation starting point — e.g., "user is logged into Admin portal"}
|
||||
|
||||
## Steps
|
||||
| # | Action | Expected Result |
|
||||
|---|--------|-----------------|
|
||||
| 1 | {user action — Navigate to, Click, Enter, Select, Submit} | {observable outcome — page loads, form appears, message displays} |
|
||||
| 2 | {next user action} | {what user sees or what changes} |
|
||||
| 3 | {next user action} | {confirmation, redirect, updated state} |
|
||||
|
||||
## Postconditions
|
||||
{Side effects to verify AFTER the flow completes — sourced from domain events and integration points}
|
||||
- {e.g., "Order confirmation email sent to customer email address"}
|
||||
- {e.g., "Inventory quantity decremented for purchased items"}
|
||||
- {e.g., "Audit log entry created with action 'order.created'"}
|
||||
|
||||
## Edge Cases
|
||||
{Variant scenarios worth separate attention — each could become its own TC if important enough}
|
||||
- {e.g., "Order with mixed digital and physical products"}
|
||||
- {e.g., "Payment fails after order created — verify rollback"}
|
||||
|
||||
## Notes
|
||||
- Related TCs: {cross-references to other TCs in this module}
|
||||
- Dependencies: {external system dependencies — payment gateway, email service}
|
||||
- Known issues: {documented bugs or limitations affecting this flow}
|
||||
```
|
||||
|
||||
**Frontmatter fields** align with what `test-case-locator` greps for (`id`, `title`, `priority`, `status`, `type`, `tags`). Always populate all fields — the locator agent extracts them for coverage reporting. The `commit` field tracks which code version was analyzed to produce this TC — used for staleness detection on regeneration.
|
||||
|
||||
**Steps table rules:**
|
||||
- Actions use imperative verbs from the user's perspective: Navigate, Click, Enter, Select, Submit, Drag, Upload, Scroll
|
||||
- Expected results describe what the user OBSERVES — visible UI changes, messages, redirects — not internal state
|
||||
- Keep each row to one atomic action. Multi-step actions (fill form -> submit) split into separate rows
|
||||
- Number steps sequentially — branching flows (if X then Y) become separate TCs
|
||||
|
||||
**Postconditions sourced from:**
|
||||
- Domain events (e.g., `OrderCreatedEvent` -> "confirmation email sent")
|
||||
- Message handlers (e.g., `InventoryReservationHandler` -> "inventory reserved")
|
||||
- Webhook dispatches (e.g., `FulfillmentWebhookPublisher` -> "fulfillment notified")
|
||||
- Audit log entries, cache invalidations, CRM syncs
|
||||
|
||||
**Priority definitions:**
|
||||
- **high**: Core happy path, payment/money flows, data integrity, security-critical
|
||||
- **medium**: Alternative paths, common edge cases, permission boundaries
|
||||
- **low**: Rare edge cases, cosmetic validation, error message wording
|
||||
Reference in New Issue
Block a user