mindforge-cc 10.0.2 → 10.7.0

package/.mindforge/skills/saas-multi-tenant/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: saas-multi-tenant
+version: 1.0.0
+min_mindforge_version: 10.2.0
+status: stable
+triggers: saas architecture, tenant management, saas billing integration, feature gating saas, white-label platform, saas onboarding, subscription management saas, saas platform design, saas tenant provisioning, usage-based billing, saas data isolation, self-serve saas
+compose: multi-tenancy-patterns
+---
+
+# Skill — SaaS Multi-Tenant
+
+## When this skill activates
+This skill activates when building multi-tenant SaaS platforms with tenant isolation, subscription billing, feature gating, white-labeling, self-serve onboarding, usage-based pricing, tenant provisioning, or plan management systems.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Design tenant isolation strategy: shared database with tenant_id column (row-level security), schema-per-tenant (PostgreSQL schemas), or database-per-tenant (highest isolation, highest cost), with cross-tenant query prevention (middleware validation, prepared statement parameterization)
+2. Model subscription lifecycle: trial start (14 days) → active paid (credit card charged) → past_due (payment failed, retry 3 times) → canceled (end of billing period) → deleted (30 days after cancel), with state machine transitions and webhook events for each stage
+3. Map feature entitlements by plan: free tier (5 users, 100 MB storage, core features), starter ($29/mo, 25 users, 10 GB, email support), professional ($99/mo, unlimited users, 100 GB, priority support, advanced analytics), enterprise (custom pricing, SSO, SLA, dedicated support)
+
+### During implementation
+- Implement tenant context middleware: extract tenant_id from subdomain (acme.platform.com) or custom domain (app.acme.com with CNAME validation), JWT claims, or API key, inject into request context, validate tenant active (not suspended/deleted), apply row-level security filter (tenant_id = :current_tenant)
+- Build feature gating system: define feature flags per plan (analytics_enabled, sso_enabled, api_access_enabled), check entitlements at runtime (before rendering UI, before API execution), return 402 Payment Required for gated features, track usage for upsell prompts
+- Design usage-based billing: meter events (API calls, emails sent, storage used), aggregate per billing period, calculate overage charges (tiered pricing: $0.10/GB for 0-100GB, $0.05/GB for 100GB+), generate invoices (line items with metered usage), integrate with Stripe Billing or Chargebee
+- Implement white-labeling: support custom domains (validate CNAME ownership via DNS TXT record), customizable branding (logo, colors, fonts stored per tenant), email templates (replace platform name with tenant name), remove "Powered by" footer on enterprise plans
+- Build self-serve onboarding: signup flow (email verification, password strength requirements), organization creation (unique subdomain validation), plan selection (trial vs paid), payment method capture (tokenized card via Stripe Elements), provision tenant resources (create schema/database, seed default data)
+
+### After implementation
+- Validate tenant isolation: attempt cross-tenant data access (user from tenant A trying to access tenant B data via direct ID manipulation), verify middleware rejects requests, check database queries include tenant_id filter, audit all raw SQL for missing tenant scoping
+- Test billing accuracy: simulate monthly billing cycle, verify usage metering (events counted correctly), overage calculation (tiered pricing applied), invoice generation (correct line items, tax applied), payment processing (Stripe webhook handled), and dunning (retry failed payments, send reminders)
+- Execute load testing with tenant skew: simulate 100 tenants with 90% traffic on top 10 tenants (power law distribution), measure query performance (ensure indexes on tenant_id), identify noisy neighbor issues (one tenant's load impacting others), validate rate limiting per tenant
+
+## Self-check before task completion
+- [ ] Tenant isolation enforced: middleware extracts and validates tenant context, all queries scoped to tenant_id, cross-tenant access prevented
+- [ ] Subscription lifecycle managed: trial → active → past_due → canceled states with webhook events, dunning for failed payments
+- [ ] Feature gating functional: entitlements defined per plan, runtime checks before UI/API, 402 response for gated features, upsell prompts
+- [ ] Usage-based billing: metered events tracked, aggregated per billing period, overage charges calculated (tiered pricing), invoices generated
+- [ ] White-labeling supported: custom domains (CNAME validation), branding per tenant (logo, colors), email templates (tenant-specific)
+- [ ] Self-serve onboarding: signup flow, plan selection, payment capture (tokenized), tenant provisioning (schema/database creation)
+- [ ] Rate limiting per tenant: prevent noisy neighbors, ensure fair resource allocation, alert when tenant exceeds plan limits

package/.mindforge/skills/santa-method/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: santa-method
+version: 1.0.0
+min_mindforge_version: 10.0.4
+status: stable
+triggers: santa, multi-angle verification, independent review, convergence, AND gate, double-check, dual review, parallel verification, cross-verification, rubric scoring, multi-reviewer, batch sampling
+compose:
+  - verification-loop
+---
+
+# Skill — Santa Method (Multi-Angle Independent Verification)
+
+## When this skill activates
+After any significant implementation, before shipping, or whenever author-bias
+is suspected. Use when a single reviewer perspective is insufficient to guarantee
+correctness — the Santa Method ensures two independent reviewers reach the same
+conclusion without cross-contamination.
+
+Named after the "making a list, checking it twice" principle: one pass is never enough
+for high-stakes outputs.
+
+## Mandatory actions when this skill is active
+
+### Before review begins
+
+1. **Identify the artifact under review** — code diff, architecture doc, API design, or generated output.
+2. **Define the review rubric** — establish 3-7 criteria with clear pass/fail definitions before spawning reviewers.
+3. **Prepare sanitized context packets** — each reviewer gets ONLY:
+   - The artifact itself
+   - The acceptance criteria / rubric
+   - Relevant domain context (docs, types, schemas)
+   - NO access to the other reviewer's notes, findings, or verdict
+4. **Select reviewer perspectives** — choose complementary angles:
+   - Reviewer A: Correctness & Logic (does it do what it claims?)
+   - Reviewer B: Robustness & Edge Cases (what breaks it?)
+   - Alternative pairs: Security/Functionality, UX/Architecture, Performance/Maintainability
+
+### During review (parallel execution)
+
+**Context Isolation Protocol:**
+- Reviewer A and Reviewer B operate in separate reasoning contexts
+- Neither reviewer sees the other's output until both have submitted
+- If using sub-agents: spawn as independent tasks with no shared state
+- If single-agent: complete Reviewer A's full assessment, seal it, then begin Reviewer B fresh
+
+**Each reviewer MUST produce structured JSON output:**
+```json
+{
+  "reviewer": "A",
+  "perspective": "Correctness & Logic",
+  "verdict": "PASS" | "FAIL" | "CONDITIONAL",
+  "confidence": 0.0-1.0,
+  "findings": [
+    {
+      "criterion": "string",
+      "score": 1-5,
+      "evidence": "specific line/section reference",
+      "severity": "critical" | "major" | "minor" | "info"
+    }
+  ],
+  "blocking_issues": [],
+  "summary": "one-paragraph assessment"
+}
+```
+
+**AND Gate Logic (non-negotiable):**
+- PASS requires: Reviewer A = PASS **AND** Reviewer B = PASS
+- If EITHER reviewer returns FAIL → overall verdict is FAIL
+- If EITHER reviewer returns CONDITIONAL → enter convergence loop
+- This is an AND gate, never an OR gate — both must independently agree
+
+**Batch Sampling (for large outputs):**
+- If the artifact exceeds 500 lines or 20 logical units:
+  - Sample 10-15% of units for full santa review (random + targeted selection)
+  - Targeted selection: always include security-sensitive, complex, and high-change-rate sections
+  - If sampled sections fail: expand review to 30% or full artifact
+  - Document which sections were sampled and which were skipped
+
+### After review (convergence and resolution)
+
+**If both reviewers PASS:**
+- Record combined verdict as PASS
+- Merge findings into unified report
+- Log to `.mindforge/reviews/santa-[timestamp].json`
+
+**If disagreement (convergence loop):**
+1. Identify the specific criteria where reviewers diverge
+2. Narrow scope to ONLY the disputed items
+3. Re-evaluate disputed items with additional context (both reviewers now see each other's evidence for disputed items ONLY)
+4. Round 2 verdict: apply AND gate again
+5. If still disagreeing after Round 2: escalate to human decision with both perspectives presented
+6. Maximum 2 convergence rounds — never infinite loops
+
+**Convergence rules:**
+- Round 1: Independent review (no cross-contamination)
+- Round 2: Targeted re-review of disputed items only (both see each other's evidence)
+- Round 3: NEVER — escalate to human if Round 2 fails
+- Each round narrows scope (never broadens)
+
+### Output format
+
+Final santa review report:
+```json
+{
+  "method": "santa-method",
+  "artifact": "description of what was reviewed",
+  "timestamp": "ISO-8601",
+  "reviewer_a": { /* full reviewer output */ },
+  "reviewer_b": { /* full reviewer output */ },
+  "and_gate_result": "PASS" | "FAIL" | "ESCALATED",
+  "convergence_rounds": 0-2,
+  "disputed_items": [],
+  "final_verdict": "PASS" | "FAIL" | "ESCALATED",
+  "batch_sampling": {
+    "total_units": 0,
+    "sampled_units": 0,
+    "sampling_percentage": 0.0,
+    "sampling_strategy": "random+targeted"
+  }
+}
+```
+
+## Self-check before task completion
+
+Before marking a task done when this skill was active:
+
+- [ ] Did both reviewers have fully isolated context? (No cross-contamination)
+- [ ] Did I apply the AND gate strictly? (Both must PASS, not just one)
+- [ ] Were reviewer perspectives complementary, not redundant?
+- [ ] Was convergence attempted on disagreement (max 2 rounds)?
+- [ ] For large artifacts, was batch sampling applied (10-15%)?
+- [ ] Was the rubric defined BEFORE review began?
+- [ ] Is the final verdict supported by evidence from both reviewers?
+- [ ] Was the review output stored in structured JSON format?

package/.mindforge/skills/search-implementation/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: search-implementation
+version: 1.0.0
+min_mindforge_version: 10.0.7
+status: stable
+triggers: search implementation, full text search design, vector search architecture, hybrid search fusion, ranking algorithm design, BM25 tuning, semantic search pipeline, faceted search design, autocomplete implementation, inverted index design, search relevance tuning, search engine architecture
+---
+
+# Search Implementation
+
+## When this skill activates
+
+This skill activates when the user is designing, implementing, or optimizing search
+functionality. This includes full-text search with inverted indexes, vector/semantic
+search with embeddings, hybrid search fusion (combining BM25 + vector), ranking
+algorithm design, faceted search, autocomplete/typeahead implementation, relevance
+tuning, and search infrastructure architecture decisions.
+
+## Mandatory actions
+
+### Before
+
+1. Identify the search use case (product catalog, document search, knowledge base, logs, code search).
+2. Determine data volume and growth rate (affects index strategy and infrastructure).
+3. Assess query patterns (keyword, natural language, filtered, faceted, autocomplete).
+4. Identify relevance requirements (precision vs recall trade-off for the use case).
+5. Review existing data pipeline and determine indexing latency tolerance (real-time vs batch).
+
+### During
+
+**Full-Text Search (Lexical):**
+- **Inverted Index:** Maps terms to document lists with positions. Foundation of all text search.
+- **BM25 Scoring:** Ranks by term frequency (TF), inverse document frequency (IDF), and document length normalization. The standard baseline for lexical relevance.
+- **Analysis Pipeline:** Tokenization → lowercasing → stemming/lemmatization → stopword removal. Customize per language.
+- **Field Boosting:** Weight title matches higher than body matches (title^3, body^1).
+- **Phrase Matching:** Preserve term proximity for multi-word queries.
+- Use Elasticsearch, OpenSearch, Solr, or PostgreSQL full-text for lexical search.
+
+**Vector Search (Semantic):**
+- **Embedding:** Convert queries and documents into dense vectors (768-1536 dimensions). Use sentence-transformers, OpenAI embeddings, or Cohere embed.
+- **Similarity:** Cosine similarity or dot product between query vector and document vectors.
+- **ANN Indexes:** Approximate Nearest Neighbor for sub-linear search. HNSW (best recall/speed trade-off), IVF (better for very large datasets), ScaNN.
+- **Chunking:** Split long documents into passages (256-512 tokens) before embedding. Overlap chunks by 10-20%.
+- Use Qdrant, Pinecone, Weaviate, pgvector, or Elasticsearch kNN for vector search.
+
+**Hybrid Search (Fusion):**
+- **Reciprocal Rank Fusion (RRF):** Merge BM25 and vector result lists. Score = sum(1 / (k + rank)) across both lists. k=60 is a common default.
+- **Linear Combination:** Normalize scores from each system and combine with weights (alpha * BM25 + (1-alpha) * vector). Tune alpha per use case.
+- Hybrid outperforms either alone for most use cases (lexical catches exact matches, semantic catches intent).
+- Run both searches in parallel, fuse results, then apply final re-ranking.
+
+**Faceted Search:**
+- Pre-compute aggregations per field (category, price range, brand, rating).
+- Return facet counts alongside search results for filter UI.
+- Apply filters BEFORE computing facets (post-filter facets confuse users).
+- Use bucket aggregations (terms, range, date histogram) in search engines.
+- Optimize with doc_values for facetable fields.
+
+**Autocomplete:**
+- **Prefix matching:** Trie data structure or edge n-gram tokenizer (index "search" as "s", "se", "sea", "sear", "searc", "search").
+- **Popularity weighting:** Boost suggestions by query frequency or click-through rate.
+- **Fuzzy matching:** Tolerate typos with edit distance (Levenshtein distance <= 2).
+- **Contextual suggestions:** Use recent user behavior to personalize completions.
+- Target response time: < 100ms for autocomplete (users expect instant feedback).
+
+**Relevance Tuning:**
+- **Field boosting:** Prioritize title > tags > body matches.
+- **Recency decay:** Score newer documents higher (exponential decay function).
+- **Popularity signals:** Boost by click-through rate, view count, or purchase frequency.
+- **User behavior:** Learn from clicks (Learning to Rank — LTR models).
+- **A/B testing:** Measure relevance changes with online metrics (click-through, session success).
+- Use NDCG (Normalized Discounted Cumulative Gain) as the offline relevance metric.
+
+**Architecture:**
+- Separate search index from primary database (search is a read-optimized view).
+- Async indexing pipeline: primary DB → change stream/CDC → transform → index.
+- Index latency SLA: define acceptable delay (real-time: <1s, near-real-time: <30s, batch: hours).
+- Replicate search indexes for availability and read throughput.
+- Monitor index lag, query latency (p50, p95, p99), and zero-result rate.
+
+### After
+
+1. Verify search returns relevant results for representative queries (spot-check top 10).
+2. Confirm indexing pipeline is running and latency is within SLA.
+3. Validate autocomplete responds within 100ms target.
+4. Check facet counts are accurate and filters work correctly.
+5. Measure zero-result rate and establish baseline relevance metrics (NDCG).
+
+## Self-check before task completion
+
+- [ ] Search type is appropriate for the use case (lexical, vector, hybrid).
+- [ ] Inverted index analysis pipeline is configured for the content language.
+- [ ] Vector embeddings use an appropriate model and chunk size.
+- [ ] Hybrid fusion strategy (RRF or linear combination) is implemented if both systems are used.
+- [ ] Autocomplete targets < 100ms latency with typo tolerance.
+- [ ] Relevance tuning includes field boosting and recency/popularity signals.
+- [ ] Search index is separate from primary DB with async indexing pipeline.
+- [ ] Monitoring covers query latency, index lag, and zero-result rate.

package/.mindforge/skills/secrets-platform/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: secrets-platform
+version: 1.0.0
+min_mindforge_version: 10.7.0
+status: stable
+triggers: secrets management platform, secret rotation automation, secret access auditing, secret sprawl prevention, vault architecture, secrets lifecycle, dynamic secret generation, secret injection pattern, secrets governance, secret scanning platform, certificate management, secrets policy enforcement
+compose: secrets-rotation
+---
+
+# Skill — Secrets Platform
+
+## When this skill activates
+
+This skill activates when the user is designing or implementing a centralized secrets management platform. This includes secret rotation automation, access auditing, secret sprawl prevention, Vault architecture, secrets lifecycle management, dynamic secret generation, secret injection patterns, secrets governance, secret scanning, certificate management, and secrets policy enforcement.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+
+1. Audit current secret storage locations: code repos, config files, environment variables, CI/CD systems, container images, config management tools. Quantify secret sprawl.
+2. Identify secret types: API keys, database credentials, TLS certificates, OAuth tokens, encryption keys, SSH keys. Each type has different rotation requirements.
+3. Define secret access policies: which teams/services can access which secrets. Use principle of least privilege (default deny, explicit allow).
+4. Establish secret rotation requirements: compliance mandates (PCI DSS, SOC 2), blast radius reduction, credential age limits.
+5. Assess current secret rotation toil: how many hours per month spent manually rotating secrets.
+
+### During implementation
+
+- **Centralized Secret Store:** Use HashiCorp Vault, AWS Secrets Manager, or GCP Secret Manager. Never store secrets in code, config files, or environment variables. Secrets should be encrypted at rest and in transit.
+- **Secret Rotation Automation:** Automate rotation for database credentials, API keys, and TLS certificates. High-sensitivity secrets (production database) rotate every 30 days. Low-sensitivity (dev sandbox API keys) rotate every 90 days. Rotation should be zero-downtime (dual-write during rotation window).
+- **Dynamic Secret Generation:** For databases, generate short-lived credentials on-demand (Vault database secrets engine). Credentials should expire after 1-8 hours. Reduces blast radius if credentials leak.
+- **Secret Injection Patterns:** Inject secrets at runtime, not build time. Use init containers (Kubernetes), sidecar containers (Vault Agent), or secret CSI drivers. Secrets should never be in container images.
+- **Access Auditing:** Log every secret access (who, what, when, from where). Audit logs must be immutable and retained for 1+ year. Alert on unusual access patterns (access from new IP, high-frequency access, access to secrets outside normal scope).
+- **Secret Sprawl Prevention:** Use secret scanning in CI/CD (Trufflehog, GitGuardian, GitHub Secret Scanning). Block commits containing secrets. Scan existing repos and remediate found secrets (rotate + remove from history).
+- **Certificate Management:** Automate TLS certificate issuance (Let's Encrypt, cert-manager) and renewal (30 days before expiry). Track certificate expiration dates and alert 60 days before expiry.
+- **Secrets Policy Enforcement:** Use policy-as-code (OPA, Vault policies) to enforce: maximum credential age, minimum rotation frequency, required encryption strength, allowed access patterns. Policies should fail-closed (deny by default).
+- **Emergency Access (Break-Glass):** Provide mechanism for emergency access to secrets when automation fails. Requires: approval workflow, audit trail, automatic expiration (4-8 hours), post-incident review.
+
+### After implementation
+
+- Verify all production secrets are migrated to centralized secret store (zero secrets in code/config).
+- Confirm secret rotation is automated and zero-downtime for critical credentials.
+- Validate secret injection happens at runtime with no secrets in container images.
+- Ensure access auditing logs every secret access with retention of 1+ year.
+- Check that secret scanning blocks commits containing secrets in CI/CD.
+
+## Self-check before task completion
+
+- [ ] All production secrets are stored in centralized secret store (Vault, Secrets Manager).
+- [ ] Secret rotation is automated for credentials and certificates with zero-downtime.
+- [ ] Dynamic secrets are used for databases with 1-8 hour expiration.
+- [ ] Secret injection happens at runtime via init containers, sidecars, or CSI drivers.
+- [ ] Access auditing logs every secret access with immutable logs retained for 1+ year.
+- [ ] Secret scanning is enabled in CI/CD and blocks commits containing secrets.
+- [ ] Certificate management automates issuance and renewal with alerts 60 days before expiry.
+- [ ] Secrets policy enforcement uses policy-as-code and fails closed (deny by default).
+- [ ] Emergency access (break-glass) requires approval, audit trail, and auto-expiration.

package/.mindforge/skills/secrets-rotation/SKILL.md

@@ -0,0 +1,173 @@
+---
+name: secrets-rotation
+version: 1.0.0
+min_mindforge_version: 0.1.0
+status: stable
+compose: security-review
+triggers: secrets rotation, automated rotation, zero downtime rollover, vault pattern, ephemeral credentials, lease management, key rotation, credential lifecycle, rotation schedule, secret versioning, rotation verification, dual key period
+---
+
+# Skill — Secrets Rotation
+
+## When this skill activates
+Any task involving secrets rotation implementation, credential lifecycle
+management, zero-downtime key rollover, or Vault/secrets manager configuration.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Inventory all secrets that need rotation (API keys, DB creds, tokens).
+2. Define the rotation schedule based on secret sensitivity.
+3. Design the dual-key period for zero-downtime rollover.
+
+### During implementation
+- Implement dual-key period (new key active, old key valid during grace period).
+- Ensure applications read "current" version pointer, not hardcoded versions.
+- Add rotation verification (test new cred works, verify old cred rejected after grace).
+
+### After implementation
+- Set up automated rotation on schedule.
+- Add alerts for rotation failures.
+- Document rotation procedures in ARCHITECTURE.md (for manual emergency rotation).
+
+## Dual-Key Period (Zero-Downtime Rollover)
+
+### Pattern
+```
+Time 0:    key_v1 = active, key_v2 = not yet created
+Time 1:    key_v2 = created, key_v1 = still active (grace period starts)
+Time 2:    key_v2 = active (apps switch), key_v1 = still valid (grace)
+Time 3:    key_v1 = revoked (grace period ends)
+```
+
+### Why Dual-Key
+- Applications may cache the old key.
+- Distributed systems need time to propagate the new key.
+- Rolling deployments mean some instances have new key, some have old.
+- Grace period ensures no request fails during transition.
+
+### Grace Period Duration
+| Secret Type | Grace Period | Rationale |
+|------------|-------------|-----------|
+| API keys (external) | 24 hours | Client applications need time to update |
+| Database credentials | 1 hour | Internal, fast propagation |
+| JWT signing keys | 2x token lifetime | Existing tokens must remain valid |
+| TLS certificates | 24 hours | DNS/CDN propagation time |
+
+## Automated Rotation
+
+### HashiCorp Vault Dynamic Secrets
+- Vault generates credentials on demand.
+- Credentials have TTL (lease), auto-expire.
+- No manual rotation needed — secrets are ephemeral.
+- Revocation: revoke lease, credential immediately invalid.
+
+### AWS Secrets Manager Rotation
+- Lambda function triggered on rotation schedule.
+- Creates new credential, tests it, updates "current" pointer.
+- Previous version remains valid during staging period.
+- Automatic rollback if new credential fails validation.
+
+### Custom Rotation Script Pattern
+```
+1. Generate new credential
+2. Store as "pending" version
+3. Test "pending" credential works (connect, query, etc.)
+4. Promote "pending" to "current"
+5. Demote old "current" to "previous" (grace period)
+6. After grace period: delete "previous"
+7. Alert on any failure at any step
+```
+
+## Zero-Downtime Application Pattern
+
+### Application Reads "Current" Pointer
+```
+Application → Secrets Manager → "current" version → actual credential
+```
+
+- Application never stores credential — fetches on each use (with cache TTL).
+- On rotation: "current" pointer updated atomically.
+- Application's next fetch gets new credential automatically.
+- Cache TTL should be shorter than grace period.
+
+### Connection Pool Refresh
+- After rotation: drain old connections, create new with new credential.
+- Graceful: new connections use new cred, old connections finish naturally.
+- Timeout: force-close old connections after grace period.
+
+## Ephemeral Credentials
+
+### Concept
+- Short-lived credentials that auto-expire (minutes to hours).
+- No rotation needed — credential dies before it could be compromised.
+- Vault dynamic secrets, AWS STS temporary credentials, K8s service account tokens.
+
+### When to Use Ephemeral
+- Service-to-service communication.
+- CI/CD pipeline credentials.
+- Developer access to production systems.
+- Any scenario where rotation overhead is high.
+
+### When NOT to Use Ephemeral
+- External integrations that can't handle credential refresh.
+- Embedded devices with limited connectivity.
+- Systems where credential fetch latency is unacceptable.
+
+## Rotation Schedule
+
+| Secret Type | Rotation Frequency | Rationale |
+|------------|-------------------|-----------|
+| Database passwords | 90 days | Balance security vs operational risk |
+| API keys (internal) | 30 days | Higher rotation, lower blast radius |
+| API keys (external) | 90-180 days | Coordination with partners needed |
+| JWT signing keys | 90 days | Must outlive longest token lifetime |
+| TLS certificates | 60 days (Let's Encrypt auto) | Short-lived, automated |
+| Encryption keys | 365 days | Key material rarely exposed |
+| Compromised secrets | IMMEDIATELY | Zero tolerance for known compromise |
+
+## Rotation Verification
+
+### Post-Rotation Checks
+1. **New credential works**: attempt connection/API call with new credential.
+2. **Old credential rejected** (after grace): verify old credential fails.
+3. **Application health**: check error rates didn't spike during rotation.
+4. **Audit log**: verify rotation event logged with timestamp and actor.
+
+### Failure Handling
+- If new credential fails validation: abort, keep old credential, alert.
+- If application errors spike after rotation: rollback (reactivate old credential).
+- Never delete old credential until verified that new credential works everywhere.
+
+## Secret Versioning
+
+### Version Metadata
+```json
+{
+  "secret_id": "db-prod-password",
+  "version": 7,
+  "created_at": "2024-01-15T10:30:00Z",
+  "expires_at": "2024-04-15T10:30:00Z",
+  "status": "current",
+  "rotated_by": "automated-rotation-lambda",
+  "previous_version": 6
+}
+```
+
+### Version States
+- **pending**: newly created, being validated.
+- **current**: active version, used by applications.
+- **previous**: grace period, still valid but deprecated.
+- **revoked**: expired/rotated out, no longer valid.
+
+## Self-check before task completion
+
+Before marking a task done when this skill was active:
+
+- [ ] Did I read the full SKILL.md before starting? (Not just the triggers)
+- [ ] Is dual-key period implemented (no downtime during rotation)?
+- [ ] Does the application read "current" pointer (not hardcoded version)?
+- [ ] Is rotation verification implemented (new works, old eventually rejected)?
+- [ ] Is automated rotation on schedule (not manual)?
+- [ ] Are alerts configured for rotation failures?
+- [ ] Is emergency manual rotation procedure documented?

package/.mindforge/skills/self-serve-infrastructure/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: self-serve-infrastructure
+version: 1.0.0
+min_mindforge_version: 10.7.0
+status: stable
+triggers: self-serve infrastructure, infrastructure abstraction layer, team resource provisioning, resource quota management, infrastructure guardrail, infrastructure self-service, cloud account vending, environment provisioning, developer infrastructure, resource request automation, infrastructure API, sandbox environment
+---
+
+# Skill — Self-Serve Infrastructure
+
+## When this skill activates
+
+This skill activates when the user is designing or implementing self-service infrastructure capabilities. This includes building infrastructure abstraction layers, enabling team resource provisioning, managing resource quotas, implementing infrastructure guardrails, cloud account vending, environment provisioning, and infrastructure APIs that allow developers to request and manage infrastructure without manual approval workflows.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+
+1. Audit current infrastructure request workflows: identify bottlenecks, approval layers, and average time from request to provisioned resource.
+2. Define resource taxonomy (compute, storage, database, network, secrets) and ownership model (team-owned, platform-managed, shared).
+3. Establish cost budgets and quota policies per team and environment type (production vs non-production).
+4. Identify compliance requirements that must be enforced via policy-as-code (data residency, encryption, network isolation).
+5. Map out the guardrails that prevent misconfiguration while still enabling developer autonomy.
+
+### During implementation
+
+- **Infrastructure Abstraction Layer:** Hide cloud provider primitives behind domain-specific abstractions (e.g., "web service", "background worker", "database" instead of EC2/RDS/ECS). Abstractions should map to 80% of use cases; provide escape hatches for the 20%.
+- **Account Vending:** Automate AWS/GCP/Azure account creation with pre-configured networking, security groups, IAM roles, and cost monitoring. Vending should complete in under 10 minutes and include automatic tagging for cost attribution.
+- **Resource Quotas:** Enforce per-team quotas on compute, storage, and API calls. Quotas should be soft limits with alerts (80% threshold) and hard limits that block provisioning. Include self-service quota increase requests with auto-approval for small increases (20%).
+- **Guardrails (Policy-as-Code):** Use OPA, Sentinel, or Cloud Custodian to enforce rules: no public S3 buckets, require encryption, require tagging, enforce naming conventions, block expensive instance types in non-prod. Guardrails should fail-fast at provisioning time, not after resources are created.
+- **Environment Provisioning:** Enable one-click environment creation (dev, staging, prod, per-developer sandbox). Environments should be ephemeral for non-prod, with automatic cleanup after N days of inactivity. Include cost estimates before provisioning.
+- **Infrastructure API:** Expose infrastructure capabilities via REST or GraphQL API. Each endpoint should return a tracking ID for async provisioning, with status polling or webhooks. Include rate limiting and audit logging.
+- **Sandbox Safety:** Sandboxes should auto-delete after 7 days, have cost caps ($50-$200/month), and include network isolation from production. Developers should receive cost alerts at 50%, 80%, 100% of quota.
+
+### After implementation
+
+- Verify infrastructure provisioning time is reduced by at least 80% (from days to minutes).
+- Confirm guardrails prevent at least 90% of misconfiguration issues that previously required manual remediation.
+- Validate resource quotas are enforced and quota breach attempts are logged and alerted.
+- Ensure environment provisioning includes cost estimates and auto-cleanup for ephemeral environments.
+- Check that infrastructure API requests include tracking IDs and status endpoints for async operations.
+
+## Self-check before task completion
+
+- [ ] Infrastructure abstraction layer covers 80% of use cases with escape hatches for the rest.
+- [ ] Account vending completes in under 10 minutes with pre-configured security and networking.
+- [ ] Resource quotas are enforced with soft limits (alerts at 80%) and hard limits (block at 100%).
+- [ ] Guardrails use policy-as-code and fail at provisioning time, not post-creation.
+- [ ] Environment provisioning includes cost estimates and automatic cleanup policies.
+- [ ] Infrastructure API has async tracking, status polling, rate limiting, and audit logs.
+- [ ] Sandbox environments have cost caps, auto-deletion, and network isolation from production.