@planu/cli 3.9.8 → 3.9.9

package/dist/tools/challenge-spec/resilience-challenge-scenarios-a.d.ts

@@ -1,35 +0,0 @@
-import type { FailureScenario, Spec } from '../../types/index.js';
-export declare const EXTERNAL_CALL_KEYWORDS: string[];
-export declare const VALIDATION_KEYWORDS: string[];
-export declare const RATE_LIMIT_KEYWORDS: string[];
-export declare const CONCURRENCY_KEYWORDS: string[];
-export declare const SAGA_KEYWORDS: string[];
-/**
- * Returns true when the spec describes an external service call.
- */
-export declare function hasExternalCallSignal(spec: Spec, specContent: string): boolean;
-/**
- * Returns true when the spec describes input validation.
- */
-export declare function hasValidationSignal(spec: Spec, specContent: string): boolean;
-/**
- * Returns true when the spec is a rate-limit-sensitive endpoint.
- */
-export declare function hasRateLimitSignal(spec: Spec, specContent: string): boolean;
-/**
- * Returns true when the spec involves shared state.
- */
-export declare function hasConcurrencySignal(spec: Spec, specContent: string): boolean;
-/**
- * Returns true when the spec describes a distributed saga.
- */
-export declare function hasSagaSignal(spec: Spec, specContent: string): boolean;
-/**
- * Generate validation boundary challenge scenarios.
- */
-export declare function generateValidationBoundaryScenarios(spec: Spec): FailureScenario[];
-/**
- * Generate cascade failure challenge scenarios.
- */
-export declare function generateCascadeFailureScenarios(spec: Spec): FailureScenario[];
-//# sourceMappingURL=resilience-challenge-scenarios-a.d.ts.map

package/dist/tools/challenge-spec/resilience-challenge-scenarios-a.js

@@ -1,199 +0,0 @@
-// tools/challenge-spec/resilience-challenge-scenarios-a.ts — SPEC-034
-// Signal detectors + validation boundary + cascade failure scenarios
-// Keywords indicating external service calls or shared state
-export const EXTERNAL_CALL_KEYWORDS = [
-    'api',
-    'http',
-    'fetch',
-    'request',
-    'endpoint',
-    'service',
-    'downstream',
-    'external',
-    'grpc',
-    'webhook',
-    'integration',
-    'client',
-    'sdk',
-];
-export const VALIDATION_KEYWORDS = [
-    'input',
-    'form',
-    'body',
-    'payload',
-    'request',
-    'submit',
-    'create',
-    'update',
-    'post',
-    'put',
-    'patch',
-    'validate',
-    'schema',
-    'endpoint',
-];
-export const RATE_LIMIT_KEYWORDS = [
-    'login',
-    'auth',
-    'register',
-    'public',
-    'api',
-    'bulk',
-    'export',
-    'import',
-];
-export const CONCURRENCY_KEYWORDS = [
-    'counter',
-    'cache',
-    'session',
-    'pool',
-    'shared',
-    'concurrent',
-    'parallel',
-    'queue',
-    'lock',
-    'mutex',
-    'atomic',
-    'thread',
-];
-export const SAGA_KEYWORDS = [
-    'distributed',
-    'saga',
-    'multi-step',
-    'compensat',
-    'rollback',
-    'orchestrat',
-    'choreograph',
-    'transaction',
-];
-/**
- * Returns true when the spec describes an external service call.
- */
-export function hasExternalCallSignal(spec, specContent) {
-    const lower = `${spec.title} ${spec.tags.join(' ')} ${specContent}`.toLowerCase();
-    return EXTERNAL_CALL_KEYWORDS.some((kw) => lower.includes(kw));
-}
-/**
- * Returns true when the spec describes input validation.
- */
-export function hasValidationSignal(spec, specContent) {
-    const lower = `${spec.title} ${spec.tags.join(' ')} ${specContent}`.toLowerCase();
-    return VALIDATION_KEYWORDS.some((kw) => lower.includes(kw));
-}
-/**
- * Returns true when the spec is a rate-limit-sensitive endpoint.
- */
-export function hasRateLimitSignal(spec, specContent) {
-    const lower = `${spec.title} ${spec.tags.join(' ')} ${specContent}`.toLowerCase();
-    return RATE_LIMIT_KEYWORDS.some((kw) => lower.includes(kw));
-}
-/**
- * Returns true when the spec involves shared state.
- */
-export function hasConcurrencySignal(spec, specContent) {
-    const lower = `${spec.title} ${spec.tags.join(' ')} ${specContent}`.toLowerCase();
-    return CONCURRENCY_KEYWORDS.some((kw) => lower.includes(kw));
-}
-/**
- * Returns true when the spec describes a distributed saga.
- */
-export function hasSagaSignal(spec, specContent) {
-    const lower = `${spec.title} ${spec.tags.join(' ')} ${specContent}`.toLowerCase();
-    return SAGA_KEYWORDS.some((kw) => lower.includes(kw));
-}
-/**
- * Generate validation boundary challenge scenarios.
- */
-export function generateValidationBoundaryScenarios(spec) {
-    return [
-        {
-            scenario: `[${spec.id}] Validation Boundary — String Fields: ` +
-                'What happens when a required string field receives: (a) empty string "", (b) null, (c) field absent from body entirely, ' +
-                '(d) string with only whitespace "   ", (e) Unicode multibyte string (emoji) that exceeds maxLength if the library counts bytes instead of codepoints? ' +
-                'Are all three cases (absent vs null vs empty) handled with distinct error codes?',
-            probability: 'high',
-            impact: 'high',
-            currentHandling: 'Validation may treat empty and null as equivalent, or silently pass absent fields as undefined without failing required checks.',
-            requiredHandling: 'Define explicit behavior for each case in the validation schema. ' +
-                'Empty string "" → 400 if field is required. ' +
-                'null → 400 if field is non-nullable. ' +
-                'Absent field → 400 if field is required. ' +
-                'Whitespace-only → trim and validate length after trimming. ' +
-                'Unicode: use character/codepoint counting, not byte length.',
-            dataConsistency: 'Accepting empty strings as valid inputs leads to records with meaningless values polluting the database.',
-            userExperience: 'Clear per-field error messages with the specific constraint violated improve form UX significantly.',
-        },
-        {
-            scenario: `[${spec.id}] Validation Boundary — Numeric Fields: ` +
-                'What happens when a numeric field receives: (a) value exactly at min boundary (e.g., min=0 → test with -1, 0, 1), ' +
-                '(b) value exactly at max boundary, (c) NaN, (d) Infinity or -Infinity, ' +
-                '(e) number sent as string "42" — does the library coerce or reject?',
-            probability: 'medium',
-            impact: 'high',
-            currentHandling: 'Boundary conditions (exactly at min/max) are often omitted from tests, leading to off-by-one bugs in production.',
-            requiredHandling: 'Test all boundary values explicitly: min-1 (fail), min (pass), max (pass), max+1 (fail). ' +
-                'NaN and Infinity must be rejected with 400, not passed through. ' +
-                'Coercion policy must be explicit: either always reject type mismatches or always coerce with documented behavior.',
-            dataConsistency: 'NaN or Infinity stored in numeric columns causes silent corruption or runtime exceptions.',
-            userExperience: 'Off-by-one errors in validation create confusing UX where users cannot submit valid data.',
-        },
-        {
-            scenario: `[${spec.id}] Validation Security — Injection Payloads: ` +
-                'Does the validation layer handle security-relevant strings without crashing or leaking internals? ' +
-                "Test with: SQL injection ('; DROP TABLE users; --), XSS (<script>alert(1)</script>), " +
-                'path traversal (../../etc/passwd), null bytes (\\0), template injection ({{7*7}}). ' +
-                'Validation is not the primary defense (that is parameterized queries / output encoding), ' +
-                'but it must not crash and must not expose stack traces.',
-            probability: 'medium',
-            impact: 'critical',
-            currentHandling: 'Injection payloads may cause unhandled exceptions in validation middleware, exposing internal error details.',
-            requiredHandling: 'All string inputs must be treated as untrusted. ' +
-                'Validation rejects malformed types; sanitization and parameterized queries handle injection prevention downstream. ' +
-                'Error responses must never include the rejected payload or stack trace — return sanitized field name + constraint only.',
-            dataConsistency: 'If injection payloads reach the database layer (even as errors), they can leak schema information via error messages.',
-            userExperience: 'Stack traces exposed in 400 responses are a security vulnerability — use opaque error IDs instead.',
-        },
-    ];
-}
-/**
- * Generate cascade failure challenge scenarios.
- */
-export function generateCascadeFailureScenarios(spec) {
-    return [
-        {
-            scenario: `[${spec.id}] Cascade Failure — Connection Pool Exhaustion: ` +
-                'If the external service starts responding in 30 seconds (OS timeout) instead of the expected 200ms, ' +
-                'how many simultaneous requests accumulate in the connection pool before the circuit breaker activates? ' +
-                'If the pool has size N and each request holds a connection for T seconds, the pool fills in N * T seconds. ' +
-                'Calculate this with the actual pool size and timeout values. ' +
-                'Does the circuit breaker open before the pool is exhausted?',
-            probability: 'medium',
-            impact: 'critical',
-            currentHandling: 'Without a circuit breaker, slow external services cause connection pool exhaustion, ' +
-                'blocking all requests to this service (not just those calling the external service).',
-            requiredHandling: 'Set connect_timeout (2s) and read_timeout (10s) — never rely on OS timeout (30s+). ' +
-                'Circuit breaker must open before pool exhaustion: threshold 50% failures in 10 calls, open duration 60s. ' +
-                'When pool is at 80% capacity, emit a warning metric. ' +
-                'When circuit is open, return 503 immediately without touching the pool.',
-            dataConsistency: 'Pool exhaustion can cascade: if this service pool is exhausted, callers of this service also accumulate requests.',
-            userExperience: 'Without fast-fail (circuit open), users wait for OS timeout (30s) instead of receiving a 503 in under 1s.',
-        },
-        {
-            scenario: `[${spec.id}] Resilience — Retry Thundering Herd: ` +
-                'If the external service recovers after a 60-second outage and the circuit breaker transitions to HALF-OPEN, ' +
-                'all queued retries fire simultaneously. ' +
-                'Does the retry strategy use jitter (random delay offset) to spread the load, ' +
-                'or do all retries hit the recovering service at the same time (thundering herd)?',
-            probability: 'medium',
-            impact: 'high',
-            currentHandling: 'Retry without jitter causes thundering herd: all retries fire simultaneously after backoff, ' +
-                'potentially re-overloading the service as it recovers.',
-            requiredHandling: 'Exponential backoff with jitter: delay = random(0, base * 2^attempt). ' +
-                'In HALF-OPEN state: limit to 1-3 probe requests, not all queued requests simultaneously. ' +
-                'If probes succeed, circuit closes gradually.',
-            dataConsistency: 'Thundering herd can cause the recovering service to fail again immediately after recovery.',
-            userExperience: 'Jitter is invisible to the user but prevents the oscillation pattern where the service flaps between healthy and degraded.',
-        },
-    ];
-}
-//# sourceMappingURL=resilience-challenge-scenarios-a.js.map

package/dist/tools/challenge-spec/resilience-challenge-scenarios-b.d.ts

@@ -1,14 +0,0 @@
-import type { FailureScenario, Spec } from '../../types/index.js';
-/**
- * Generate rate limit bypass challenge scenarios.
- */
-export declare function generateRateLimitBypassScenarios(spec: Spec): FailureScenario[];
-/**
- * Generate concurrency model-specific challenge scenarios.
- */
-export declare function generateConcurrencyScenarios(spec: Spec, concurrencyModel: string): FailureScenario[];
-/**
- * Generate distributed saga failure scenarios.
- */
-export declare function generateSagaFailureScenarios(spec: Spec): FailureScenario[];
-//# sourceMappingURL=resilience-challenge-scenarios-b.d.ts.map

package/dist/tools/challenge-spec/resilience-challenge-scenarios-b.js

@@ -1,149 +0,0 @@
-// tools/challenge-spec/resilience-challenge-scenarios-b.ts — SPEC-034
-// Rate limit bypass + concurrency model-specific + distributed saga scenarios
-/**
- * Generate rate limit bypass challenge scenarios.
- */
-export function generateRateLimitBypassScenarios(spec) {
-    return [
-        {
-            scenario: `[${spec.id}] Rate Limit Bypass — Distributed Attack: ` +
-                'The rate limit is configured per-IP. An attacker uses 1000 different IPs (botnet or distributed scraper) ' +
-                'to bypass the per-IP limit. What is the effective global rate of requests the system receives? ' +
-                'Does the system have any IP-independent rate limiting (per-account, global circuit breaker) to handle this?',
-            probability: 'medium',
-            impact: 'high',
-            currentHandling: 'Per-IP rate limiting is ineffective against distributed attacks — an attacker with 1000 IPs gets 1000x the per-IP limit.',
-            requiredHandling: 'Layer rate limits: per-IP (coarse), per-account/API-key (fine-grained), and global per-endpoint. ' +
-                'For authentication endpoints: per-account lockout after N failed attempts (regardless of source IP). ' +
-                'Use Redis-backed distributed rate limiting for consistency across multiple instances.',
-            dataConsistency: 'In-memory rate limiting (local to one instance) allows the effective limit to be multiplied by the number of instances.',
-            userExperience: 'Rate limit responses must include Retry-After header so legitimate clients can back off gracefully.',
-        },
-    ];
-}
-/**
- * Generate concurrency model-specific challenge scenarios.
- */
-export function generateConcurrencyScenarios(spec, concurrencyModel) {
-    const modelScenarios = {
-        goroutines: {
-            scenario: `[${spec.id}] Concurrency — Go Race Condition: ` +
-                'If this feature reads and writes shared state (counter, map, cache) from multiple goroutines simultaneously, ' +
-                'is the access protected by sync.Mutex, sync.RWMutex, or sync/atomic? ' +
-                'Run with `go test -race` to verify. ' +
-                'A map accessed concurrently without a lock is undefined behavior in Go (runtime panic possible).',
-            probability: 'high',
-            impact: 'critical',
-            currentHandling: 'Without mutex protection, concurrent map writes in Go cause a runtime panic or silent data corruption.',
-            requiredHandling: 'Use sync.RWMutex for read-heavy maps (multiple concurrent reads, exclusive writes). ' +
-                'Use sync/atomic for simple counters. ' +
-                'Always run `go test -race ./...` in CI to detect race conditions before production.',
-            dataConsistency: 'Race conditions on shared state lead to inconsistent reads and corrupted writes that are hard to reproduce.',
-            userExperience: 'A runtime panic from a race condition kills the entire goroutine group, causing an unexpected 500.',
-        },
-        'async-await': {
-            scenario: `[${spec.id}] Concurrency — Event Loop Blocking: ` +
-                'Does this feature perform any synchronous CPU-intensive or I/O-blocking operation inside an async function? ' +
-                'Examples: JSON.parse on large payloads (> 1MB), crypto operations (bcrypt without async), ' +
-                'RegExp with catastrophic backtracking. ' +
-                'These block the single-threaded event loop and degrade ALL concurrent requests, not just this one.',
-            probability: 'medium',
-            impact: 'high',
-            currentHandling: 'Synchronous operations inside async handlers block the Node.js event loop, causing latency spikes for all concurrent requests.',
-            requiredHandling: 'Move CPU-intensive operations to worker threads (worker_threads module). ' +
-                'Use async crypto APIs (bcrypt.hash not bcrypt.hashSync). ' +
-                'Test with clinic.js or --inspect + async_hooks to identify event loop blocking before production.',
-            dataConsistency: 'No data consistency impact — performance issue only.',
-            userExperience: 'Event loop blocking causes P99 latency spikes that affect all users, not just those using the slow feature.',
-        },
-        'threads-locks': {
-            scenario: `[${spec.id}] Concurrency — Deadlock Risk: ` +
-                'If this feature acquires multiple locks (e.g., lock on resource A, then lock on resource B), ' +
-                'is there another code path that acquires the same locks in the opposite order (B first, then A)? ' +
-                'This is the classic deadlock condition. ' +
-                'Test by running the two paths simultaneously with a short sleep between lock acquisitions.',
-            probability: 'medium',
-            impact: 'critical',
-            currentHandling: 'Inconsistent lock ordering causes deadlocks that hang threads indefinitely, eventually exhausting the thread pool.',
-            requiredHandling: 'Establish a canonical lock ordering (always A before B, never B before A). Document this ordering. ' +
-                'Use tryLock(timeout) in tests to detect deadlocks: if the lock is not acquired in N seconds, the test fails. ' +
-                'Consider using ReentrantLock over synchronized blocks for more control.',
-            dataConsistency: 'Deadlocked threads hold locks, preventing other threads from accessing the protected resources.',
-            userExperience: 'A deadlock causes the request to hang until the timeout is reached, resulting in a 503 or 504 for the user.',
-        },
-        'rust-ownership': {
-            scenario: `[${spec.id}] Concurrency — Rust Logical Deadlock: ` +
-                'Rust prevents data races at compile time via the borrow checker. ' +
-                'However, logical deadlocks (two async tasks waiting for each other via Mutex or channel) are still possible at runtime. ' +
-                'If this feature acquires Arc<Mutex<T>> guards in multiple futures, is the acquisition order consistent? ' +
-                'The Rust compiler will not catch this — it must be tested with deadlock timeout tests.',
-            probability: 'low',
-            impact: 'high',
-            currentHandling: 'Rust eliminates data races at compile time, but logical deadlocks between async tasks holding Mutex guards are runtime errors.',
-            requiredHandling: 'Use tokio::time::timeout to wrap Mutex acquisitions in async code. ' +
-                'If the lock is not acquired within the timeout, return an error instead of hanging. ' +
-                'Document the lock acquisition order and enforce it via code review.',
-            dataConsistency: 'Deadlocked async tasks hold Mutex guards, blocking other tasks from accessing the protected data.',
-            userExperience: 'Logical deadlocks in Rust async code cause requests to timeout rather than return an error — prefer explicit timeout.',
-        },
-        'actor-model': {
-            scenario: `[${spec.id}] Concurrency — Mailbox Overflow: ` +
-                'If the producer sends messages to this actor faster than the actor processes them, ' +
-                'the mailbox grows unboundedly. ' +
-                'What is the configured mailbox size limit? What happens when the limit is reached: ' +
-                'back-pressure (producer blocks), message drop (with which strategy), or unbounded growth (memory risk)?',
-            probability: 'medium',
-            impact: 'high',
-            currentHandling: 'Unbounded mailboxes cause memory exhaustion under load. Message drops without metrics cause silent data loss.',
-            requiredHandling: 'Configure a bounded mailbox with a drop strategy (drop-oldest or drop-newest). ' +
-                'Emit a metric when mailbox exceeds 80% capacity. ' +
-                'Consider back-pressure: if the producer is too fast, slow it down at the source instead of dropping at the destination.',
-            dataConsistency: 'Dropped messages cause data loss that is not recoverable without event sourcing or DLQ.',
-            userExperience: 'Mailbox overflow is invisible to users until they notice missing data or failed operations.',
-        },
-        'reactive-streams': {
-            scenario: `[${spec.id}] Concurrency — Backpressure Strategy: ` +
-                'This spec uses a reactive stream. If the publisher emits faster than the subscriber processes, ' +
-                'what backpressure strategy is in use? ' +
-                'BUFFER (memory risk), DROP (data loss), ERROR (stream terminates), LATEST (only last value), or MISSING (unbounded)? ' +
-                'The strategy must match the business requirements: can messages be dropped or is each one required?',
-            probability: 'medium',
-            impact: 'high',
-            currentHandling: 'Without explicit backpressure strategy, fast publishers overflow the subscriber buffer, causing OutOfMemoryError or silent drops.',
-            requiredHandling: 'Choose the backpressure strategy explicitly based on business requirements. ' +
-                'For critical events: use ERROR or bounded BUFFER to prevent loss. ' +
-                'For metrics/logging: DROP or LATEST is acceptable. ' +
-                'Test with a producer that emits 10x faster than the subscriber to verify the strategy holds.',
-            dataConsistency: 'Backpressure strategy determines whether data loss is acceptable or whether the stream must be slowed down.',
-            userExperience: 'Backpressure overflow can cause request failures for the publisher, which surfaces as 503 or timeout.',
-        },
-    };
-    const scenario = modelScenarios[concurrencyModel];
-    return scenario ? [scenario] : [];
-}
-/**
- * Generate distributed saga failure scenarios.
- */
-export function generateSagaFailureScenarios(spec) {
-    return [
-        {
-            scenario: `[${spec.id}] Distributed Saga — Partial Failure at Step N: ` +
-                'If step 3 of 5 in the saga fails after steps 1 and 2 already executed in external services, ' +
-                'how long do the compensation events (rollback for steps 1 and 2) take to complete? ' +
-                'How is it verified that the system is in a consistent state after compensation, ' +
-                'rather than in a partially-reverted state (step 1 rolled back but step 2 not yet)?',
-            probability: 'medium',
-            impact: 'critical',
-            currentHandling: 'Partial saga failures without compensation leave the system in an inconsistent state ' +
-                '(some external services have committed while others have not).',
-            requiredHandling: 'Each saga step must have a defined compensation operation. ' +
-                'Compensation must be idempotent (can be retried safely). ' +
-                'Track saga state in a durable store: if the orchestrator crashes mid-saga, it must resume from the last known state. ' +
-                'Add a saga status endpoint: GET /sagas/{id} returns the current step, status, and any failed compensations.',
-            dataConsistency: 'Partial compensation leaves distributed state inconsistent. The saga log must be the source of truth for rollback status.',
-            userExperience: 'Users must receive a clear error explaining that the operation was rolled back and what state the system is in. ' +
-                'If rollback also failed, the user must be told that manual resolution is required.',
-        },
-    ];
-}
-//# sourceMappingURL=resilience-challenge-scenarios-b.js.map

package/dist/tools/challenge-spec/resilience-challenge-scenarios.d.ts

@@ -1,8 +0,0 @@
-import type { FailureScenario, Spec, ProjectKnowledge } from '../../types/index.js';
-export { EXTERNAL_CALL_KEYWORDS, VALIDATION_KEYWORDS, RATE_LIMIT_KEYWORDS, CONCURRENCY_KEYWORDS, SAGA_KEYWORDS, hasExternalCallSignal, hasValidationSignal, hasRateLimitSignal, hasConcurrencySignal, hasSagaSignal, generateValidationBoundaryScenarios, generateCascadeFailureScenarios, } from './resilience-challenge-scenarios-a.js';
-export { generateRateLimitBypassScenarios, generateConcurrencyScenarios, generateSagaFailureScenarios, } from './resilience-challenge-scenarios-b.js';
-/**
- * Main entry: generate all SPEC-034 resilience/concurrency challenges for a spec.
- */
-export declare function generateResilienceChallengeScenarios(spec: Spec, specContent: string, knowledge: ProjectKnowledge): FailureScenario[];
-//# sourceMappingURL=resilience-challenge-scenarios.d.ts.map

package/dist/tools/challenge-spec/resilience-challenge-scenarios.js

@@ -1,35 +0,0 @@
-// tools/challenge-spec/resilience-challenge-scenarios.ts — SPEC-034
-// Barrel re-export for resilience/concurrency challenge scenarios.
-// Signal detectors + validation + cascade: resilience-challenge-scenarios-a.ts
-// Rate limit + concurrency + saga: resilience-challenge-scenarios-b.ts
-import { hasValidationSignal, hasExternalCallSignal, hasRateLimitSignal, hasConcurrencySignal, hasSagaSignal, generateValidationBoundaryScenarios, generateCascadeFailureScenarios, } from './resilience-challenge-scenarios-a.js';
-import { generateRateLimitBypassScenarios, generateConcurrencyScenarios, generateSagaFailureScenarios, } from './resilience-challenge-scenarios-b.js';
-export { EXTERNAL_CALL_KEYWORDS, VALIDATION_KEYWORDS, RATE_LIMIT_KEYWORDS, CONCURRENCY_KEYWORDS, SAGA_KEYWORDS, hasExternalCallSignal, hasValidationSignal, hasRateLimitSignal, hasConcurrencySignal, hasSagaSignal, generateValidationBoundaryScenarios, generateCascadeFailureScenarios, } from './resilience-challenge-scenarios-a.js';
-export { generateRateLimitBypassScenarios, generateConcurrencyScenarios, generateSagaFailureScenarios, } from './resilience-challenge-scenarios-b.js';
-/**
- * Main entry: generate all SPEC-034 resilience/concurrency challenges for a spec.
- */
-export function generateResilienceChallengeScenarios(spec, specContent, knowledge) {
-    const scenarios = [];
-    if (hasValidationSignal(spec, specContent)) {
-        scenarios.push(...generateValidationBoundaryScenarios(spec));
-    }
-    if (hasExternalCallSignal(spec, specContent)) {
-        scenarios.push(...generateCascadeFailureScenarios(spec));
-    }
-    if (hasRateLimitSignal(spec, specContent)) {
-        scenarios.push(...generateRateLimitBypassScenarios(spec));
-    }
-    if (hasConcurrencySignal(spec, specContent)) {
-        // `concurrencyModel` may be present on enriched knowledge objects (ValidationResilienceProfile mixin)
-        // but is not declared on the base ProjectKnowledge interface — intentional duck-type access.
-        // ProjectKnowledge has no index signature, so `as unknown` intermediate is required.
-        const concurrencyModel = knowledge.concurrencyModel;
-        scenarios.push(...generateConcurrencyScenarios(spec, concurrencyModel ?? 'unknown'));
-    }
-    if (hasSagaSignal(spec, specContent)) {
-        scenarios.push(...generateSagaFailureScenarios(spec));
-    }
-    return scenarios;
-}
-//# sourceMappingURL=resilience-challenge-scenarios.js.map

package/dist/tools/challenge-spec/scenarios-data.d.ts

@@ -1,3 +0,0 @@
-import type { FailureScenario, Spec, ProjectKnowledge } from '../../types/index.js';
-export declare function generateDataConsistencyScenarios(_spec: Spec, content: string, _knowledge: ProjectKnowledge): FailureScenario[];
-//# sourceMappingURL=scenarios-data.d.ts.map

package/dist/tools/challenge-spec/scenarios-data.js

@@ -1,52 +0,0 @@
-// tools/challenge-spec/scenarios-data.ts — Data consistency and partial write scenarios
-import { contentMentions } from './scenarios-utils.js';
-export function generateDataConsistencyScenarios(_spec, content, _knowledge) {
-    const scenarios = [];
-    const lower = content.toLowerCase();
-    // Partial writes
-    if (lower.includes('transaction') ||
-        lower.includes('update') ||
-        lower.includes('create') ||
-        lower.includes('modify') ||
-        lower.includes('save')) {
-        scenarios.push({
-            scenario: 'Partial write: server crashes mid-transaction',
-            probability: 'low',
-            impact: 'critical',
-            currentHandling: contentMentions(lower, ['transaction', 'atomic', 'rollback'])
-                ? 'Transactions mentioned'
-                : 'Not addressed',
-            requiredHandling: 'Wrap multi-step writes in database transactions. Implement saga pattern for distributed operations.',
-            dataConsistency: 'ACID properties must be maintained. No orphaned records.',
-            userExperience: 'Transparent: user sees either success or clean failure with clear error message.',
-        });
-    }
-    // Stale data
-    if (lower.includes('cache') || lower.includes('real-time') || lower.includes('concurrent')) {
-        scenarios.push({
-            scenario: 'Stale data served from cache after underlying data changes',
-            probability: 'high',
-            impact: 'medium',
-            currentHandling: contentMentions(lower, ['invalidat', 'ttl', 'websocket', 'real-time'])
-                ? 'Some cache strategy mentioned'
-                : 'Not addressed',
-            requiredHandling: 'Implement cache invalidation on writes. Use TTL for time-sensitive data. Consider event-driven invalidation.',
-            dataConsistency: 'Define acceptable staleness window per data type. Document cache strategy.',
-            userExperience: 'Show "last updated" timestamp. Offer manual refresh option.',
-        });
-    }
-    // Duplicate operations
-    scenarios.push({
-        scenario: 'User double-clicks submit, causing duplicate records',
-        probability: 'high',
-        impact: 'medium',
-        currentHandling: contentMentions(lower, ['idempoten', 'debounce', 'disable', 'lock'])
-            ? 'Some prevention mentioned'
-            : 'Not addressed',
-        requiredHandling: 'Implement idempotency keys for mutations. Disable submit button on click. Use unique constraints in DB.',
-        dataConsistency: 'No duplicate records from repeated submissions.',
-        userExperience: 'Button disabled during submission. Clear success/error feedback.',
-    });
-    return scenarios;
-}
-//# sourceMappingURL=scenarios-data.js.map

package/dist/tools/challenge-spec/scenarios-desktop.d.ts

@@ -1,7 +0,0 @@
-import type { FailureScenario, Spec, ProjectKnowledge } from '../../types/index.js';
-/**
- * Generate desktop auto-update edge case scenarios.
- * Covers interrupted download, permission issues, version regression, update during close.
- */
-export declare function generateDesktopAutoUpdateChallenges(_spec: Spec, specContent: string, knowledge: ProjectKnowledge): FailureScenario[];
-//# sourceMappingURL=scenarios-desktop.d.ts.map

package/dist/tools/challenge-spec/scenarios-desktop.js

@@ -1,86 +0,0 @@
-// tools/challenge-spec/scenarios-desktop.ts — Desktop auto-update edge case scenarios
-// SPEC-014b: interrupted download, permission issues, version regression, update during close.
-import { contentMentions } from './scenarios-utils.js';
-/**
- * Generate desktop auto-update edge case scenarios.
- * Covers interrupted download, permission issues, version regression, update during close.
- */
-export function generateDesktopAutoUpdateChallenges(_spec, specContent, knowledge) {
-    const lower = specContent.toLowerCase();
-    const isDesktop = knowledge.projectCategory === 'desktop' ||
-        contentMentions(lower, ['electron', 'tauri', 'auto-update', 'autoupdate', 'electron-updater']);
-    if (!isDesktop) {
-        return [];
-    }
-    const hasUpdateMention = contentMentions(lower, [
-        'update',
-        'electron-updater',
-        'autoUpdater',
-        'tauri updater',
-    ]);
-    if (!hasUpdateMention) {
-        return [];
-    }
-    const scenarios = [];
-    scenarios.push({
-        scenario: 'User interrupts update download (kills app mid-download)',
-        probability: 'medium',
-        impact: 'medium',
-        currentHandling: contentMentions(lower, ['resume', 'partial', 'checksum'])
-            ? 'Partially addressed in spec'
-            : 'Not addressed in spec',
-        requiredHandling: 'Implement resumable downloads with byte-range HTTP requests. ' +
-            'Store partial download with progress marker. ' +
-            'Verify checksum before applying. ' +
-            'Clean up partial file if user cancels.',
-        dataConsistency: 'Trigger: User force-quits during 40% downloaded update. App must launch normally without applying partial update.',
-        userExperience: 'On next launch, offer to resume download or start fresh. Show clear progress.',
-    });
-    scenarios.push({
-        scenario: 'Installer lacks write permissions (e.g., system-wide install vs user install)',
-        probability: 'medium',
-        impact: 'high',
-        currentHandling: contentMentions(lower, ['permission', 'admin', 'elevation', 'uac'])
-            ? 'Permissions partially addressed'
-            : 'Not addressed',
-        requiredHandling: 'Detect permission level before installing. ' +
-            'Windows: request UAC elevation for system-wide, or use per-user installation path. ' +
-            'macOS: install to ~/Applications if /Applications is read-only. ' +
-            'Linux: use user-local AppImage fallback.',
-        dataConsistency: 'Trigger: App installed in Program Files (requires admin) but updater runs without elevation.',
-        userExperience: 'Show clear error: "Update requires administrator permission. Click here to retry with elevated rights."',
-    });
-    scenarios.push({
-        scenario: 'Server version is older than installed version (rollback scenario)',
-        probability: 'low',
-        impact: 'high',
-        currentHandling: contentMentions(lower, ['version check', 'semver', 'downgrade'])
-            ? 'Version comparison mentioned'
-            : 'Not addressed',
-        requiredHandling: 'Compare semver strictly: server.version <= installed.version → skip update. ' +
-            'Log and report version mismatch to monitoring. ' +
-            'Never downgrade silently. ' +
-            'Add configurable allowDowngrade flag for emergency rollbacks.',
-        dataConsistency: 'Trigger: Rollback deployment pushes v1.0.0 while users have v1.1.0 installed. ' +
-            'Data format may be forward-compatible only.',
-        userExperience: 'Do not notify user about "update" when none is available. Silent version check.',
-    });
-    scenarios.push({
-        scenario: 'User closes app while update is being applied (installer running)',
-        probability: 'medium',
-        impact: 'critical',
-        currentHandling: contentMentions(lower, ['pending', 'restart', 'apply on quit'])
-            ? 'Restart handling mentioned'
-            : 'Not addressed',
-        requiredHandling: 'Defer update application to app quit event. ' +
-            'Use electron-updater `autoUpdater.on("update-downloaded")` → install on quit. ' +
-            'Prevent force-quit during NSIS/MSI installer phase. ' +
-            'On next launch, detect interrupted install and prompt clean reinstall.',
-        dataConsistency: 'Trigger: NSIS installer replaces DLLs while app is writing to local database. ' +
-            'Half-replaced binaries can corrupt user data.',
-        userExperience: 'Show progress overlay during critical install phase. ' +
-            'Offer "Update and Restart Now" vs "Update on Next Launch".',
-    });
-    return scenarios;
-}
-//# sourceMappingURL=scenarios-desktop.js.map

package/dist/tools/challenge-spec/scenarios-failure.d.ts

@@ -1,3 +0,0 @@
-import type { FailureScenario, Spec, ProjectKnowledge } from '../../types/index.js';
-export declare function generateFailureScenarios(spec: Spec, content: string, _knowledge: ProjectKnowledge): FailureScenario[];
-//# sourceMappingURL=scenarios-failure.d.ts.map