@cubis/foundry 0.3.83 → 0.3.84

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/sadd/agents/spec-miner.md

@@ -1,52 +0,0 @@
-# Spec-Miner Agent
-
-## Role
-
-You are a specification mining agent. Your job is to extract implicit behavioral specifications from existing codebases, test suites, API contracts, and documentation when formal specifications do not exist.
-
-## When to Invoke
-
-- A legacy codebase needs rewriting but has no formal specification document.
-- An API has consumers but the behavioral contract is undocumented.
-- A refactoring effort requires a behavioral baseline to prevent regressions.
-- An inherited project needs specification documentation for new team members.
-
-## Operating Procedure
-
-1. **Identify mining sources.** Catalog the available evidence: test files, code contracts (assertions, guards, type signatures), inline comments, commit history, API documentation, and consumer usage patterns. Rank them by reliability (tests > code contracts > comments > commit messages).
-
-2. **Extract behavioral specifications from tests.** For each test, derive the requirement it implicitly validates. Use the test name, setup, assertion, and teardown to reconstruct the expected behavior. Output as: "The system MUST [behavior] WHEN [condition]."
-
-3. **Extract specifications from code contracts.** Scan for validation logic (input guards, type checks, range constraints), error handling (catch blocks, error codes), and invariants (assertions, preconditions). Each contract point becomes a specification clause.
-
-4. **Extract specifications from comments and documentation.** Look for NOTE, HACK, FIXME, and TODO annotations. Notes and hacks often encode undocumented requirements. TODOs represent future work and should be flagged but not included as current specifications.
-
-5. **Deduplicate and reconcile.** Merge specifications that describe the same behavior from different sources. Flag contradictions (e.g., a test expects X but a comment says Y) for human resolution.
-
-6. **Assign unique identifiers.** Every mined specification gets a REQ-XXX ID, a source reference, and a confidence level (high = from passing test, medium = from code contract, low = from comment only).
-
-7. **Produce the specification document.** Output a structured requirements registry with ID, requirement text, source, confidence, and type.
-
-## Output Format
-
-```markdown
-## Mined Specifications
-
-| REQ ID | Requirement | Source | Confidence | Type |
-|--------|------------|--------|------------|------|
-| REQ-001 | The system MUST [behavior] WHEN [condition] | test_name / code:line / comment | High/Medium/Low | Functional/Non-Functional |
-
-## Contradictions
-| # | Source A | Source B | Conflict Description |
-|---|---------|---------|---------------------|
-
-## Unmined Areas
-- [Areas of the codebase not covered by this mining pass]
-```
-
-## Constraints
-
-- Never invent specifications that are not evidenced by code, tests, or documentation.
-- Always flag low-confidence specifications for human review.
-- Never include TODO items as current requirements.
-- Always cite the exact source (file, line, test name) for every mined specification.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/sadd/agents/verifier.md

@@ -1,70 +0,0 @@
-# Verifier Agent
-
-## Role
-
-You are a specification verifier agent. Your job is to cross-reference a completed implementation against a specification (formal or mined) and produce a verification report that identifies covered requirements, gaps, failures, and ambiguities.
-
-## When to Invoke
-
-- An implementation is complete and needs verification against its specification.
-- A pull request needs review for specification compliance.
-- A release candidate requires a compliance check before deployment.
-- A rewrite needs confirmation that it preserves all behaviors of the original.
-
-## Operating Procedure
-
-1. **Load the specification.** Read the requirements registry or traceability matrix. Confirm the total number of requirements and their IDs. If no matrix exists, flag this and recommend running the spec-miner agent first.
-
-2. **Locate tests for each requirement.** For every REQ-XXX, find the corresponding TEST-XXX. Check that the test exists, is not skipped, and asserts the requirement's expected behavior. Flag requirements without tests.
-
-3. **Run or review test results.** If test results are available, check pass/fail status for each requirement's tests. If results are unavailable, analyze the test code for correctness of assertions relative to the requirement text.
-
-4. **Locate implementation for each requirement.** For every REQ-XXX, find the code location that implements the specified behavior. Verify that the implementation logic matches the requirement semantics, not just the test expectations.
-
-5. **Check for behavioral mismatches.** Compare the requirement text against the implementation logic. Look for:
-   - Off-by-one errors in boundaries (e.g., "at least 8" implemented as `> 8` instead of `>= 8`).
-   - Missing error handling for specified error cases.
-   - Hardcoded values that differ from the specification.
-   - Partial implementations that handle the happy path but skip edge cases.
-
-6. **Identify untested code paths.** Look for implementation branches (if/else, switch/case, try/catch) that have no corresponding test. These represent potential specification gaps or undertested requirements.
-
-7. **Produce the verification report.** Output a structured report with coverage summary, failures, gaps, and recommendations.
-
-## Output Format
-
-```markdown
-## Verification Report
-
-### Coverage Summary
-| Metric | Count |
-|--------|-------|
-| Total requirements | N |
-| Requirements with passing tests | X |
-| Requirements with failing tests | Y |
-| Requirements with no test | Z |
-| Requirements with no implementation | W |
-
-### Failures
-| REQ ID | Test ID | Expected | Actual | Root Cause |
-|--------|---------|----------|--------|------------|
-
-### Gaps
-| REQ ID | Gap Type | Description | Recommendation |
-|--------|----------|-------------|----------------|
-
-### Behavioral Mismatches
-| REQ ID | Spec Says | Code Does | Severity |
-|--------|-----------|-----------|----------|
-
-### Verdict
-[PASS / PASS_WITH_WARNINGS / FAIL]
-[Summary of what needs to happen before this implementation can ship.]
-```
-
-## Constraints
-
-- Never mark a requirement as "verified" without evidence (passing test + matching implementation).
-- Always flag skipped tests as gaps, even if the skip reason seems valid.
-- Never assume implementation correctness from test passage alone; verify the test actually asserts the specified behavior.
-- Always provide a clear verdict with actionable next steps.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/sadd/evals/assertions.md

@@ -1,50 +0,0 @@
-# SADD Eval Assertions
-
-## Eval 1: Spec Extraction from Requirements
-
-This eval tests whether the skill can mine structured, testable specifications from a natural language requirements document.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                          |
-|---|----------|-------------------------------------------------|---------------------------------------------------------------------------------------------------------|
-| 1 | contains | `GIVEN` — GIVEN-WHEN-THEN format usage           | The structured format makes specs testable. Free-form specs cannot be directly mapped to test cases.    |
-| 2 | contains | `unique` — Email uniqueness constraint            | This is a data integrity constraint that requires database-level enforcement and a specific test.       |
-| 3 | contains | `24 hours` — Time-bound expiry spec              | Time-bound requirements are frequently missed in spec extraction and require explicit test setup.       |
-| 4 | contains | `rate limit` — Rate limiting as non-functional   | The 3-per-hour limit is a non-functional requirement that needs its own test with time manipulation.    |
-| 5 | contains | `unverified` — Access restriction spec            | Security specs must be extracted separately because they require negative testing (denied access).      |
-
-### What a passing response looks like
-
-- 7+ specifications extracted (one per bullet in the requirements, plus implicit edge cases).
-- Each spec has a unique ID (e.g., SPEC-001, SPEC-002).
-- Each spec uses GIVEN-WHEN-THEN format with concrete conditions.
-- Specs are classified as functional, non-functional, or security.
-- At least one gap is identified (e.g., "What happens when an expired link is clicked?").
-- Ambiguous requirements are flagged with clarifying questions.
-
----
-
-## Eval 2: Verification Workflow
-
-This eval tests whether the skill can systematically verify an implementation against specifications and identify gaps.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                          |
-|---|----------|-------------------------------------------------|---------------------------------------------------------------------------------------------------------|
-| 1 | contains | `SPEC-003` — Identifies missing quantity-to-zero | The Cart class has no method to set quantity. This gap must be explicitly identified.                   |
-| 2 | contains | `SPEC-005` — Identifies missing checkout guard   | There is no checkout method at all. This is a complete implementation gap.                              |
-| 3 | contains | `SPEC-001` — Confirms add item works             | The addItem method correctly increments itemCount. Must confirm satisfied specs, not only gaps.         |
-| 4 | contains | `SPEC-004` — Confirms duplicate handling          | The existing item check in addItem satisfies the deduplication spec. Must verify positive cases too.   |
-| 5 | contains | `gap` — Explicit gap identification              | Must clearly label gaps and recommend specific implementation changes, not just note them.              |
-
-### What a passing response looks like
-
-- A specification-by-specification verification report.
-- SPEC-001 and SPEC-002 marked as satisfied with evidence from the code.
-- SPEC-004 marked as satisfied, pointing to the `existing` item check.
-- SPEC-003 marked as NOT satisfied, with recommendation to add `setQuantity` or `updateQuantity` method.
-- SPEC-005 marked as NOT satisfied, with recommendation to add `checkout` method with empty cart validation.
-- A summary table showing 3/5 specs satisfied (60% spec coverage).
-- Suggested test cases for the two missing implementations.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/sadd/evals/evals.json

@@ -1,66 +0,0 @@
-[
-  {
-    "name": "spec-extraction-from-requirements",
-    "description": "Validate that the skill extracts complete, testable specifications from a natural language requirements document using structured formats.",
-    "input": "Extract testable specifications from this requirements document:\n\n## User Registration\n- Users must register with email and password.\n- Email must be unique across the system.\n- Password must be at least 8 characters with one uppercase, one lowercase, and one number.\n- After registration, a verification email is sent.\n- Unverified accounts cannot access protected resources.\n- Verification links expire after 24 hours.\n- Users can request a new verification email, but not more than 3 times per hour.\n\nProvide specifications in GIVEN-WHEN-THEN format with IDs and classification.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "GIVEN",
-        "description": "Must use the GIVEN-WHEN-THEN format for specifications, as this is the standard format for testable behavioral specs."
-      },
-      {
-        "type": "contains",
-        "value": "unique",
-        "description": "Must extract the email uniqueness constraint as a distinct specification, since it requires a specific database-level check."
-      },
-      {
-        "type": "contains",
-        "value": "24 hours",
-        "description": "Must extract the verification link expiry as a testable time-bound specification, not just a narrative description."
-      },
-      {
-        "type": "contains",
-        "value": "rate limit",
-        "description": "Must extract the 3-per-hour rate limit on verification email requests as a non-functional specification."
-      },
-      {
-        "type": "contains",
-        "value": "unverified",
-        "description": "Must extract the access restriction on unverified accounts as a security specification with explicit test criteria."
-      }
-    ]
-  },
-  {
-    "name": "verification-workflow",
-    "description": "Validate that the skill can verify an implementation against specifications and identify gaps.",
-    "input": "I have these specifications for a shopping cart:\n\nSPEC-001: GIVEN a logged-in user WHEN they add an item to the cart THEN the cart item count increases by 1.\nSPEC-002: GIVEN a cart with items WHEN the user removes an item THEN the cart item count decreases by 1.\nSPEC-003: GIVEN a cart with items WHEN the user changes quantity to 0 THEN the item is removed from the cart.\nSPEC-004: GIVEN a cart WHEN the user adds an item already in the cart THEN the quantity increases instead of adding a duplicate.\nSPEC-005: GIVEN an empty cart WHEN the user proceeds to checkout THEN they see an error message.\n\nHere is the implementation:\n\n```javascript\nclass Cart {\n  constructor() { this.items = []; }\n\n  addItem(product, quantity = 1) {\n    const existing = this.items.find(i => i.product.id === product.id);\n    if (existing) { existing.quantity += quantity; }\n    else { this.items.push({ product, quantity }); }\n  }\n\n  removeItem(productId) {\n    this.items = this.items.filter(i => i.product.id !== productId);\n  }\n\n  get itemCount() {\n    return this.items.reduce((sum, i) => sum + i.quantity, 0);\n  }\n}\n```\n\nVerify the implementation against the specifications. Identify which specs are satisfied and which have gaps.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "SPEC-003",
-        "description": "Must identify SPEC-003 as not satisfied because there is no setQuantity method that handles setting quantity to 0."
-      },
-      {
-        "type": "contains",
-        "value": "SPEC-005",
-        "description": "Must identify SPEC-005 as not satisfied because there is no checkout method that validates cart emptiness."
-      },
-      {
-        "type": "contains",
-        "value": "SPEC-001",
-        "description": "Must confirm SPEC-001 is satisfied by the addItem method with quantity tracking."
-      },
-      {
-        "type": "contains",
-        "value": "SPEC-004",
-        "description": "Must confirm SPEC-004 is satisfied by the existing item check in addItem that increments quantity."
-      },
-      {
-        "type": "contains",
-        "value": "gap",
-        "description": "Must explicitly identify specification gaps and recommend implementation changes to close them."
-      }
-    ]
-  }
-]

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/sadd/examples/01-basic-usage.md

@@ -1,72 +0,0 @@
-# Example: Extracting Requirements from Acceptance Criteria
-
-## Context
-
-A product manager has written acceptance criteria for a password reset feature. The developer needs to extract testable requirements and build a traceability matrix before writing any code.
-
-## User Prompt
-
-> Here are the acceptance criteria for our password reset feature: (1) User clicks "Forgot Password" and enters their email. (2) System sends a reset link valid for 1 hour. (3) Link contains a unique token. (4) User sets a new password that must be at least 8 characters with one number. (5) After reset, all existing sessions are invalidated. Extract requirements and create a test plan.
-
-## Skill Response
-
-### Specification Source
-
-- **Type:** Semi-formal (acceptance criteria)
-- **Location:** Product brief, Sprint 12
-- **Version:** v1.0 (initial)
-
-### Requirements Registry
-
-| REQ ID | Requirement Text | Type | Priority |
-|--------|-----------------|------|----------|
-| REQ-001 | System sends a password reset email when user submits a registered email address | Functional | Must |
-| REQ-002 | Reset link expires after 1 hour from generation | Functional | Must |
-| REQ-003 | Reset link contains a cryptographically unique token | Functional | Must |
-| REQ-004 | New password must be at least 8 characters | Functional | Must |
-| REQ-005 | New password must contain at least one numeric character | Functional | Must |
-| REQ-006 | All existing sessions are invalidated after successful password reset | Functional | Must |
-| REQ-007 | System does not reveal whether an email is registered (security) | Non-Functional | Should |
-| REQ-008 | Reset token is single-use (cannot be reused after successful reset) | Functional | Should |
-
-### Specification Gaps Identified
-
-| # | Gap Description | Decision Made | Test Added |
-|---|----------------|---------------|------------|
-| 1 | What happens if email is not registered? Spec says "enters their email" but not what happens for unknown emails. | Show same success message for registered and unregistered emails to prevent email enumeration. | TEST-007 |
-| 2 | Can a reset token be used more than once? Spec does not mention single-use. | Token should be single-use and invalidated after successful reset. | TEST-008 |
-| 3 | Rate limiting on reset requests not specified. | Limit to 3 reset requests per email per hour. | TEST-009 |
-
-### Test Cases
-
-| TEST ID | REQ ID | Test Description | Type |
-|---------|--------|-----------------|------|
-| TEST-001 | REQ-001 | Submit registered email; verify reset email is sent | Positive |
-| TEST-002 | REQ-002 | Use reset link after 61 minutes; verify it is rejected | Negative/Boundary |
-| TEST-003 | REQ-002 | Use reset link at 59 minutes; verify it works | Positive/Boundary |
-| TEST-004 | REQ-003 | Generate two reset tokens; verify they are different | Positive |
-| TEST-005 | REQ-004 | Submit 7-character password; verify rejection | Negative |
-| TEST-006 | REQ-005 | Submit all-letter password; verify rejection | Negative |
-| TEST-007 | REQ-007 | Submit unregistered email; verify same response as registered | Security |
-| TEST-008 | REQ-008 | Use reset token twice; verify second use is rejected | Negative |
-| TEST-009 | GAP-003 | Submit 4 reset requests in 1 hour; verify 4th is rate-limited | Negative |
-| TEST-010 | REQ-006 | Reset password; verify existing session tokens are invalidated | Positive |
-
-### Traceability Matrix
-
-| REQ ID | Test IDs | Implementation | Status |
-|--------|----------|---------------|--------|
-| REQ-001 | TEST-001 | Pending | Not started |
-| REQ-002 | TEST-002, TEST-003 | Pending | Not started |
-| REQ-003 | TEST-004 | Pending | Not started |
-| REQ-004 | TEST-005 | Pending | Not started |
-| REQ-005 | TEST-006 | Pending | Not started |
-| REQ-006 | TEST-010 | Pending | Not started |
-| REQ-007 | TEST-007 | Pending | Not started |
-| REQ-008 | TEST-008 | Pending | Not started |
-
-### Key Decisions
-
-1. **Mined 8 requirements from 5 acceptance criteria** -- The original 5 criteria contained compound statements. Splitting them into atomic requirements (REQ-004 and REQ-005 from a single criterion) ensures each is independently testable.
-2. **Added 3 specification gaps** -- Security-critical features like password reset commonly under-specify error handling and abuse prevention. Documenting gaps upfront prevents them from becoming production incidents.
-3. **Boundary tests for time-based requirements** -- REQ-002 gets both a 59-minute (should work) and 61-minute (should fail) test to verify the exact boundary.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/sadd/examples/01-spec-extraction.md

@@ -1,92 +0,0 @@
-# Example: Extract Specifications from a Feature Requirements Document
-
-## Scenario
-
-A product manager wrote a feature requirements document for a file upload feature. The development team needs to extract testable specifications before implementation begins.
-
-## User Prompt
-
-> Extract testable specifications from this feature requirement:
->
-> ## File Upload Feature
-> Users should be able to upload files to their project workspace. Supported formats are PDF, PNG, JPG, and SVG. Maximum file size is 10MB. Files are stored in S3 with a unique key. Uploaded files appear in the file list immediately. Users can delete their own files but not files uploaded by others. Administrators can delete any file. File names are sanitized to remove special characters.
-
-## Expected Response
-
-### Specification Registry
-
-| ID       | Classification | Specification |
-|----------|---------------|---------------|
-| SPEC-001 | Functional    | GIVEN a logged-in user WHEN they upload a PDF, PNG, JPG, or SVG file under 10MB THEN the file is stored successfully and a confirmation is returned. |
-| SPEC-002 | Constraint    | GIVEN a user attempting to upload WHEN the file format is not PDF, PNG, JPG, or SVG THEN the upload is rejected with a descriptive error message. |
-| SPEC-003 | Constraint    | GIVEN a user attempting to upload WHEN the file size exceeds 10MB THEN the upload is rejected with a file-too-large error. |
-| SPEC-004 | Functional    | GIVEN a successful upload WHEN the file is stored THEN it is placed in S3 with a unique key that prevents collisions. |
-| SPEC-005 | Functional    | GIVEN a successful upload WHEN the user views the file list THEN the newly uploaded file appears without requiring a page refresh. |
-| SPEC-006 | Security      | GIVEN a non-admin user WHEN they attempt to delete a file uploaded by another user THEN the deletion is denied with a 403 status. |
-| SPEC-007 | Security      | GIVEN an admin user WHEN they attempt to delete any file THEN the deletion succeeds regardless of who uploaded it. |
-| SPEC-008 | Functional    | GIVEN a user who uploaded a file WHEN they delete it THEN the file is removed from both S3 and the file list. |
-| SPEC-009 | Functional    | GIVEN a file with special characters in its name WHEN it is uploaded THEN the file name is sanitized to contain only alphanumeric characters, hyphens, underscores, and the original extension. |
-
-### Gap Analysis
-
-| Issue | Requirement Text | Question |
-|-------|-----------------|----------|
-| Ambiguous | "appear immediately" | Does "immediately" mean optimistic UI update, or server-confirmed? What is the acceptable latency? |
-| Missing | File name sanitization | What happens if two files have the same name after sanitization? Is a suffix added? |
-| Missing | Upload limits | Is there a limit on the number of files per project or per user? |
-| Missing | Concurrent uploads | Can multiple users upload to the same project simultaneously? |
-| Missing | File replacement | Can a user upload a file with the same name as an existing file? Does it overwrite or create a new version? |
-
-### Test Plan (Skeletons)
-
-```javascript
-describe('File Upload', () => {
-  test('SPEC-001: accepts valid file formats under size limit', async () => {
-    // Arrange: create a 5MB PDF file
-    // Act: POST /api/files with the file
-    // Assert: 201 status, file ID returned, file exists in S3
-  });
-
-  test('SPEC-002: rejects unsupported file formats', async () => {
-    // Arrange: create a .exe file
-    // Act: POST /api/files with the file
-    // Assert: 400 status, error message mentions supported formats
-  });
-
-  test('SPEC-003: rejects files exceeding size limit', async () => {
-    // Arrange: create an 11MB PNG file
-    // Act: POST /api/files with the file
-    // Assert: 413 status, error message mentions 10MB limit
-  });
-
-  test('SPEC-006: prevents non-owner from deleting files', async () => {
-    // Arrange: user A uploads a file, authenticate as user B
-    // Act: DELETE /api/files/:id as user B
-    // Assert: 403 status, file still exists
-  });
-
-  test('SPEC-007: allows admin to delete any file', async () => {
-    // Arrange: user A uploads a file, authenticate as admin
-    // Act: DELETE /api/files/:id as admin
-    // Assert: 200 status, file removed from S3 and database
-  });
-});
-```
-
-### Traceability Matrix
-
-| Requirement | Spec IDs | Test IDs | Module |
-|-------------|----------|----------|--------|
-| Format validation | SPEC-001, SPEC-002 | TEST-001, TEST-002 | upload-service |
-| Size limit | SPEC-003 | TEST-003 | upload-service |
-| S3 storage | SPEC-004 | TEST-004 | storage-adapter |
-| Real-time display | SPEC-005 | TEST-005 | file-list-component |
-| Delete authorization | SPEC-006, SPEC-007, SPEC-008 | TEST-006, TEST-007, TEST-008 | file-service |
-| Name sanitization | SPEC-009 | TEST-009 | upload-service |
-
-## Why This Response Works
-
-- Extracts 9 specifications from 8 sentences of requirements, showing that each sentence may contain multiple testable conditions.
-- Identifies 5 specification gaps that would have been discovered only during implementation without SADD.
-- Provides test skeletons that can be implemented immediately without further spec interpretation.
-- The traceability matrix enables impact analysis when requirements change.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/sadd/examples/02-advanced-usage.md

@@ -1,114 +0,0 @@
-# Example: Mining Specifications from Legacy Code and Verifying a Rewrite
-
-## Context
-
-A team is rewriting a payment processing module from Python 2 to Python 3. The original code has no formal specification, only inline comments and existing tests. The team needs to extract behavioral specifications from the legacy code before rewriting.
-
-## User Prompt
-
-> We're rewriting our payment processing module. The legacy code has no spec -- just 47 tests and scattered comments. I need to: (1) mine the implicit specification from the existing code and tests, (2) create a traceability matrix for the rewrite, and (3) verify the new implementation covers everything the old one did. Walk me through the full SADD workflow.
-
-## Skill Response
-
-### Phase 1: Specification Mining (Spec-Miner Agent)
-
-#### Step 1: Extract Behavioral Specs from Existing Tests
-
-Analyze each test to derive the requirement it implicitly validates:
-
-```markdown
-| Legacy Test | Mined Requirement | REQ ID |
-|-------------|-------------------|--------|
-| test_charge_success | System processes a valid charge and returns a transaction ID | REQ-001 |
-| test_charge_declined | System returns decline reason when card is rejected | REQ-002 |
-| test_charge_insufficient_funds | System distinguishes insufficient funds from other declines | REQ-003 |
-| test_refund_full | System processes full refund for a completed charge | REQ-004 |
-| test_refund_partial | System processes partial refund up to original charge amount | REQ-005 |
-| test_refund_exceeds_charge | System rejects refund exceeding original charge amount | REQ-006 |
-| test_idempotency_key | System returns same result for duplicate requests with same idempotency key | REQ-007 |
-| test_currency_conversion | System converts currencies using rates from rate provider | REQ-008 |
-| test_webhook_delivery | System delivers payment event webhooks to registered endpoints | REQ-009 |
-| test_retry_on_timeout | System retries gateway calls up to 3 times on timeout | REQ-010 |
-```
-
-#### Step 2: Mine Implicit Specs from Code Contracts
-
-```python
-# Legacy code patterns that imply specifications:
-
-def charge(amount, currency, token, idempotency_key=None):
-    """Process a payment charge."""
-    if amount <= 0:                    # REQ-011: Amount must be positive
-        raise ValueError("Amount must be positive")
-    if currency not in SUPPORTED:      # REQ-012: Currency must be in supported list
-        raise ValueError(f"Unsupported currency: {currency}")
-    if len(token) != 32:               # REQ-013: Token must be exactly 32 characters
-        raise ValueError("Invalid token format")
-```
-
-#### Step 3: Mine from Inline Comments
-
-```python
-# Legacy comments that imply specifications:
-# NOTE: Always log PCI-sensitive data as masked  -> REQ-014: PCI data masking in logs
-# HACK: Rate limit to 100 req/s per merchant    -> REQ-015: Rate limiting at 100 req/s
-# TODO: Add support for 3D Secure               -> NOT a requirement (future work)
-```
-
-### Phase 2: Traceability Matrix for Rewrite
-
-| REQ ID | Requirement | Legacy Test | Legacy Code Location | New Test ID | New Code Location | Status |
-|--------|------------|-------------|---------------------|-------------|-------------------|--------|
-| REQ-001 | Process valid charge, return tx ID | test_charge_success | charge.py:45 | TEST-001 | — | Pending |
-| REQ-002 | Return decline reason on rejection | test_charge_declined | charge.py:72 | TEST-002 | — | Pending |
-| REQ-003 | Distinguish insufficient funds | test_charge_insufficient_funds | charge.py:89 | TEST-003 | — | Pending |
-| REQ-004 | Full refund for completed charge | test_refund_full | refund.py:23 | TEST-004 | — | Pending |
-| REQ-005 | Partial refund up to original | test_refund_partial | refund.py:41 | TEST-005 | — | Pending |
-| REQ-006 | Reject over-refund | test_refund_exceeds_charge | refund.py:58 | TEST-006 | — | Pending |
-| REQ-007 | Idempotency key dedup | test_idempotency_key | charge.py:110 | TEST-007 | — | Pending |
-| REQ-008 | Currency conversion | test_currency_conversion | fx.py:15 | TEST-008 | — | Pending |
-| REQ-009 | Webhook delivery | test_webhook_delivery | events.py:30 | TEST-009 | — | Pending |
-| REQ-010 | Retry on timeout (3x) | test_retry_on_timeout | charge.py:130 | TEST-010 | — | Pending |
-| REQ-011 | Amount must be positive | (code contract) | charge.py:46 | TEST-011 | — | Pending |
-| REQ-012 | Currency must be supported | (code contract) | charge.py:48 | TEST-012 | — | Pending |
-| REQ-013 | Token must be 32 chars | (code contract) | charge.py:50 | TEST-013 | — | Pending |
-| REQ-014 | PCI data masking in logs | (comment) | logging.py:12 | TEST-014 | — | Pending |
-| REQ-015 | Rate limit 100 req/s/merchant | (comment) | middleware.py:8 | TEST-015 | — | Pending |
-
-### Phase 3: Verification (Verifier Agent)
-
-After the rewrite is complete, run verification:
-
-```markdown
-## Verification Report
-
-### Coverage Summary
-| Metric | Count |
-|--------|-------|
-| Total requirements | 15 |
-| Requirements with passing tests | 13 |
-| Requirements with failing tests | 1 |
-| Requirements with no test | 1 |
-
-### Failures
-| REQ ID | Issue |
-|--------|-------|
-| REQ-010 | New implementation retries 2 times, not 3. Legacy code used `for i in range(3)` (3 retries after initial attempt = 4 total). New code uses `max_retries=2`. |
-
-### Gaps
-| REQ ID | Issue |
-|--------|-------|
-| REQ-015 | Rate limiting test (TEST-015) exists but is skipped in CI. No integration test validates the 100 req/s threshold under load. |
-
-### Recommendation
-1. Fix REQ-010: Change `max_retries=2` to `max_retries=3` in the new gateway client.
-2. Fix REQ-015: Add a load test that verifies rate limiting engages at 100 req/s.
-3. After fixes, all 15 requirements will have passing tests and verified implementations.
-```
-
-### Key Decisions
-
-1. **Three mining sources** -- Tests, code contracts, and comments each reveal different types of implicit specifications. Using all three provides the most complete picture.
-2. **Legacy-to-new mapping** -- The traceability matrix includes both legacy and new locations, enabling side-by-side verification during the rewrite.
-3. **Verifier catches subtle discrepancy** -- The retry count difference (3 vs 2) is exactly the kind of behavioral regression that code review misses but spec-aware verification catches.
-4. **Excluded TODO comments** -- "TODO: Add 3D Secure" is future work, not an existing behavioral spec. Including it would inflate the requirement set with unimplemented features.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/sadd/examples/02-implementation-verification.md

@@ -1,126 +0,0 @@
-# Example: Verify Implementation Against Specifications
-
-## Scenario
-
-A team implemented a user authentication module based on specifications extracted earlier. They need to verify the implementation satisfies all specs and identify any gaps before release.
-
-## User Prompt
-
-> Verify this authentication implementation against our specifications:
->
-> **Specifications:**
-> - SPEC-101: GIVEN valid credentials WHEN the user logs in THEN a JWT access token (15min expiry) and refresh token (7day expiry) are returned.
-> - SPEC-102: GIVEN an expired access token WHEN the user makes an API request THEN a 401 is returned with code TOKEN_EXPIRED.
-> - SPEC-103: GIVEN a valid refresh token WHEN the user requests token refresh THEN a new access token is returned and the old refresh token is revoked.
-> - SPEC-104: GIVEN 5 failed login attempts WHEN the user attempts a 6th login THEN the account is locked for 15 minutes.
-> - SPEC-105: GIVEN a locked account WHEN the lock period expires THEN the user can log in normally.
->
-> **Implementation:**
-> ```python
-> class AuthService:
->     def login(self, email, password):
->         user = self.user_repo.find_by_email(email)
->         if not user or not verify_password(password, user.password_hash):
->             raise InvalidCredentialsError()
->         access_token = create_jwt(user.id, expires_in=900)
->         refresh_token = create_refresh_token(user.id, expires_in=604800)
->         return {"access_token": access_token, "refresh_token": refresh_token}
->
->     def refresh(self, refresh_token):
->         payload = verify_refresh_token(refresh_token)
->         if not payload:
->             raise InvalidTokenError()
->         new_access = create_jwt(payload["user_id"], expires_in=900)
->         return {"access_token": new_access}
->
->     def verify_access(self, token):
->         payload = decode_jwt(token)
->         if not payload:
->             raise AuthenticationError("TOKEN_EXPIRED")
->         return payload
-> ```
-
-## Expected Response
-
-### Verification Report
-
-| Spec ID  | Status           | Evidence                                              |
-|----------|------------------|-------------------------------------------------------|
-| SPEC-101 | SATISFIED        | `login()` creates JWT with 900s (15min) and refresh with 604800s (7day). Token pair returned correctly. |
-| SPEC-102 | PARTIALLY MET    | `verify_access()` raises `AuthenticationError("TOKEN_EXPIRED")` but does not distinguish between expired and invalid tokens. |
-| SPEC-103 | NOT SATISFIED    | `refresh()` creates a new access token but does NOT revoke the old refresh token. Token reuse attack vector. |
-| SPEC-104 | NOT SATISFIED    | No failed login attempt tracking. No account locking mechanism. Entire spec is unimplemented. |
-| SPEC-105 | NOT SATISFIED    | Depends on SPEC-104 which is unimplemented. No lock expiry logic exists. |
-
-### Summary
-
-- **Satisfied**: 1/5 (20%)
-- **Partially met**: 1/5 (20%)
-- **Not satisfied**: 3/5 (60%)
-
-### Gap Details
-
-**SPEC-103: Missing refresh token revocation**
-
-The `refresh()` method issues a new access token but leaves the old refresh token valid. This means:
-- A stolen refresh token can be used indefinitely.
-- There is no way to detect token reuse (a common indicator of compromise).
-
-**Recommended fix**:
-```python
-def refresh(self, refresh_token):
-    payload = verify_refresh_token(refresh_token)
-    if not payload:
-        raise InvalidTokenError()
-    # Revoke old refresh token
-    self.token_repo.revoke(refresh_token)
-    # Issue new token pair
-    new_access = create_jwt(payload["user_id"], expires_in=900)
-    new_refresh = create_refresh_token(payload["user_id"], expires_in=604800)
-    return {"access_token": new_access, "refresh_token": new_refresh}
-```
-
-**SPEC-104 and SPEC-105: Missing account locking**
-
-The login method has no tracking of failed attempts. Implementation needed:
-1. Add a `failed_attempts` counter and `locked_until` timestamp to the user model.
-2. Increment `failed_attempts` on each failed login.
-3. When `failed_attempts >= 5`, set `locked_until = now + 15 minutes`.
-4. Check `locked_until` before validating credentials.
-5. Reset `failed_attempts` on successful login.
-
-### Verification Tests to Add
-
-```python
-def test_spec_103_refresh_revokes_old_token():
-    # Arrange: login and get tokens
-    tokens = auth.login("user@test.com", "password")
-    # Act: refresh to get new tokens
-    new_tokens = auth.refresh(tokens["refresh_token"])
-    # Assert: old refresh token is no longer valid
-    with pytest.raises(InvalidTokenError):
-        auth.refresh(tokens["refresh_token"])
-
-def test_spec_104_account_locks_after_5_failures():
-    # Arrange: valid user exists
-    # Act: attempt login 6 times with wrong password
-    for i in range(5):
-        with pytest.raises(InvalidCredentialsError):
-            auth.login("user@test.com", "wrong")
-    # Assert: 6th attempt raises AccountLockedError
-    with pytest.raises(AccountLockedError):
-        auth.login("user@test.com", "correct_password")
-
-def test_spec_105_lock_expires_after_15_minutes():
-    # Arrange: lock the account by failing 5 times
-    # Act: advance time by 16 minutes
-    # Assert: login succeeds with correct password
-```
-
-## Why This Response Works
-
-- Provides a spec-by-spec verification with clear status and evidence.
-- Distinguishes between "not satisfied" and "partially met" which is important for prioritization.
-- Identifies a security-relevant gap (refresh token reuse) that could be exploited.
-- Provides concrete code fixes, not just descriptions of what is wrong.
-- Includes test cases that would catch these gaps in the future.