wicked-garden 12.27.0

package/skills/agentic/trust-and-safety/refs/safety-checklist-advanced.md

@@ -0,0 +1,209 @@
+---
+phase_relevance: ["design", "review"]
+archetype_relevance: ["*"]
+---
+# Safety Checklist: Advanced
+
+Advanced safety checklist covering monitoring, incident response, testing, and operational safety.
+
+## Monitoring & Observability
+
+### Logging
+
+- [ ] **Comprehensive audit logging**
+  - All agent decisions logged
+  - All actions logged
+  - User interactions logged
+
+- [ ] **Structured logging**
+  - JSON/structured format
+  - Consistent fields
+  - Correlation IDs
+
+- [ ] **Log retention policy**
+  - Retention period defined
+  - Compliance with regulations
+  - Secure log storage
+
+- [ ] **Sensitive data not logged**
+  - PII redacted from logs
+  - Credentials not logged
+  - Secrets not logged
+
+### Monitoring
+
+- [ ] **Real-time safety monitoring**
+  - Anomaly detection
+  - Unusual action patterns
+  - Spike in errors/failures
+
+- [ ] **Alerting configured**
+  - Critical safety events trigger alerts
+  - Alert routing to right team
+  - Alert escalation policies
+
+- [ ] **Dashboard for safety metrics**
+  - Safety violations over time
+  - Approval rates
+  - Error rates by type
+
+### Tracing
+
+- [ ] **Distributed tracing implemented**
+  - Request traced across agents
+  - Agent-to-agent calls traced
+  - External API calls traced
+
+- [ ] **Tracing includes safety context**
+  - Approval decisions in trace
+  - Validation failures in trace
+  - Safety gates in trace
+
+## Incident Response
+
+### Detection
+
+- [ ] **Incident detection mechanisms**
+  - Automated detection of safety violations
+  - Anomaly detection
+  - User reporting mechanism
+
+- [ ] **Incident classification**
+  - Severity levels defined
+  - Classification criteria
+  - Triage process
+
+### Response
+
+- [ ] **Incident response plan documented**
+  - Roles and responsibilities
+  - Communication plan
+  - Escalation procedures
+
+- [ ] **Kill switch mechanism**
+  - Emergency stop capability
+  - Clear activation criteria
+  - Alert on activation
+
+- [ ] **Rollback capability**
+  - Can revert problematic changes
+  - Rollback tested regularly
+  - Data backup for rollback
+
+### Recovery
+
+- [ ] **Post-incident review process**
+  - Root cause analysis
+  - Lessons learned documented
+  - Corrective actions tracked
+
+- [ ] **Incident documentation**
+  - Timeline of events
+  - Actions taken
+  - Impact assessment
+
+## Testing & Validation
+
+### Safety Testing
+
+- [ ] **Adversarial testing performed**
+  - Red team testing
+  - Prompt injection testing
+  - Jailbreak attempt testing
+
+- [ ] **Edge case testing**
+  - Invalid inputs
+  - Boundary conditions
+  - Race conditions
+
+- [ ] **Safety regression testing**
+  - Safety tests automated
+  - Run on every change
+  - No reduction in safety coverage
+
+### Validation
+
+- [ ] **Safety requirements documented**
+  - Clear safety specifications
+  - Acceptance criteria
+  - Success metrics
+
+- [ ] **Independent security review**
+  - External security assessment
+  - Penetration testing
+  - Code review for security
+
+## Operational Safety
+
+### Deployment
+
+- [ ] **Gradual rollout strategy**
+  - Canary deployments
+  - Percentage-based rollout
+  - Automatic rollback on errors
+
+- [ ] **Deployment gates**
+  - All tests pass
+  - Security scan clear
+  - Approval obtained
+
+### Runtime Safety
+
+- [ ] **Circuit breakers implemented**
+  - Prevent cascading failures
+  - Automatic recovery
+  - Alert on circuit open
+
+- [ ] **Rate limiting active**
+  - Per-user limits
+  - Per-agent limits
+  - Per-API limits
+
+- [ ] **Graceful degradation**
+  - Reduced functionality when components fail
+  - System remains safe in degraded mode
+  - User informed of degraded state
+
+### Continuous Improvement
+
+- [ ] **Safety metrics tracked**
+  - Violations per day/week
+  - False positive rate
+  - Response time to incidents
+
+- [ ] **Regular safety reviews**
+  - Quarterly safety audits
+  - Policy updates
+  - New threat assessment
+
+- [ ] **User feedback integration**
+  - Safety concerns from users tracked
+  - Feedback incorporated into improvements
+
+## Scoring Your System
+
+**Critical (must have):**
+- Input validation
+- Output validation
+- Action whitelisting
+- Human approval for high-stakes
+- Audit logging
+- Kill switch
+
+**Important (should have):**
+- PII detection/redaction
+- Resource limits
+- Circuit breakers
+- Rate limiting
+- Incident response plan
+
+**Nice to have:**
+- Advanced hallucination detection
+- ML-based anomaly detection
+- Automated adversarial testing
+
+**Minimum viable safety:** All critical items + 80% of important items
+
+**Production ready:** All critical, all important, 50% of nice-to-have
+
+**Best in class:** 100% of all items

package/skills/agentic/trust-and-safety/refs/safety-checklist-core.md

@@ -0,0 +1,215 @@
+---
+phase_relevance: ["design", "review"]
+archetype_relevance: ["*"]
+---
+# Safety Checklist: Core
+
+Use this checklist to assess core safety of agentic systems covering input, output, action, auth, and privacy.
+
+## Input Safety
+
+### User Input Validation
+
+- [ ] **Input sanitization implemented**
+  - Remove or escape dangerous characters
+  - Strip HTML/script tags if not needed
+  - Normalize unicode and encoding
+
+- [ ] **Input length limits enforced**
+  - Maximum input size defined
+  - Protection against DOS via large inputs
+  - Truncation or rejection of oversized inputs
+
+- [ ] **Prompt injection defenses active**
+  - Delimiter-based separation of instructions and data
+  - Pattern detection for injection attempts
+  - Monitoring for suspicious input patterns
+
+- [ ] **Content filtering applied**
+  - Profanity/offensive content detection
+  - Spam detection
+  - Malicious URL detection
+
+### Data Input Validation
+
+- [ ] **Schema validation on structured inputs**
+  - JSON/XML schema enforcement
+  - Type checking
+  - Required field validation
+
+- [ ] **Range validation on numeric inputs**
+  - Min/max bounds checking
+  - Validation of enumerated values
+  - Null/undefined handling
+
+- [ ] **File upload safety (if applicable)**
+  - File type whitelist
+  - File size limits
+  - Virus scanning
+  - Sandboxed file processing
+
+## Output Safety
+
+### Output Validation
+
+- [ ] **Structured output validation**
+  - Outputs conform to expected schema
+  - Pydantic/JSON Schema validation
+  - Required fields present
+
+- [ ] **Content safety checks**
+  - Offensive content detection
+  - Bias detection
+  - Harmful advice detection
+
+- [ ] **PII redaction**
+  - Email addresses redacted
+  - Phone numbers redacted
+  - SSN/credit cards redacted
+  - API keys/secrets redacted
+
+- [ ] **Hallucination detection**
+  - Confidence thresholds enforced
+  - Fact verification against known sources
+  - Citation requirements
+  - Multi-agent cross-validation
+
+### Output Handling
+
+- [ ] **Sensitive output protection**
+  - Encryption for sensitive data
+  - Secure transmission (HTTPS, etc.)
+  - Minimal logging of sensitive outputs
+
+- [ ] **Output rate limiting**
+  - Prevents information disclosure via repeated queries
+  - Protects against scraping
+
+## Action Safety
+
+### Pre-Action Validation
+
+- [ ] **Action whitelisting**
+  - Only allowed actions are executable
+  - Comprehensive whitelist defined
+  - Regular review of allowed actions
+
+- [ ] **Parameter validation**
+  - Action parameters validated
+  - SQL injection prevention
+  - Command injection prevention
+
+- [ ] **Dry-run capability**
+  - Can simulate actions without executing
+  - Preview of action consequences
+  - Rollback plan identified
+
+### Human-in-the-Loop
+
+- [ ] **High-stakes actions require approval**
+  - Production data modifications
+  - Financial transactions
+  - External communications
+  - Credential changes
+
+- [ ] **Approval workflow defined**
+  - Clear approval chain
+  - Timeout handling
+  - Escalation process
+  - Approval audit trail
+
+- [ ] **Approval UI/notification system**
+  - Approvers receive timely notifications
+  - Approvers can see full context
+  - Approval/denial is logged
+
+### Action Constraints
+
+- [ ] **Resource limits enforced**
+  - Maximum execution time
+  - Memory limits
+  - Token budget limits
+  - API call limits
+
+- [ ] **Scope restrictions**
+  - File system access limited
+  - Network access controlled
+  - Database access restricted
+  - API access scoped
+
+- [ ] **Reversibility considered**
+  - Rollback mechanism for critical actions
+  - Backups before destructive operations
+  - Audit trail for reversing actions
+
+## Authentication & Authorization
+
+### Identity Management
+
+- [ ] **User authentication required**
+  - Strong authentication mechanisms
+  - MFA for sensitive operations
+  - Session management
+
+- [ ] **Agent identity tracked**
+  - Each agent has unique ID
+  - Agent identity in all logs
+  - Attribution of actions to agents
+
+### Access Control
+
+- [ ] **Role-based access control (RBAC)**
+  - User roles defined
+  - Agent permissions per role
+  - Least privilege principle
+
+- [ ] **Permission scoping**
+  - Fine-grained permissions
+  - Time-bound permissions
+  - Context-dependent permissions
+
+- [ ] **Credential management**
+  - Secrets not in code
+  - Secret rotation policy
+  - Secure secret storage (vault, KMS)
+
+## Privacy & Compliance
+
+### PII Protection
+
+- [ ] **PII detection active**
+  - Pattern-based detection
+  - ML-based detection
+  - Context-aware detection
+
+- [ ] **PII minimization**
+  - Only collect necessary PII
+  - PII retention limits
+  - Anonymization when possible
+
+- [ ] **PII encryption**
+  - Encryption at rest
+  - Encryption in transit
+  - Key management
+
+### Compliance
+
+- [ ] **Regulatory requirements identified**
+  - GDPR, CCPA, HIPAA, etc.
+  - Industry-specific regulations
+  - Geographic regulations
+
+- [ ] **Data residency compliance**
+  - Data stored in correct regions
+  - Cross-border transfer controls
+  - Sovereignty requirements
+
+- [ ] **Right to deletion implemented**
+  - User can request data deletion
+  - Deletion verified across systems
+  - Deletion audit trail
+
+- [ ] **Consent management**
+  - User consent tracked
+  - Consent scope clearly defined
+  - Consent withdrawal mechanism

package/skills/archetype/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: wicked-garden-archetype
+context: fork
+description: |
+  v11 work-shape archetype runner. When a prompt has been routed to one
+  of the archetypes (triage, explore, specify, decide, ship, review,
+  incident, build, migrate, modernize), this skill is the entry point. It
+  picks the right per-archetype playbook from refs/ and executes the phase
+  shape declared in `.claude-plugin/archetypes.json`.
+
+  Use when: a `<wg archetype="X">` or `<wg archetypes>` system-reminder
+  tag appears, an explicit "let's run the X archetype" request, or
+  when one of the per-archetype slash commands resolves to this skill.
+allowed-tools: ["*"]
+---
+
+# /wicked-garden:archetype
+
+v11 entry point for **work-shape archetypes**. Each archetype is a complete
+unit with its own phase shape, produces, HITL discipline, and cost band.
+There is no universal pipeline.
+
+## When to use this skill
+
+Invoke when:
+- A `<wg archetype="X">` or `<wg archetypes>` system-reminder tag appears
+  (emitted by the v11 prompt hook).
+- The user explicitly asks to "run the {archetype} archetype" or "do this
+  as a {archetype}" workflow.
+- You're routing from `triage` to a real archetype after classifying the
+  work.
+
+Do **not** use this skill for:
+- Continuation tokens ("yes", "ok", "do it"). Those carry no new shape;
+  keep going on the current archetype.
+- Simple-edit work (typos, single-line fixes, cosmetic changes). The v11
+  hook already suppresses archetype tags on `simple-edit` intent.
+
+## The archetypes
+
+| Archetype | Phases                                                    | Produces                        | HITL                  |
+|-----------|-----------------------------------------------------------|---------------------------------|-----------------------|
+| triage    | classify                                                  | routing decision                | none                  |
+| explore   | frame → diverge → converge                                | option set / hypothesis         | continuous            |
+| specify   | elicit → structure → validate                             | SMART acceptance criteria       | discrete:validate     |
+| decide    | brief → options → score → record                          | ADR / decision artifact         | discrete:select       |
+| ship      | canary → ramp → full → soak                               | rollout verdict / SLO snapshot  | discrete:ramp         |
+| review    | scope → assess → findings → remediate-or-accept           | verdict / remediation list      | hard:final-verdict    |
+| incident  | triage → investigate → mitigate → resolve → followup      | mitigation / RCA / followup     | hard:mitigate         |
+| build     | plan → implement → test → review                          | shipped code / test report      | discrete:review       |
+| migrate   | plan → expand → backfill → cutover → contract             | shape change / rollback proof   | hard:cutover          |
+| modernize | discover → extract → blueprint → transform → parity → cutover | modernization blueprint / parity proof | hard:cutover  |
+
+## Procedure
+
+1. **Identify the archetype.** Read the `<wg archetype>` tag in the system
+   reminder OR ask the user which archetype they want when ambiguous.
+2. **Load the playbook.** Read `refs/{archetype}.md` for the phase-by-phase
+   playbook, the produces contract, and the HITL discipline.
+3. **Execute the phases.** Run each phase in order. At each phase boundary
+   ask: "do I have what this phase produces?" Don't move on until yes.
+4. **Honor HITL.** When the playbook marks a gate as `hard:*`, **stop and
+   ask the user** before proceeding. `discrete:*` gates may auto-pass when
+   the produces contract is met. `none` and `continuous` carry no gate.
+5. **Multi-archetype prompts.** When the hook emitted `<wg archetypes>`
+   with two co-firing matches (e.g. `build + migrate` for a schema-change
+   feature), run them in dependency order: `migrate` shape work first, then
+   `build` integration work. The dependency graph lives in each archetype's
+   `next_archetypes` field in the catalog.
+
+## Catalog source of truth
+
+`.claude-plugin/archetypes.json` is canonical. The detector lives at
+`scripts/crew/archetypes_v11.py`. The CLI shim:
+
+```bash
+sh "${CLAUDE_PLUGIN_ROOT}/scripts/_python.sh" \
+  "${CLAUDE_PLUGIN_ROOT}/scripts/crew/archetypes_v11.py" \
+  detect --prompt "<text>" --signals '{"production_impact": true}' --steering
+```
+
+## Refs
+
+- `refs/triage.md` — entry classification
+- `refs/explore.md` — diverge/converge for open problems
+- `refs/specify.md` — elicit + structure + validate ACs
+- `refs/decide.md` — ADR-shaped option scoring
+- `refs/ship.md` — canary/ramp rollout
+- `refs/review.md` — independent assessment with verdict
+- `refs/incident.md` — live-fire response
+- `refs/build.md` — plan/implement/test/review (the common case)
+- `refs/migrate.md` — expand/backfill/cutover/contract (in-place shape change)
+- `refs/modernize.md` — discover/extract/blueprint/transform/parity/cutover (legacy→new-stack port)
+
+## What v11 archetypes are NOT
+
+- They are **not** the v6.3 target-kind archetypes (`code-repo`, `docs-only`,
+  `config-infra`, etc.). Those classify *what is being changed*; v11
+  classifies *what shape of work is happening*. Both stay; they answer
+  different questions.
+- They are **not** rigor tiers (`minimal | standard | full`). v11 obsoletes
+  the rigor-tier dial: each archetype owns its own cost band and HITL.
+- They are **not** phase slots in a universal pipeline. Each archetype's
+  phases live only inside that archetype.

package/skills/archetype/refs/build.md

@@ -0,0 +1,142 @@
+# build — plan / implement / test / review
+
+The most common archetype. Implement and ship a feature or fix. **Test
+rigor scales with complexity, blast_radius, and novelty** — a one-line
+typo fix and a new auth path are both `build` archetype, but the test
+phase looks different.
+
+## Phase shape
+
+| Phase     | Goal                                                |
+|-----------|-----------------------------------------------------|
+| plan      | Name the diff in 2–3 sentences. Pick the test rigor. |
+| implement | Write the change. Stay in the diff; resist drift.   |
+| test      | Verify the diff does what plan said. Rigor scales.  |
+| review    | Hand off to the `review` archetype if needed.       |
+
+## Produces
+
+- **Shipped code**: a commit (or PR) with the diff.
+- **Test report**: at minimum, evidence that the change was exercised.
+  At higher rigor: unit tests, integration tests, acceptance evidence.
+
+The review gate **re-derives** these via `wicked-loom` (`scripts/qe/vault_gate.py` shells `wicked-loom gate`, which shells `wicked-vault cross-check`): the evidence is re-hashed and its verifier
+re-run, never trusting a cached "done". wicked-loom (the gate engine) and wicked-vault (the evidence backend) are **required** peers (installed by `/wicked-garden:setup`); if loom is unresolvable — or the vault behind it absent — the gate **fails closed** (`gate: "unavailable"`, `satisfied: false`) rather
+than self-asserting a PASS. `--no-require` opts a throwaway/low-rigor run
+back to the doctrine-light claim-only path.
+
+## HITL
+
+`discrete:review-gate` — review is the discrete gate. Approve happens
+through PR review, council, or the `review` archetype if rigor warrants.
+
+## Ground in the repo's method first
+
+Before you plan, check for **wicked-understanding** repo playbooks (the opt-in
+"how to work in THIS repo" layer). If its skills are present — `add-feature` /
+`fix-bug` / `scaffold` / `write-tests`, or the routing block in
+`AGENTS.md` / `CLAUDE.md` — **load the one matching this task and follow its
+repo-specific method**: the file that owns this kind of change, the wiring step
+("register it here or it won't boot"), the real test command, the gotcha. That
+turns the plan phase from "discover how this repo works" into "follow the known
+method." Absent? Discover it the usual way — and consider
+`npx skills add mikeparcewski/wicked-understanding --all` so next time it's known.
+
+## How to run
+
+### plan
+
+1. Initialise the evidence tracker for this archetype run:
+   `scripts/qe/evidence_tracker.py init <project_dir> --archetype build`.
+   Pre-populates `shipped-code` and `test-report` as pending.
+   Then, if a vault is resolvable
+   (`scripts/qe/vault_gate.py resolve` → `available: true`), declare the
+   re-derivable contract for this phase so the review gate has a bar to
+   check against:
+   `wicked-vault init` (once per repo) then
+   `wicked-vault declare-contract --scope <scope> --phase build --spec contract.json`
+   — `required_evidence` should pin `tests-pass` to a deterministic
+   verifier (e.g. `exit_code_eq:0`). Skip silently if no vault.
+2. If picking up open conditions from a prior `review` archetype, read
+   `scripts/qe/conditions_manifest.py status <project_dir>` and pin
+   each one to a build task so they don't get lost.
+3. Name the diff in 2–3 sentences. What changes? What stays the same?
+   What's the smallest possible scope?
+2. Pick the test rigor based on signals (factor scoring from the
+   propose-process rubric is a fine input):
+
+   | Signal pattern                                  | Test rigor             |
+   |-------------------------------------------------|------------------------|
+   | reversibility HIGH + blast_radius LOW + novelty LOW | one targeted test  |
+   | medium on any of the above                      | unit tests + 1–2 integration |
+   | high on any of the above                        | unit + integration + acceptance |
+   | compliance scope OR auth changes                | full + security audit  |
+
+3. If the diff is simple-edit-class (typo, comment, format), build
+   shouldn't have been the archetype — drop back to `triage` and
+   suppress.
+
+### implement
+
+1. Write the change. Stay tight to the plan.
+2. Use `wicked-garden:engineering:apply` for patch-style edits when the
+   change is well-scoped.
+3. **Don't refactor adjacent code unless plan said so.** Drift is the
+   #1 source of inflated build cycles.
+
+### test
+
+1. The rigor picked in plan governs which tests get written.
+2. Use `wicked-testing:authoring` to generate tests when the rigor is
+   medium or high.
+3. **Tests must actually fail when the code is wrong.** The
+   test-code-quality-auditor exists for a reason — assertion-free
+   tests are worse than no tests.
+4. Record the test run as re-derivable evidence (vault present):
+   `wicked-vault record --scope <scope> --phase build --claim tests-pass
+   --kind test-run --source "<the test command>" --criteria "<the bar>"
+   --verifier exit_code_eq:0 --run`. The `--run` captures the command's
+   real exit code now and the gate re-runs it later — a claim you can't
+   re-derive is not evidence. No vault → fall back to
+   `evidence_tracker.py claim`.
+
+### review
+
+1. Open the PR. Use the appropriate review skill:
+   - Low rigor: `pr-review-toolkit:code-reviewer` only.
+   - Medium: code-reviewer + relevant specialist (security / data /
+     etc.).
+   - High: full `review` archetype (this skill family).
+2. Address findings. Keep the response narrow — review feedback is for
+   THIS diff, not for opening adjacent issues.
+
+## When to stop
+
+Build is done when the produces-gate is satisfied AND the PR is merged.
+Check the gate — don't self-assert it.
+
+**Frictionless (recommended for a single decisive claim):** skip the
+init/declare/record/gate ritual and re-derive in one call —
+`scripts/qe/prove.py tests-pass --by "<your test command>" --scope <scope> --phase build`
+(exit 0 = re-derived PASS; exit 1 = REJECT; exit 3 = backend down / fail-closed).
+Run it before you tell anyone the build is done.
+
+**Full contract (multi-claim):** declare a contract then
+`scripts/qe/vault_gate.py gate <project_dir> --scope <scope> --phase build`
+(exit 0 = satisfied). Either way it is a re-derived PASS over the declared
+contract. A REJECT means the recorded evidence does not clear its
+contract — fix the work, not the claim. An `unavailable` verdict means
+the required vault isn't installed — run `/wicked-garden:setup`. If the
+change is high-blast-radius, hand off to `ship`.
+
+## Anti-patterns
+
+- **Don't refactor in build.** A bug fix doesn't need surrounding
+  cleanup. The CLAUDE.md "no premature abstraction" rule applies.
+- **Don't write tests before the code compiles.** TDD is fine; testing
+  uncompilable code is not.
+- **Don't merge with red CI.** The "I'll fix it in a follow-up"
+  mentality is how main goes red and stays red.
+- **Don't test-stamp with rigor that doesn't match the change.**
+  Adding 200 LOC of integration scaffolding for a typo fix is its own
+  anti-pattern.