@baselane/packs 0.1.5 → 0.1.6

package/packs/full-harness/rendered/.claude/skills/uncloud/SKILL.md

@@ -0,0 +1,342 @@
+---
+name: uncloud
+description: Use when managing an Uncloud cluster — deploying services, configuring Caddy ingress, adding static proxy routes for non-cluster devices, publishing ports, scaling, inspecting logs, or managing machines and volumes with the `uc` CLI.
+---
+
+# Uncloud Cluster Management
+
+Reference for the `uc` CLI — a decentralised self-hosting platform using Docker containers, WireGuard mesh networking, and Caddy reverse proxy.
+
+## When to Activate
+
+Use this skill when working with Uncloud clusters, especially when:
+- Bootstrapping or joining machines with `uc machine`
+- Deploying services from Compose files with `uc deploy`
+- Publishing HTTP, HTTPS, TCP, or UDP ports through Uncloud
+- Configuring Caddy ingress with `x-caddy`, `x-ports`, or `--caddyfile`
+- Routing external LAN devices through the cluster proxy
+- Inspecting logs, service state, volumes, DNS, or machine placement
+
+## How It Works
+
+Uncloud runs Docker services across peer machines connected by a WireGuard mesh. Each machine is an equal cluster member; services communicate on the overlay network and Caddy runs globally to terminate public HTTP/HTTPS traffic. Compose files can use Uncloud extensions for ingress, placement, and generated Caddy configuration, while the `uc` CLI handles image distribution, scheduling, scaling, logs, and cluster state.
+
+## Examples
+
+```bash
+uc machine init user@host --name machine-1
+uc service run --name web -p app.example.com:8080/https nginx:latest
+uc deploy
+```
+
+## Core Concepts
+
+- **No central control plane** — all machines are equal peers connected by WireGuard
+- **Caddy** runs as a global service on every machine; auto-obtains TLS from Let's Encrypt
+- **Overlay network** — services communicate via `10.210.0.0/16` by default; DNS provided inside the mesh
+- **Caddyfile is autogenerated** — never edit it directly; use `x-caddy` / `--caddyfile` instead
+
+---
+
+## CLI Quick Reference
+
+### Machines
+
+| Command | Purpose |
+|---------|---------|
+| `uc machine init user@host` | Bootstrap first machine / new cluster |
+| `uc machine add user@host` | Join machine to existing cluster |
+| `uc machine ls` | List machines |
+| `uc machine update NAME --public-ip IP` | Update public IP for ingress |
+| `uc machine rm NAME` | Remove machine |
+
+Key `init` flags: `--name`, `--network 10.210.0.0/16`, `--no-caddy`, `--no-dns`, `--public-ip auto\|IP\|none`
+
+### Services
+
+| Command | Purpose |
+|---------|---------|
+| `uc service ls` / `uc ls` | List services |
+| `uc service run IMAGE` | Run a single container service |
+| `uc deploy` | Deploy from `compose.yaml` |
+| `uc deploy --no-build` | Deploy already-pushed images without rebuilding |
+| `uc deploy --recreate` | Force service recreation |
+| `uc scale SERVICE N` | Set replica count |
+| `uc service logs SERVICE` | View logs |
+| `uc service exec SERVICE` | Shell into container |
+| `uc service inspect SERVICE` | Detailed info |
+| `uc service rm SERVICE` | Remove service (keeps named volumes) |
+| `uc ps` | All containers across cluster |
+
+### Images
+
+```bash
+uc image push myapp:latest                    # Push local image to all machines
+uc image push myapp:latest -m machine1,machine2  # Push to specific machines
+uc images                                     # List images in cluster
+```
+
+### Volumes
+
+```bash
+uc volume ls                  # All volumes
+uc volume ls -m machine1      # On specific machine
+uc volume create NAME -m MACHINE
+uc volume rm NAME
+```
+
+### Caddy
+
+```bash
+uc caddy config    # Show current generated Caddyfile (read-only)
+uc caddy deploy    # Deploy/upgrade Caddy across cluster
+```
+
+### DNS & Context
+
+```bash
+uc dns show        # Show reserved *.uncld.dev domain
+uc dns reserve     # Reserve a new domain
+uc ctx ls          # List cluster contexts
+uc ctx use prod    # Switch context
+```
+
+---
+
+## Port Publishing
+
+### HTTP/HTTPS (via Caddy reverse proxy)
+
+```
+-p [hostname:]container_port[/protocol]
+```
+
+| Example | Meaning |
+|---------|---------|
+| `-p 8080/https` | HTTPS with auto `service-name.cluster-domain` hostname |
+| `-p app.example.com:8080/https` | HTTPS with custom hostname |
+| `-p 8080/http` | HTTP only, no TLS |
+
+### TCP/UDP (host-bound, bypasses Caddy)
+
+```
+-p [host_ip:]host_port:container_port[/protocol]@host
+```
+
+| Example | Meaning |
+|---------|---------|
+| `-p 5432:5432@host` | TCP 5432 on all interfaces |
+| `-p 127.0.0.1:5432:5432@host` | TCP 5432 loopback only |
+| `-p 53:5353/udp@host` | UDP |
+
+---
+
+## Compose File Extensions
+
+Uncloud adds these extensions on top of Docker Compose:
+
+### `x-ports` — publish ports with domains
+
+```yaml
+services:
+  app:
+    image: app:latest
+    x-ports:
+      - example.com:8000/https
+      - www.example.com:8000/https
+      - api.example.com:9000/https
+```
+
+### `x-caddy` — custom Caddy config for service
+
+```yaml
+services:
+  app:
+    image: app:latest
+    x-caddy: |
+      example.com {
+        redir https://www.example.com{uri} permanent
+      }
+      www.example.com {
+        reverse_proxy {{upstreams 8000}} {
+          import common_proxy
+        }
+        basic_auth /admin/* {
+          admin $2a$14$...
+        }
+      }
+```
+
+Template functions available inside `x-caddy`:
+- `{{upstreams [service] [port]}}` — healthy container IPs
+- `{{.Name}}` — service name
+- `{{.Upstreams}}` — map of all services → IPs
+
+### `x-machines` — placement constraints
+
+```yaml
+services:
+  db:
+    image: postgres:18
+    x-machines: db-machine          # Single machine name
+  app:
+    image: app:latest
+    x-machines:
+      - machine-1
+      - machine-2
+```
+
+### Full multi-service example
+
+```yaml
+services:
+  api:
+    build: ./api
+    x-ports:
+      - api.example.com:3000/https
+    environment:
+      DATABASE_URL: postgres://db:5432/mydb
+
+  web:
+    build: ./web
+    x-ports:
+      - example.com:8000/https
+      - www.example.com:8000/https
+    environment:
+      API_URL: http://api:3000
+
+  db:
+    image: postgres:18
+    environment:
+      POSTGRES_PASSWORD: ${DB_PASSWORD}
+    volumes:
+      - db-data:/var/lib/postgresql/data
+    x-machines: db-machine
+
+volumes:
+  db-data:
+```
+
+---
+
+## Routing to External (Non-Cluster) Devices
+
+To expose an external device (e.g. BMC, NAS, router UI) via Caddy without running a real container:
+
+**1. Create a Caddyfile snippet** (e.g. `~/device.caddyfile`):
+
+```caddyfile
+https://device.example.com {
+    reverse_proxy https://192.168.1.x {
+        transport http {
+            tls_insecure_skip_verify   # needed for self-signed BMC certs
+        }
+    }
+    log
+}
+```
+
+For plaintext upstream: `reverse_proxy http://192.168.1.x:port`
+
+**2. Register as a named service with no-op container:**
+
+```bash
+uc service run \
+  --name device-bmc \
+  --caddyfile ~/device.caddyfile \
+  registry.k8s.io/pause:3.9
+```
+
+`pause` is a minimal no-op container — it does nothing, but gives Uncloud a service entry to attach the Caddyfile to.
+
+**3. Verify:**
+
+```bash
+uc caddy config   # device.example.com block should appear
+```
+
+> `--caddyfile` cannot be combined with non-`@host` published ports.
+
+**DNS tip:** A wildcard record (`*.yourdomain.com → cluster-public-ip`) means any new subdomain works immediately — no DNS change needed per service.
+
+---
+
+## Service DNS (Internal)
+
+Services inside the cluster resolve each other by name:
+
+| DNS name | Resolves to |
+|----------|------------|
+| `service-name` | Any healthy container |
+| `service-name.internal` | Same |
+| `rr.service-name.internal` | Round-robin |
+| `nearest.service-name.internal` | Machine-local first |
+
+---
+
+## Scaling & Global Services
+
+```bash
+uc scale web 5    # 5 replicas (spread across machines)
+uc scale web 1    # Scale down
+```
+
+```yaml
+services:
+  caddy:
+    deploy:
+      mode: global   # One container on every machine
+```
+
+---
+
+## Image Tag Templates (in compose.yaml)
+
+```yaml
+image: myapp:{{gitdate "20060102"}}.{{gitsha 7}}
+image: myapp:{{gitsha 7}}.${GITHUB_RUN_ID:-local}
+```
+
+| Function | Output |
+|----------|--------|
+| `{{gitsha N}}` | First N chars of commit SHA |
+| `{{gitdate "format"}}` | Git commit date in Go format |
+| `{{date "format"}}` | Current date |
+
+---
+
+## Common Workflows
+
+**Deploy from source:**
+```bash
+uc deploy                          # Build + push + deploy
+uc build --push && uc deploy --no-build   # Separate steps
+```
+
+**Inspect a service:**
+```bash
+uc inspect web
+uc logs -f web
+uc logs --since 1h web
+uc exec web                        # Opens shell
+uc exec web /bin/sh -c "env"       # Run specific command
+```
+
+**Zero-downtime deploys** happen automatically; Uncloud waits for health checks before terminating old containers.
+
+**Force recreate:**
+```bash
+uc deploy --recreate
+```
+
+---
+
+## Common Mistakes
+
+| Mistake | Fix |
+|---------|-----|
+| Editing the Caddyfile directly | Use `x-caddy` in compose or `--caddyfile` on `uc service run` |
+| Proxying an HTTPS upstream with self-signed cert | Add `transport http { tls_insecure_skip_verify }` |
+| `uc caddy config` shows no user-defined blocks | Caddy admin socket unreachable — check `uc inspect caddy` and `uc logs caddy` |
+| Service can't reach external LAN IP from container | Verify Caddy container's host can route to target network |
+| Volumes lost after `uc service rm` | Named volumes persist; only anonymous volumes are auto-removed |

package/packs/full-harness/rendered/.claude/skills/unified-notifications-ops/SKILL.md

@@ -0,0 +1,186 @@
+---
+name: unified-notifications-ops
+description: Operate notifications as one ECC-native workflow across GitHub, Linear, desktop alerts, hooks, and connected communication surfaces. Use when the real problem is alert routing, deduplication, escalation, or inbox collapse.
+---
+
+# Unified Notifications Ops
+
+Use this skill when the real problem is not a missing ping. The real problem is a fragmented notification system.
+
+The job is to turn scattered events into one operator surface with:
+- clear severity
+- clear ownership
+- clear routing
+- clear follow-up action
+
+## When to Use
+
+- the user wants a unified notification lane across GitHub, Linear, local hooks, desktop alerts, chat, or email
+- CI failures, review requests, issue updates, and operator events are arriving in disconnected places
+- the current setup creates noise instead of action
+- the user wants to consolidate overlapping notification branches or backlog proposals into one ECC-native lane
+- the workspace already has hooks, MCPs, or connected tools, but no coherent notification policy
+
+## Preferred Surface
+
+Start from what already exists:
+- GitHub issues, PRs, reviews, comments, and CI
+- Linear issue/project movement
+- local hook events and session lifecycle signals
+- desktop notification primitives
+- connected email/chat surfaces when they actually exist
+
+Prefer ECC-native orchestration over telling the user to adopt a separate notification product.
+
+## Non-Negotiable Rules
+
+- never expose tokens, secrets, webhook secrets, or internal identifiers
+- separate:
+  - event source
+  - severity
+  - routing channel
+  - operator action
+- default to digest-first when interruption cost is unclear
+- do not fan out every event to every channel
+- if the real fix is better issue triage, hook policy, or project flow, say so explicitly
+
+## Event Pipeline
+
+Treat the lane as:
+
+1. **Capture** the event
+2. **Classify** urgency and owner
+3. **Route** to the correct channel
+4. **Collapse** duplicates and low-signal churn
+5. **Attach** the next operator action
+
+The goal is fewer, better notifications.
+
+## Default Severity Model
+
+| Class | Examples | Default handling |
+| --- | --- | --- |
+| Critical | broken default-branch CI, security issue, blocked release, failed deploy | interrupt now |
+| High | review requested, failing PR, owner-blocking handoff | same-day alert |
+| Medium | issue state changes, notable comments, backlog movement | digest or queue |
+| Low | repeat successes, routine churn, redundant lifecycle markers | suppress or fold |
+
+If the workspace has no severity model, build one before proposing automation.
+
+## Workflow
+
+### 1. Inventory the current surface
+
+List:
+- event sources
+- current channels
+- existing hooks/scripts that emit alerts
+- duplicate paths for the same event
+- silent failure cases where important things are not being surfaced
+
+Call out what ECC already owns.
+
+### 2. Decide what deserves interruption
+
+For each event family, answer:
+- who needs to know?
+- how fast do they need to know?
+- should this interrupt, batch, or just log?
+
+Use these defaults:
+- interrupt for release, CI, security, and owner-blocking events
+- digest for medium-signal updates
+- log-only for telemetry and low-signal lifecycle markers
+
+### 3. Collapse duplicates before adding channels
+
+Look for:
+- the same PR event appearing in GitHub, Linear, and local logs
+- repeated hook notifications for the same failure
+- comments or status churn that should be summarized instead of forwarded raw
+- channels that duplicate each other without adding a better action path
+
+Prefer:
+- one canonical summary
+- one owner
+- one primary channel
+- one fallback path
+
+### 4. Design the ECC-native workflow
+
+For each real notification need, define:
+- **source**
+- **gate**
+- **shape**: immediate alert, digest, queue, or dashboard-only
+- **channel**
+- **action**
+
+If ECC already has the primitive, prefer:
+- a skill for operator triage
+- a hook for automatic emission/enforcement
+- an agent for delegated classification
+- an MCP/connector only when a real bridge is missing
+
+### 5. Return an action-biased design
+
+End with:
+- what to keep
+- what to suppress
+- what to merge
+- what ECC should wrap next
+
+## Output Format
+
+```text
+CURRENT SURFACE
+- sources
+- channels
+- duplicates
+- gaps
+
+EVENT MODEL
+- critical
+- high
+- medium
+- low
+
+ROUTING PLAN
+- source -> channel
+- why
+- operator owner
+
+CONSOLIDATION
+- suppress
+- merge
+- canonical summaries
+
+NEXT ECC MOVE
+- skill / hook / agent / MCP
+- exact workflow to build next
+```
+
+## Recommendation Rules
+
+- prefer one strong lane over many weak ones
+- prefer digests for medium and low-signal updates
+- prefer hooks when the signal should emit automatically
+- prefer operator skills when the work is triage, routing, and review-first decision-making
+- prefer `project-flow-ops` when the root cause is backlog / PR coordination rather than alerts
+- prefer `workspace-surface-audit` when the user first needs a source inventory
+- if desktop notifications are enough, do not invent an unnecessary external bridge
+
+## Good Use Cases
+
+- "We have GitHub, Linear, and local hook alerts, but no single operator flow"
+- "Our CI failures are noisy and people ignore them"
+- "I want one notification policy across Claude, OpenCode, and Codex surfaces"
+- "Figure out what should interrupt versus land in a digest"
+- "Collapse overlapping notification PR ideas into one canonical ECC lane"
+
+## Related Skills
+
+- `workspace-surface-audit`
+- `project-flow-ops`
+- `github-ops`
+- `knowledge-ops`
+- `customer-billing-ops` when the notification pain is billing/customer operations rather than engineering

package/packs/full-harness/rendered/.claude/skills/uspto-database/SKILL.md

@@ -0,0 +1,176 @@
+---
+name: uspto-database
+description: USPTO patent and trademark data workflow for official record lookup, PatentSearch queries, TSDR checks, assignment data, and reproducible IP research logs.
+---
+
+# USPTO Database
+
+Use this skill when a task needs official United States patent or trademark
+records from USPTO systems.
+
+## When to Use
+
+- Searching granted patents or pre-grant publications.
+- Checking patent application status, file-wrapper data, assignments, or
+  public prosecution history.
+- Looking up trademark status, documents, or assignment history.
+- Building reproducible prior-art, portfolio, or IP landscape research logs.
+- Comparing USPTO records with secondary tools such as Google Patents,
+  Lens.org, Semantic Scholar, or company patent pages.
+
+Do not use this skill to give legal advice. Treat it as a data-gathering and
+record-verification workflow.
+
+## Source Selection
+
+Prefer official USPTO or USPTO-supported surfaces first:
+
+- Open Data Portal (ODP): current home for migrated USPTO datasets and APIs.
+- Patent File Wrapper: public patent application bibliographic data and file
+  wrapper records.
+- PatentSearch API: PatentsView search API for granted patents and pre-grant
+  publication datasets.
+- TSDR Data API: trademark status and document retrieval.
+- Patent and Trademark Assignment Search: ownership transfer records.
+- PTAB data in ODP: Patent Trial and Appeal Board proceedings.
+
+Use secondary sources only as convenience indexes. When the answer matters,
+cross-check the official record.
+
+## Authentication and Secrets
+
+Many USPTO API flows require an API key. Store keys in environment variables or
+a secret manager, never in committed files or pasted transcripts.
+
+Common environment names:
+
+```bash
+export USPTO_API_KEY="..."
+export PATENTSVIEW_API_KEY="..."
+```
+
+For PatentSearch, send the key with the `X-Api-Key` header. For TSDR, follow
+the current USPTO API Manager instructions and rate-limit guidance.
+
+## PatentSearch Workflow
+
+Use PatentSearch for broad patent and pre-grant publication search when the
+question is about trends, inventors, assignees, classifications, dates, or
+portfolio slices.
+
+Workflow:
+
+1. Identify the endpoint from the current PatentSearch reference or Swagger UI.
+2. Build a JSON query with explicit filters.
+3. Request only the fields needed for the analysis.
+4. Sort and paginate deterministically.
+5. Record the endpoint, query body, date, data currency note, and result count.
+
+Python request skeleton:
+
+```python
+import os
+import requests
+
+API_KEY = os.environ["PATENTSVIEW_API_KEY"]
+BASE = "https://search.patentsview.org/api/v1"
+
+payload = {
+    "q": {
+        "_and": [
+            {"patent_date": {"_gte": "2024-01-01"}},
+            {"assignees.assignee_organization": {"_text_any": ["Google", "Alphabet"]}},
+        ]
+    },
+    "f": ["patent_id", "patent_title", "patent_date"],
+    "s": [{"patent_date": "desc"}],
+    "o": {"per_page": 100, "page": 1},
+}
+
+response = requests.post(
+    f"{BASE}/patent/",
+    headers={"X-Api-Key": API_KEY, "Content-Type": "application/json"},
+    json=payload,
+    timeout=30,
+)
+response.raise_for_status()
+print(response.json())
+```
+
+Before reusing a query, verify current endpoint names, field paths, request
+parameters, and API-key availability in the live PatentSearch docs.
+
+## Trademark/TSDR Workflow
+
+Use TSDR when the task needs trademark case status, documents, images, owner
+history, or prosecution events.
+
+Workflow:
+
+1. Normalize the serial number or registration number.
+2. Check the current TSDR API instructions and required API-key header.
+3. Fetch status first, then documents only if needed.
+4. Respect the lower rate limit for PDF, ZIP, and multi-case downloads.
+5. Capture retrieval date and serial/registration identifier in the output.
+
+For large trademark pulls, prefer documented bulk-data flows rather than
+screen-scraping public pages.
+
+## File Wrapper and Prosecution History
+
+For application status, transaction history, and prosecution documents:
+
+- Start with ODP Patent File Wrapper search.
+- Use exact identifiers when available: application number, publication number,
+  patent number, or party name.
+- Record whether the record is a granted patent, pre-grant publication, or
+  pending application.
+- Cross-check document dates and status against the record detail page before
+  citing them.
+
+## Assignment Workflow
+
+For patent or trademark ownership:
+
+1. Search official assignment data by patent/application/registration number,
+   assignor, assignee, or reel/frame when available.
+2. Record conveyance text, execution date, recordation date, and parties.
+3. Distinguish assignment records from current legal ownership conclusions.
+4. If ownership is material, flag the result for attorney or subject-matter
+   review.
+
+## Reproducible Output
+
+Every USPTO research pass should include a log table:
+
+```markdown
+| Source | Date searched | Identifier/query | Filters | Results | Notes |
+| --- | --- | --- | --- | ---: | --- |
+| PatentSearch | 2026-05-11 | `assignee=Alphabet AND date>=2024` | patent endpoint | 118 | API docs checked before run |
+| TSDR | 2026-05-11 | `serial=90000000` | status only | 1 | API-key flow, no document bulk pull |
+```
+
+For final writeups, separate:
+
+- official record facts
+- inferred analysis
+- secondary-source convenience matches
+- unresolved gaps or records that require legal review
+
+## Review Checklist
+
+- Did you use an official USPTO or USPTO-supported source first?
+- Did you verify current endpoint and field names before running code?
+- Are API keys kept out of files, shell history, and output logs?
+- Does the query log include the date searched and exact request shape?
+- Are rate limits respected?
+- Are legal conclusions avoided or explicitly escalated?
+- Are secondary sources labeled as secondary?
+
+## References
+
+- [USPTO APIs catalog](https://developer.uspto.gov/api-catalog)
+- [USPTO Open Data Portal](https://data.uspto.gov/)
+- [PatentSearch API reference](https://search.patentsview.org/docs/docs/Search%20API/SearchAPIReference/)
+- [PatentSearch API updates](https://search.patentsview.org/docs/)
+- [TSDR API bulk download FAQ](https://developer.uspto.gov/faq/tsdr-api-bulk-download)