@event4u/agent-config 1.9.1

package/.agent-src/skills/threat-modeling/SKILL.md

@@ -0,0 +1,189 @@
+---
+name: threat-modeling
+description: "Use when adding auth, webhooks, uploads, queues, secrets, tenant boundaries, or public endpoints — produces trust boundaries + abuse cases mapped to files, BEFORE implementation."
+source: package
+---
+
+# threat-modeling
+
+> You are a reviewer specialized in **pre-implementation threat analysis**.
+> Your only job is to produce a compact threat model for a planned change —
+> actors, assets, trust boundaries, abuse cases, and the minimum controls
+> the implementer must add. You do **not** audit existing code end-to-end,
+> you do **not** review diffs, you do **not** implement controls — sibling
+> skills handle those.
+
+## When to use
+
+* The change adds or modifies authentication, authorization, or permission checks
+* The change adds a public endpoint, webhook, file upload, queue worker,
+  scheduled task, or third-party integration
+* The change touches sensitive data, tenant boundaries, secrets, billing flows,
+  or admin-only capabilities
+* A `security-sensitive-stop-rule` trigger fired and the agent must produce a
+  risk review before patching
+
+Do NOT use when:
+
+* The change is a cosmetic refactor or documentation-only edit — skip entirely
+* The change is a diff ready for review — route to
+  [`judge-security-auditor`](../judge-security-auditor/SKILL.md)
+* The concern is a full-codebase security posture review — route to
+  [`security-audit`](../security-audit/SKILL.md)
+* The concern is end-to-end authorization enforcement — route to
+  [`authz-review`](../authz-review/SKILL.md)
+* The concern is output/log leakage on an existing API — route to
+  [`data-exposure-review`](../data-exposure-review/SKILL.md)
+* The concern is implementing the controls once identified — route to
+  [`security`](../security/SKILL.md)
+
+## Procedure
+
+### 1. Anchor on the planned change
+
+Read the task description (ticket, feature plan, spec) and the entrypoints
+the change will touch. You are modelling **the stated change**, not the
+whole system. If the change is unclear from available context, stop and ask
+before continuing — never invent a threat model for an imagined feature.
+
+### 2. Inspect the execution path
+
+Trace the path once through existing code:
+
+- Where does untrusted input enter? (route, webhook, queue payload, CLI arg,
+  uploaded file, imported record)
+- Which actor types cross this path? (anonymous, authenticated user, admin,
+  service account, queue worker, cron)
+- What assets does the path touch? (PII, credentials, internal IDs, billing,
+  tenant-scoped records, files, secrets)
+- Where are the privilege boundaries? (auth gate, authorization layer, tenant
+  scope, admin gate)
+
+### 3. Model the risks
+
+For every distinct abuse case, answer:
+
+| Field | What to fill in |
+|---|---|
+| Entry point | route / job / webhook + concrete file |
+| Actor | who can trigger it |
+| Precondition | what must be true (auth state, data state) |
+| Impact | concrete damage (data loss, privilege escalation, DoS, leakage) |
+| Current control | what exists today |
+| Missing control | what the change must add |
+
+Prioritize by **impact × plausibility**, not by novelty. Skip generic
+OWASP bullets unless you can anchor them in a concrete file or line.
+
+### 4. Convert risks to engineering actions
+
+For each prioritized abuse case, propose the **smallest effective control**
+and name the exact file/layer it belongs in:
+
+- input validation → where
+- authorization check → where
+- rate limiting → where
+- output filtering → where
+- safer default → where
+- logging / alerting → where
+
+State whether a new **negative test** is required and what condition it
+must assert (e.g. *"POST /imports with tenant-B id from tenant-A session
+returns 403"*).
+
+## Validation
+
+Before finalizing the threat model, confirm:
+
+1. Every entry point has at least one identified control owner
+2. Every 🔴 abuse case has either an existing control or a required new one
+3. Every 🔴 abuse case has at least one proposed negative test
+4. You have NOT produced generic advice — every risk cites a file, route, or job
+5. You have NOT proposed offensive testing steps, exploit chains, or bypass ideas
+6. If the change is out of scope for threat modelling (no trust boundary
+   crossed), you have said so explicitly and stopped
+
+## Output format
+
+```
+Skill:   threat-modeling
+Target:  <feature / ticket / change summary>
+
+Actors:   <list, one per line>
+Assets:   <list, one per line>
+Entry points:   <route / job / webhook — file:line>
+Trust boundaries:   <where untrusted → trusted crossings happen>
+
+Abuse cases (prioritized):
+  🔴  <name> — entry point · actor · precondition
+      Impact: <concrete damage>
+      Current control: <what exists>
+      Missing control: <what to add, where>
+      Required test: <negative assertion>
+  🟡  ...
+  🟢  ...
+
+Implementation plan:
+  1. <control>, <file/layer>
+  2. ...
+
+Missing tests:
+  1. <assertion>, <test file>
+```
+
+Severity: 🔴 exploitable by external actor with current or no privilege /
+🟡 exploitable only with elevated privilege or partial auth / 🟢 defense-in-depth
+improvement, not a concrete exploit path.
+
+Required fields (ordered):
+
+1. **Skill** and **Target** — one-line change summary
+2. **Actors**, **Assets**, **Entry points**, **Trust boundaries**
+3. **Abuse cases** — prioritized; every entry cites entry point + actor + impact + current + missing control + required test
+4. **Implementation plan** — ordered controls mapped to files/layers
+5. **Missing tests** — ordered negative assertions
+
+Runtime confirmation (e.g. *"reproduce the abuse against staging"*, *"query
+the DB to confirm scope leakage exists today"*) is a follow-up for the
+implementer — **this skill does not execute tools, reproduce exploits, or
+run tests**.
+
+## Gotcha
+
+* **Generic OWASP bullets without a file anchor** — "SQL injection risk" is
+  noise unless you cite the query. Drop it or anchor it.
+* **Confusing authentication with authorization** — a logged-in user is not an
+  authorized user. Model authorization as a distinct boundary even when auth
+  is already enforced upstream.
+* **Treating queue workers and webhooks as trusted** — they carry attacker-
+  influenced payloads. Model them as untrusted entry points.
+* **Modelling the whole system when the change is narrow** — the model is
+  scoped to the planned change. Out-of-scope risks belong to `security-audit`.
+* **Producing offensive test steps** — you name abuse cases and required
+  controls, not exploit procedures.
+
+## Do NOT
+
+* NEVER produce exploit chains, payloads, or bypass techniques — if the task
+  asks for offensive work, stop and refuse per `never-help-build-offensive-cyber-capability`
+* NEVER return a threat model out of politeness when no trust boundary is crossed — say so and stop
+* NEVER treat "internal" or "behind the WAF" as a substitute for a control
+* NEVER approve a plan without at least one negative test per 🔴 abuse case
+* NEVER silently fall back to a generic checklist when the diff context is missing — ask instead
+
+## References
+
+- **STRIDE threat model** — Microsoft Security Development Lifecycle, Shostack
+  *Threat Modeling: Designing for Security* (2014). Framing basis for the
+  Actors / Assets / Entry Points / Trust Boundaries / Abuse Cases rubric.
+  [learn.microsoft.com/en-us/security/engineering/threat-modeling-tool-threats](https://learn.microsoft.com/en-us/security/engineering/threat-modeling-tool-threats)
+- **OWASP ASVS v4.0.3** — Authorization (V4), Validation & Encoding (V5),
+  Session Management (V3) — default baseline for "Missing control" entries.
+  [owasp.org/www-project-application-security-verification-standard/](https://owasp.org/www-project-application-security-verification-standard/)
+- **OWASP Top 10 2021** — A01 Broken Access Control, A04 Insecure Design,
+  A05 Security Misconfiguration — cross-reference when naming abuse cases.
+  [owasp.org/Top10/](https://owasp.org/Top10/)
+- [`authz-review`](../authz-review/SKILL.md),
+  [`data-exposure-review`](../data-exposure-review/SKILL.md),
+  [`security`](../security/SKILL.md),
+  [`security-audit`](../security-audit/SKILL.md) — sibling review / implementation skills.

package/.agent-src/skills/traefik/SKILL.md

@@ -0,0 +1,319 @@
+---
+name: traefik
+description: "Use when setting up Traefik as a local reverse proxy — real domains on 127.0.0.1, trusted HTTPS via mkcert, automatic service discovery, and multi-project routing."
+source: package
+---
+
+# Traefik Skill
+
+## When to use
+
+Use this skill when:
+- Setting up local development with real domain names and trusted HTTPS
+- Configuring SSL certificates (self-signed, mkcert, ACME via Namecheap/AWS)
+- Routing multiple Docker projects through a single reverse proxy
+- Embedding external services (Grafana, etc.) that require HTTPS/same-origin
+
+## Procedure: Set up Traefik
+
+### 0. Understand current setup
+
+Before changing routing:
+
+1. Check existing proxy — `docker ps | grep traefik`
+2. Review docker-compose for existing labels and network config
+3. Check `/etc/hosts` or dnsmasq for existing domain mappings
+
+### Architecture
+
+Traefik acts as a **local reverse proxy** that:
+1. Resolves real domains (e.g., `local.example.dev`, `app.test`) to `127.0.0.1`
+2. Terminates HTTPS with trusted certificates
+3. Auto-discovers Docker services via labels (no manual config per service)
+4. Routes requests to the correct container based on hostname
+
+```
+Browser → https://app.example.com
+    → DNS resolves to 127.0.0.1 (via /etc/hosts or dnsmasq)
+    → Traefik (port 443) picks up the request
+    → Routes to app container (based on Docker labels)
+```
+
+## DNS Resolution (domains → 127.0.0.1)
+
+**Option A: `/etc/hosts` (simple, per-domain)**
+
+```
+127.0.0.1  local.example.dev
+127.0.0.1  grafana.local.example.dev
+```
+
+**Option B: dnsmasq (wildcard, all subdomains — preferred)**
+
+```bash
+brew install dnsmasq
+echo 'address=/.local.example.dev/127.0.0.1' >> /opt/homebrew/etc/dnsmasq.conf
+sudo brew services restart dnsmasq
+sudo mkdir -p /etc/resolver
+echo 'nameserver 127.0.0.1' | sudo tee /etc/resolver/local.example.dev
+```
+
+## Certificate Strategies
+
+Choose based on project needs:
+
+| Strategy | Tool | Trust | Use when |
+|---|---|---|---|
+| **Self-signed** | openssl | Manual trust via keychain | Quick local dev, no external deps |
+| **mkcert** | mkcert | Auto-trusted local CA | Local dev, easiest setup |
+| **ACME (Namecheap)** | lego + DNS-01 | Real CA (Let's Encrypt) | Real domain, Namecheap DNS |
+| **ACME (AWS Route53)** | lego + DNS-01 | Real CA (Let's Encrypt) | Real domain, AWS DNS |
+
+### Self-signed (openssl)
+
+```bash
+mkdir -p traefik/certificates
+openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
+  -keyout traefik/certificates/_.${CERT_DOMAIN}.key \
+  -out traefik/certificates/_.${CERT_DOMAIN}.crt \
+  -subj "/CN=*.${CERT_DOMAIN}" \
+  -addext "subjectAltName=DNS:*.${CERT_DOMAIN},DNS:${CERT_DOMAIN}"
+
+# Trust on macOS
+sudo security add-trusted-cert -d -r trustRoot \
+  -k /Library/Keychains/System.keychain traefik/certificates/tls.crt
+```
+
+### mkcert (simplest for local dev)
+
+```bash
+brew install mkcert && mkcert -install
+mkcert "local.example.dev" "*.local.example.dev"
+```
+
+### ACME via Lego container (real certs)
+
+```yaml
+# docker-compose.yml
+lego:
+  image: goacme/lego:latest
+  profiles: [manual]   # Only run on demand
+  volumes:
+    - ./traefik/certificates:/etc/lego
+```
+
+```bash
+# Namecheap DNS-01
+docker compose run --rm \
+  -e NAMECHEAP_API_USER -e NAMECHEAP_API_KEY \
+  lego --dns namecheap \
+  --domains "*.${CERT_DOMAIN}" --email "admin@${CERT_DOMAIN}" \
+  --path /etc/lego run
+
+# AWS Route53 DNS-01
+docker compose run --rm \
+  -e AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY -e AWS_REGION \
+  lego --dns route53 \
+  --domains "*.${CERT_DOMAIN}" --email "admin@${CERT_DOMAIN}" \
+  --path /etc/lego run
+```
+
+### Taskfile integration for cert management
+
+```yaml
+# certificates/generate.yml (included in main Taskfile)
+tasks:
+  selfsigned:
+    desc: Generate self-signed certificate for ${CERT_DOMAIN}
+    cmds: [...]
+
+  namecheap:
+    desc: Generate ACME certificate via Namecheap DNS-01
+    cmds: [...]
+
+  aws:
+    desc: Generate ACME certificate via AWS Route53 DNS-01
+    cmds: [...]
+```
+
+```yaml
+# Main Taskfile
+trust:
+  desc: Add cert to macOS keychain
+  cmds:
+    - sudo security add-trusted-cert -d -r trustRoot \
+        -k /Library/Keychains/System.keychain traefik/certificates/tls.crt
+
+untrust:
+  desc: Remove cert from macOS keychain
+  cmds:
+    - sudo security delete-certificate -c "*.${CERT_DOMAIN}" \
+        /Library/Keychains/System.keychain
+
+cert:setup:
+  desc: Generate and trust self-signed certificate
+  deps: [generate:selfsigned, trust]
+```
+
+## Traefik Container
+
+```yaml
+traefik:
+  image: traefik:v3.2   # or v2.11 for older setups
+  command:
+    - --providers.docker=true
+    - --providers.docker.exposedbydefault=false
+    - --providers.file.directory=/etc/traefik/dynamic
+    - --providers.file.watch=true
+    - --entrypoints.web.address=:80
+    - --entrypoints.websecure.address=:443
+  ports:
+    - "${TRAEFIK_HTTP_PORT:-80}:80"
+    - "${TRAEFIK_HTTPS_PORT:-443}:443"
+  volumes:
+    - /var/run/docker.sock:/var/run/docker.sock:ro
+    - ./traefik/dynamic:/etc/traefik/dynamic:ro
+    - ./traefik/certificates:/certs:ro
+```
+
+### TLS dynamic config
+
+```yaml
+# traefik/dynamic/tls.yml
+tls:
+  certificates:
+    - certFile: /certs/tls.crt
+      keyFile: /certs/tls.key
+```
+
+## Service Labels
+
+### Basic pattern (HTTP → HTTPS redirect + TLS)
+
+```yaml
+my-service:
+  labels:
+    - "traefik.enable=true"
+    # HTTP router (redirect to HTTPS)
+    - "traefik.http.routers.myapp.rule=Host(`${CERT_HOST}`)"
+    - "traefik.http.routers.myapp.entrypoints=web"
+    - "traefik.http.routers.myapp.middlewares=myapp-https-redirect"
+    - "traefik.http.middlewares.myapp-https-redirect.redirectscheme.scheme=https"
+    - "traefik.http.middlewares.myapp-https-redirect.redirectscheme.port=${TRAEFIK_HTTPS_PORT}"
+    # HTTPS router
+    - "traefik.http.routers.myapp-secure.rule=Host(`${CERT_HOST}`)"
+    - "traefik.http.routers.myapp-secure.entrypoints=websecure"
+    - "traefik.http.routers.myapp-secure.tls=true"
+    - "traefik.http.services.myapp.loadbalancer.server.port=80"
+```
+
+### Subdomain routing
+
+```yaml
+grafana:
+  labels:
+    - "traefik.enable=true"
+    - "traefik.http.routers.grafana-secure.rule=Host(`grafana.${CERT_HOST}`)"
+    - "traefik.http.routers.grafana-secure.entrypoints=websecure"
+    - "traefik.http.routers.grafana-secure.tls=true"
+    - "traefik.http.services.grafana.loadbalancer.server.port=3000"
+```
+
+### Path-based routing
+
+```yaml
+horizon:
+  labels:
+    - "traefik.http.routers.horizon-secure.rule=Host(`${CERT_HOST}`) && PathPrefix(`/horizon`)"
+```
+
+## Integration Patterns
+
+### With NGINX
+
+Traefik sits **in front of** NGINX — does NOT replace it:
+
+```
+Traefik (443) → NGINX (80 internal) → PHP-FPM
+```
+
+NGINX keeps: PHP-FPM routing, Xdebug header detection, static files.
+Traefik adds: real domains, HTTPS, multi-service routing.
+
+### Standalone
+
+Traefik routes directly to the app container:
+
+```
+Traefik (443) → App container (80 internal)
+```
+
+### Multi-project (shared Traefik)
+
+One Traefik instance routes to multiple projects via shared network:
+
+```yaml
+networks:
+  traefik-public:
+    external: true   # docker network create traefik-public
+```
+
+```
+traefik
+├── local.example.dev      → api-service
+├── grafana.local.example.dev → grafana
+├── other.local.example.dev → other-service
+└── app.test               → frontend
+```
+
+## Middleware Examples
+
+```yaml
+# Rate limiting
+- "traefik.http.middlewares.rate-limit.ratelimit.average=100"
+
+# Basic auth
+- "traefik.http.middlewares.auth.basicauth.users=admin:$$apr1$$..."
+
+# CORS
+- "traefik.http.middlewares.cors.headers.accesscontrolalloworiginlist=*"
+```
+
+## Related
+
+- **Skill:** `docker` — Docker setup, compose services, container architecture
+- **Skill:** `devcontainer` — DevContainer and Codespaces setup
+- **Skill:** `grafana` — Grafana dashboards (benefits from HTTPS for embedding)
+- **Skill:** `dashboard-design` — Grafana embedding requires same-origin/HTTPS
+- **Rule:** `docker-commands.md` — all commands run inside Docker containers
+
+### Validate
+
+- Verify Traefik dashboard is accessible and shows all expected services.
+- Confirm HTTPS works with trusted certificates (no browser warnings).
+- Check that each service has correct Docker labels for routing.
+- Test DNS resolution: `curl -I https://your-domain.localhost` should return 200.
+
+## Output format
+
+1. Traefik configuration with routing rules and TLS setup
+2. Docker labels or dynamic config for service discovery
+
+## Gotcha
+
+- Traefik requires Docker labels on each service — a missing label means the service isn't routed.
+- mkcert certificates must be trusted by the OS — `mkcert -install` is a one-time setup step.
+- The model forgets to add the Traefik network to docker-compose services — no network = no routing.
+
+## Do NOT
+
+- Do NOT expose internal services without authentication.
+- Do NOT use self-signed certificates when mkcert is available.
+
+## Auto-trigger keywords
+
+- Traefik
+- reverse proxy
+- local domains
+- HTTPS
+- mkcert

package/.agent-src/skills/universal-project-analysis/SKILL.md

@@ -0,0 +1,179 @@
+---
+name: universal-project-analysis
+description: "ONLY when user explicitly requests: full project analysis, deep codebase audit, or comprehensive architecture review. Routes to core and framework-specific analysis skills."
+source: package
+---
+
+# universal-project-analysis
+
+## When to use
+
+Use this skill when:
+
+* The user explicitly requests a full project analysis
+* The user wants a deep codebase audit
+* The user wants a comprehensive architecture review
+* The system is large, unclear, or spans multiple layers
+* `analysis-autonomous-mode` routes here for broad understanding
+
+Do NOT use when:
+
+* The task is normal feature work
+* Only a small isolated code area needs review
+* The issue is already narrow enough for a specialist skill
+* A framework-specific analysis skill can be called directly
+
+## Mission
+
+Act as the top-level router for deep project investigation.
+
+This skill must:
+
+* confirm whether full-project analysis is justified
+* identify the stack and framework
+* choose the correct analysis mode
+* route to the right specialist analysis skills
+* define the required output for broad project investigations
+
+This skill must NOT become:
+
+* a giant framework encyclopedia
+* a shallow pointer-only file
+* a replacement for framework-specific deep-dive skills
+
+## Core principles
+
+1. Never assume — verify against code, config, docs, and evidence
+2. Version dictates behavior
+3. Broad understanding comes before narrow conclusions
+4. Use framework-specific skills once the stack is known
+5. Use hypothesis-driven analysis when root cause is unclear
+6. Mark uncertainty explicitly
+
+## Thinking model
+
+Always think in this order:
+
+1. Observe
+2. Understand
+3. Verify
+4. Route
+5. Investigate
+6. Conclude
+
+## Analysis modes
+
+### Exploration mode
+
+Use when the system is unknown.
+Goal: understand structure, identify major components, detect investigation paths, choose the next specialist skill.
+
+### Investigation mode
+
+Use when there is a concrete issue inside a large or unclear system.
+Goal: isolate the affected area, route into root-cause analysis, verify likely causes with evidence.
+
+### Optimization mode
+
+Use when the system works but may be inefficient or over-complex.
+Goal: identify hot paths, find expensive boundaries, route into architecture or performance specialists.
+
+## Procedure
+
+### 1. Confirm scope
+
+Check whether full-project analysis is really needed.
+Use this skill only if the user wants: broad system understanding, architecture reconstruction, deep multi-layer debugging, broad audit across modules or runtime boundaries.
+If not: route to the narrower specialist skill directly.
+
+### 2. Discover the project
+
+Identify: language, framework, runtime environment, package managers, major entrypoints, documentation locations.
+Look at: package manifests, lock files, bootstrap files, Docker/CI config, README/AGENTS/docs.
+
+### 3. Choose the primary route
+
+* unknown or mixed system → `project-analysis-core`
+* concrete root-cause problem → `project-analysis-hypothesis-driven`
+* Laravel → `project-analysis-laravel`
+* Symfony → `project-analysis-symfony`
+* Zend/Laminas → `project-analysis-zend-laminas`
+* Node/Express → `project-analysis-node-express`
+* React → `project-analysis-react`
+* Next.js → `project-analysis-nextjs`
+
+### 4. Chain specialists where needed
+
+* bottleneck found → `performance-analysis`
+* security concern found → `security-audit`
+* bug isolated → `bug-analyzer`
+
+### 5. Consolidate findings
+
+Combine: system overview, framework-specific findings, verified risks, explicit uncertainties, next investigation steps.
+
+### 6. Validate analysis quality
+
+Check:
+
+* full-project analysis was actually justified
+* framework detection is explicit
+* chosen specialist skills match the discovered stack
+* uncertainties are marked
+* conclusions are evidence-based
+
+## Routing map
+
+### Universal analysis skills
+
+* `project-analysis-core`
+* `project-analysis-hypothesis-driven`
+
+### Framework-specific deep dives
+
+* `project-analysis-laravel`
+* `project-analysis-symfony`
+* `project-analysis-zend-laminas`
+* `project-analysis-node-express`
+* `project-analysis-react`
+* `project-analysis-nextjs`
+
+### Optional downstream specialists
+
+* `bug-analyzer`
+* `performance-analysis`
+* `security-audit`
+
+## When to add a new framework analysis skill
+
+A framework gets its own `project-analysis-*` skill ONLY if:
+
+* it has its own lifecycle that creates unique debugging patterns
+* it produces failure classes that `project-analysis-core` cannot explain
+* debugging it requires framework-specific mental models (not just API knowledge)
+
+Examples that qualify: Laravel, Symfony, Express, React, Next.js.
+Examples that do NOT qualify: Tailwind, small utility libraries, CSS frameworks, simple state libs.
+
+## Output format
+
+1. Investigation summary
+2. Detected stack and framework
+3. Chosen analysis mode
+4. Routed specialist skills
+5. Consolidated findings
+6. Risks and next steps
+
+## Gotcha
+
+* This skill must remain a real orchestration skill.
+* Do not move long framework-specific deep dives back into this file.
+* Do not let this skill become a generic "analyze everything" bucket.
+
+## Do NOT
+
+* Do NOT analyze everything here directly if a specialist skill exists
+* Do NOT skip framework detection
+* Do NOT present broad guesses as conclusions
+* Do NOT turn this into a shallow pointer-only file
+* Do NOT duplicate framework-specific deep-dive content here