claudecode-omc 5.6.4 → 5.6.6

package/bundled/upstream/ecc/skills/fsharp-testing/SKILL.md

@@ -0,0 +1,280 @@
+---
+name: fsharp-testing
+description: F# testing patterns with xUnit, FsUnit, Unquote, FsCheck property-based testing, integration tests, and test organization best practices.
+origin: ECC
+---
+
+# F# Testing Patterns
+
+Comprehensive testing patterns for F# applications using xUnit, FsUnit, Unquote, FsCheck, and modern .NET testing practices.
+
+## When to Activate
+
+- Writing new tests for F# code
+- Reviewing test quality and coverage
+- Setting up test infrastructure for F# projects
+- Debugging flaky or slow tests
+
+## Test Framework Stack
+
+| Tool | Purpose |
+|---|---|
+| **xUnit** | Test framework (standard .NET ecosystem choice) |
+| **FsUnit.xUnit** | F#-friendly assertion syntax for xUnit |
+| **Unquote** | Assertion library using F# quotations for clear failure messages |
+| **FsCheck.xUnit** | Property-based testing integrated with xUnit |
+| **NSubstitute** | Mocking .NET dependencies |
+| **Testcontainers** | Real infrastructure in integration tests |
+| **WebApplicationFactory** | ASP.NET Core integration tests |
+
+## Unit Tests with xUnit + FsUnit
+
+### Basic Test Structure
+
+```fsharp
+module OrderServiceTests
+
+open Xunit
+open FsUnit.Xunit
+
+[<Fact>]
+let ``create sets status to Pending`` () =
+    let order = Order.create "cust-1" [ validItem ]
+    order.Status |> should equal Pending
+
+[<Fact>]
+let ``confirm changes status to Confirmed`` () =
+    let order = Order.create "cust-1" [ validItem ]
+    let confirmed = Order.confirm order
+    confirmed.Status |> should be (ofCase <@ Confirmed @>)
+```
+
+### Assertions with Unquote
+
+Unquote uses F# quotations so failure messages show the full expression that failed, not just "expected X got Y".
+
+```fsharp
+module OrderValidationTests
+
+open Xunit
+open Swensen.Unquote
+
+[<Fact>]
+let ``PlaceOrder returns success when request is valid`` () =
+    let request = { CustomerId = "cust-123"; Items = [ validItem ] }
+    let result = OrderService.placeOrder request
+    test <@ Result.isOk result @>
+
+[<Fact>]
+let ``order total sums item prices`` () =
+    let items = [ { Sku = "A"; Quantity = 2; Price = 10m }
+                  { Sku = "B"; Quantity = 1; Price = 5m } ]
+    let total = Order.calculateTotal items
+    test <@ total = 25m @>
+
+[<Fact>]
+let ``validated email rejects empty input`` () =
+    let result = ValidatedEmail.create ""
+    test <@ Result.isError result @>
+```
+
+### Async Tests
+
+```fsharp
+[<Fact>]
+let ``PlaceOrder returns success when request is valid`` () = task {
+    let deps = createTestDeps ()
+    let request = { CustomerId = "cust-123"; Items = [ validItem ] }
+
+    let! result = OrderService.placeOrder deps request
+
+    test <@ Result.isOk result @>
+}
+
+[<Fact>]
+let ``PlaceOrder returns error when items are empty`` () = task {
+    let deps = createTestDeps ()
+    let request = { CustomerId = "cust-123"; Items = [] }
+
+    let! result = OrderService.placeOrder deps request
+
+    test <@ Result.isError result @>
+}
+```
+
+### Parameterized Tests with Theory
+
+```fsharp
+[<Theory>]
+[<InlineData("")>]
+[<InlineData("   ")>]
+let ``PlaceOrder rejects empty customer ID`` (customerId: string) =
+    let request = { CustomerId = customerId; Items = [ validItem ] }
+    let result = OrderService.placeOrder request
+    result |> should be (ofCase <@ Error @>)
+
+[<Theory>]
+[<InlineData("", false)>]
+[<InlineData("a", false)>]
+[<InlineData("user@example.com", true)>]
+[<InlineData("user+tag@example.co.uk", true)>]
+let ``IsValidEmail returns expected result`` (email: string, expected: bool) =
+    test <@ EmailValidator.isValid email = expected @>
+```
+
+## Property-Based Testing with FsCheck
+
+### Using FsCheck.xUnit
+
+```fsharp
+open FsCheck
+open FsCheck.Xunit
+
+[<Property>]
+let ``order total is always non-negative`` (items: NonEmptyList<PositiveInt * decimal>) =
+    let orderItems =
+        items.Get
+        |> List.map (fun (qty, price) ->
+            { Sku = "SKU"; Quantity = qty.Get; Price = abs price })
+    let total = Order.calculateTotal orderItems
+    total >= 0m
+
+[<Property>]
+let ``serialization roundtrips`` (order: Order) =
+    let json = JsonSerializer.Serialize order
+    let deserialized = JsonSerializer.Deserialize<Order> json
+    deserialized = order
+```
+
+### Custom Generators
+
+```fsharp
+type OrderGenerators =
+    static member ValidEmail () =
+        gen {
+            let! user = Gen.elements [ "alice"; "bob"; "carol" ]
+            let! domain = Gen.elements [ "example.com"; "test.org" ]
+            return $"{user}@{domain}"
+        }
+        |> Arb.fromGen
+
+[<Property(Arbitrary = [| typeof<OrderGenerators> |])>]
+let ``valid emails pass validation`` (email: string) =
+    EmailValidator.isValid email
+```
+
+## Mocking Dependencies
+
+### Function Stubs (Preferred)
+
+```fsharp
+let createTestDeps () =
+    let mutable savedOrders = []
+    { FindOrder = fun id -> task { return Map.tryFind id testData }
+      SaveOrder = fun order -> task { savedOrders <- order :: savedOrders }
+      SendNotification = fun _ -> Task.CompletedTask }
+
+[<Fact>]
+let ``PlaceOrder saves the confirmed order`` () = task {
+    let mutable saved = []
+    let deps =
+        { createTestDeps () with
+            SaveOrder = fun order -> task { saved <- order :: saved } }
+
+    let! _ = OrderService.placeOrder deps validRequest
+
+    test <@ saved.Length = 1 @>
+}
+```
+
+### NSubstitute for .NET Interfaces
+
+```fsharp
+open NSubstitute
+
+[<Fact>]
+let ``calls repository with correct ID`` () = task {
+    let repo = Substitute.For<IOrderRepository>()
+    repo.FindByIdAsync(Arg.Any<Guid>(), Arg.Any<CancellationToken>())
+        .Returns(Task.FromResult(Some testOrder))
+
+    let service = OrderService(repo)
+    let! _ = service.GetOrder(testOrder.Id, CancellationToken.None)
+
+    do! repo.Received(1).FindByIdAsync(testOrder.Id, Arg.Any<CancellationToken>())
+}
+```
+
+## ASP.NET Core Integration Tests
+
+```fsharp
+type OrderApiTests (factory: WebApplicationFactory<Program>) =
+    interface IClassFixture<WebApplicationFactory<Program>>
+
+    let client =
+        factory.WithWebHostBuilder(fun builder ->
+            builder.ConfigureServices(fun services ->
+                services.RemoveAll<DbContextOptions<AppDbContext>>() |> ignore
+                services.AddDbContext<AppDbContext>(fun options ->
+                    options.UseInMemoryDatabase("TestDb") |> ignore) |> ignore))
+            .CreateClient()
+
+    [<Fact>]
+    member _.``GET order returns 404 when not found`` () = task {
+        let! response = client.GetAsync($"/api/orders/{Guid.NewGuid()}")
+        test <@ response.StatusCode = HttpStatusCode.NotFound @>
+    }
+```
+
+## Test Organization
+
+```
+tests/
+  MyApp.Tests/
+    Unit/
+      OrderServiceTests.fs
+      PaymentServiceTests.fs
+    Integration/
+      OrderApiTests.fs
+      OrderRepositoryTests.fs
+    Properties/
+      OrderPropertyTests.fs
+    Helpers/
+      TestData.fs
+      TestDeps.fs
+```
+
+## Common Anti-Patterns
+
+| Anti-Pattern | Fix |
+|---|---|
+| Testing implementation details | Test behavior and outcomes |
+| Mutable shared test state | Fresh state per test |
+| `Thread.Sleep` in async tests | Use `Task.Delay` with timeout, or polling helpers |
+| Asserting on `sprintf` output | Assert on typed values and pattern matches |
+| Ignoring `CancellationToken` | Always pass and verify cancellation |
+| Skipping property-based tests | Use FsCheck for any function with clear invariants |
+
+## Related Skills
+
+- `dotnet-patterns` - Idiomatic .NET patterns, dependency injection, and architecture
+- `csharp-testing` - C# testing patterns (shared infrastructure like WebApplicationFactory and Testcontainers applies to F# too)
+
+## Running Tests
+
+```bash
+# Run all tests
+dotnet test
+
+# Run with coverage
+dotnet test --collect:"XPlat Code Coverage"
+
+# Run specific project
+dotnet test tests/MyApp.Tests/
+
+# Filter by test name
+dotnet test --filter "FullyQualifiedName~OrderService"
+
+# Watch mode during development
+dotnet watch test --project tests/MyApp.Tests/
+```

package/bundled/upstream/ecc/skills/gateguard/SKILL.md

@@ -94,6 +94,10 @@ Triggers on: `rm -rf`, `git reset --hard`, `git push --force`, `drop table`, etc
 
 The hook at `scripts/hooks/gateguard-fact-force.js` is included in this plugin. Enable it via hooks.json.
 
+If GateGuard blocks setup or repair work, start the session with
+`ECC_GATEGUARD=off`. For hook-level control, keep using
+`ECC_DISABLED_HOOKS` with the GateGuard hook ID.
+
 ### Option B: Full package with config
 
 ```bash

package/bundled/upstream/ecc/skills/hermes-imports/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: hermes-imports
+description: Convert local Hermes operator workflows into sanitized ECC skills and release-pack artifacts. Use when preparing a Hermes workflow for public ECC reuse without leaking private workspace state, credentials, or local-only paths.
+origin: ECC
+---
+
+# Hermes Imports
+
+Use this skill when turning a repeated Hermes workflow into something safe to ship in ECC.
+
+Hermes is the operator shell. ECC is the reusable workflow layer. Imports should move stable patterns from Hermes into ECC without moving private state.
+
+## When To Use
+
+- A Hermes workflow has repeated enough times to become reusable.
+- A local operator prompt should become a public ECC skill.
+- A launch, content, research, or engineering workflow needs sanitized handoff docs.
+- A workflow mentions local paths, credentials, personal datasets, or private account names that must be removed before publication.
+
+## Import Rules
+
+- Convert local paths to repo-relative paths or placeholders.
+- Replace live account names with role labels such as `operator`, `default profile`, or `workspace owner`.
+- Describe credential requirements by provider name only.
+- Keep examples narrow and operational.
+- Do not ship raw workspace exports, tokens, OAuth files, health data, CRM data, or finance data.
+- If the workflow requires private state to make sense, keep it local.
+
+## Sanitization Checklist
+
+Before committing an imported workflow, scan for:
+
+- absolute paths such as `/Users/...`
+- `~/.hermes` paths unless the doc is explicitly explaining local setup
+- API keys, tokens, cookies, OAuth files, or bearer strings
+- phone numbers, private email addresses, and personal contact graphs
+- client names, family names, or account names that are not already public
+- revenue, health, or CRM details
+- raw logs that include tool output from private systems
+
+## Conversion Pattern
+
+1. Identify the repeatable operator loop.
+2. Strip private inputs and outputs.
+3. Rewrite local paths as repo-relative examples.
+4. Turn one-off instructions into a `When To Use` section and a short process.
+5. Add concrete output requirements.
+6. Run a secret and local-path scan before opening a PR.
+
+## Example: Launch Handoff
+
+Local Hermes prompt:
+
+```text
+Read my local workspace files and finalize launch copy.
+```
+
+ECC-safe version:
+
+```text
+Use the public release pack under docs/releases/<version>/.
+Return one X thread, one LinkedIn post, one recording checklist, and the missing assets list.
+```
+
+## Example: Quiet-Hours Operator Job
+
+Local Hermes job:
+
+```text
+Run my private inbox, finance, and content checks overnight.
+```
+
+ECC-safe version:
+
+```text
+Describe the scheduler policy, the quiet-hours window, the escalation rules, and the categories of checks. Do not include private data sources or credentials.
+```
+
+## Output Contract
+
+Return:
+
+- candidate ECC skill name
+- sanitized workflow summary
+- required public inputs
+- private inputs removed
+- remaining risks
+- files that should be created or updated

package/bundled/upstream/ecc/skills/homelab-network-readiness/SKILL.md

@@ -0,0 +1,169 @@
+---
+name: homelab-network-readiness
+description: Readiness checklist for homelab VLAN segmentation, local DNS filtering, and WireGuard-style remote access before changing router, firewall, DHCP, or VPN configuration.
+origin: community
+---
+
+# Homelab Network Readiness
+
+Use this skill before changing a home or small-lab network that mixes VLANs,
+Pi-hole or another local DNS resolver, firewall rules, and remote VPN access.
+
+This is a planning and review skill. Do not turn it into copy-paste router,
+firewall, or VPN configuration unless the target platform, current topology,
+rollback path, console access, and maintenance window are all known.
+
+## When to Use
+
+- Preparing to split a flat network into trusted, IoT, guest, server, or
+  management VLANs.
+- Moving DHCP clients to Pi-hole, AdGuard Home, Unbound, or another local DNS
+  resolver.
+- Adding WireGuard, Tailscale, ZeroTier, OpenVPN, or router-native VPN access.
+- Reviewing whether a homelab change can lock the operator out of the gateway,
+  switch, access point, DNS server, or VPN server.
+- Turning an informal home-network idea into a staged migration plan with
+  validation evidence.
+
+## Safety Rules
+
+- Keep the first answer read-only: inventory, risks, staged plan, validation,
+  and rollback.
+- Do not expose gateway admin panels, DNS resolvers, SSH, NAS consoles, or VPN
+  management UIs directly to the public internet.
+- Do not provide firewall, NAT, VLAN, DHCP, or VPN commands without a confirmed
+  platform and a rollback procedure.
+- Require out-of-band or same-room console access before changing management
+  VLANs, trunk ports, firewall default policies, or DHCP/DNS settings.
+- Keep a working path back to the internet before pointing the whole network at
+  a new DNS resolver or VPN route.
+- Treat IoT, guest, camera, and lab-server networks as different trust zones
+  until the operator explicitly chooses otherwise.
+
+## Required Inventory
+
+Collect this before giving implementation steps:
+
+| Area | Questions |
+| --- | --- |
+| Internet edge | What is the modem or ONT? Is the ISP router bridged or still routing? |
+| Gateway | What routes, firewalls, handles DHCP, and terminates VPNs? |
+| Switching | Which switch ports are uplinks, access ports, trunks, or unmanaged? |
+| Wi-Fi | Which SSIDs map to which networks, and are APs wired or mesh? |
+| Addressing | What subnets exist today, and which ranges conflict with VPN sites? |
+| DNS/DHCP | Which service currently hands out leases and resolver addresses? |
+| Management | How will the operator reach the gateway, switch, and AP after changes? |
+| Recovery | What can be reverted locally if DNS, DHCP, VLANs, or VPN routes break? |
+
+## VLAN And Trust-Zone Plan
+
+Start with intent rather than vendor syntax.
+
+| Zone | Typical contents | Default policy |
+| --- | --- | --- |
+| Trusted | Laptops, phones, admin workstations | Can reach shared services and management only when needed |
+| Servers | NAS, Home Assistant, lab hosts, DNS resolver | Accepts narrow inbound flows from trusted clients |
+| IoT | TVs, smart plugs, cameras, speakers | Internet access plus explicit exceptions only |
+| Guest | Visitor devices | Internet-only, no LAN reachability |
+| Management | Gateway, switches, APs, controllers | Reachable only from trusted admin devices |
+| VPN | Remote clients | Same or narrower access than trusted clients |
+
+Before recommending VLAN IDs or subnets, confirm:
+
+1. The gateway supports inter-VLAN routing and firewall rules.
+2. The switch supports the required tagged and untagged port behavior.
+3. The APs can map SSIDs to VLANs.
+4. The operator knows which port they are connected through during the change.
+5. The management network remains reachable after trunk and SSID changes.
+
+## DNS Filtering Readiness
+
+Pi-hole or another local resolver should be introduced as a dependency, not as a
+single point of failure.
+
+1. Give the resolver a reserved address before using it in DHCP options.
+2. Confirm it can resolve public DNS and local `home.arpa` names.
+3. Keep the gateway or a second resolver available as a temporary fallback.
+4. Test one client or one VLAN before changing every DHCP scope.
+5. Document which networks may bypass filtering and why.
+6. Check that blocking rules do not break captive portals, work VPNs, firmware
+   updates, or medical/security devices.
+
+Useful validation evidence:
+
+```text
+Client gets expected DHCP lease
+Client receives expected DNS resolver
+Public DNS lookup succeeds
+Local home.arpa lookup succeeds
+Blocked test domain is blocked only where intended
+Gateway and DNS admin interfaces are not reachable from guest or IoT networks
+```
+
+## Remote Access Readiness
+
+For WireGuard-style access, decide what the VPN is allowed to reach before
+generating keys or opening ports.
+
+| Mode | Use when | Risk notes |
+| --- | --- | --- |
+| Split tunnel to one subnet | Remote admin for NAS or lab hosts | Keep route list narrow |
+| Split tunnel to trusted services | Access selected apps by IP or DNS | Requires precise firewall rules |
+| Full tunnel | Untrusted networks or travel | More bandwidth and DNS responsibility |
+| Overlay VPN | Simpler remote access with identity controls | Still needs ACL review |
+
+Do not recommend port forwarding until the operator confirms:
+
+- The VPN endpoint is patched and actively maintained.
+- The forwarded port goes only to the VPN service, not an admin UI.
+- Dynamic DNS, public IP behavior, and ISP CGNAT status are understood.
+- Peer keys can be revoked without rebuilding the whole network.
+- Logs or connection status can verify who connected and when.
+
+## Change Sequence
+
+Prefer small, reversible changes:
+
+1. Snapshot the current topology, IP plan, DHCP settings, DNS settings, and
+   firewall rules.
+2. Reserve infrastructure addresses for gateway, DNS, controller, APs, NAS, and
+   VPN endpoint.
+3. Create the new zone or VLAN without moving critical devices.
+4. Move one test client and validate DHCP, DNS, routing, internet, and block
+   behavior.
+5. Add narrow firewall exceptions for required flows.
+6. Move one low-risk device group.
+7. Add VPN access with the narrowest route and firewall policy that satisfies
+   the use case.
+8. Document final state, known exceptions, and rollback commands or UI steps.
+
+## Review Checklist
+
+- Each network has a reason to exist and a clear trust boundary.
+- No management interface is reachable from guest, IoT, or the public internet.
+- DNS failure does not take down the operator's ability to recover locally.
+- DHCP scope changes were tested on one client before broad rollout.
+- VPN clients receive only the routes and DNS settings they need.
+- Firewall rules are default-deny between zones, with named exceptions.
+- The operator can still reach gateway, switch, AP, DNS, and VPN admin surfaces.
+- Rollback is documented in the same vocabulary as the chosen platform UI or
+  CLI.
+
+## Anti-Patterns
+
+- Segmenting networks before knowing which switch ports and SSIDs carry which
+  VLANs.
+- Moving the admin workstation off the only reachable management network.
+- Pointing all DHCP scopes at a Pi-hole before testing fallback DNS.
+- Publishing NAS, DNS, router, or hypervisor management directly to the
+  internet.
+- Treating VPN access as equivalent to full trusted-LAN access.
+- Adding allow-all firewall rules temporarily and forgetting to remove them.
+- Copying commands from another vendor or firmware version without checking the
+  exact platform syntax.
+
+## See Also
+
+- Skill: `homelab-network-setup`
+- Skill: `network-config-validation`
+- Skill: `network-interface-health`

package/bundled/upstream/ecc/skills/homelab-network-setup/SKILL.md

@@ -0,0 +1,129 @@
+---
+name: homelab-network-setup
+description: Practical home and homelab network planning for gateways, switches, access points, IP ranges, DHCP reservations, DNS, cabling, and common beginner mistakes.
+origin: community
+---
+
+# Homelab Network Setup
+
+Use this skill to design a home or small-lab network that can grow without
+needing a full rebuild.
+
+## When to Use
+
+- Planning a new home network or redesigning an ISP-router-only setup.
+- Choosing gateway, switch, and access point roles.
+- Designing IP ranges, DHCP scopes, static reservations, and DNS.
+- Preparing for future VLANs, Pi-hole, NAS, lab servers, or VPN access.
+- Troubleshooting a new network that has double NAT, unstable Wi-Fi, or changing
+  server addresses.
+
+## How It Works
+
+Start by separating device roles:
+
+```text
+Internet
+  |
+Modem or ONT
+  |
+Gateway or router      NAT, firewall, DHCP, DNS, inter-VLAN routing
+  |
+Managed switch         wired clients, AP uplinks, optional VLAN trunks
+  |
+Access points          Wi-Fi only; ideally wired backhaul
+Servers and NAS        stable addresses, DNS names, monitoring
+Clients and IoT        DHCP pools, isolated later if VLANs are available
+```
+
+Pick a gateway that matches the operator, not just the feature checklist:
+
+| Option | Best fit | Notes |
+| --- | --- | --- |
+| ISP router | Basic internet only | Limited control and often poor VLAN support |
+| UniFi gateway | Managed home network | Good UI, ecosystem lock-in |
+| OPNsense or pfSense | Flexible homelab | Strong VLAN, firewall, VPN, and DNS control |
+| MikroTik | Advanced network users | Powerful, but easy to misconfigure |
+| Linux router | Tinkerers | Document rollback before using as primary gateway |
+
+## IP Plan
+
+Avoid the most common default, `192.168.1.0/24`, when you expect to use VPNs.
+It often conflicts with hotels, offices, and ISP routers.
+
+```text
+Example small homelab plan:
+
+192.168.10.0/24  trusted clients
+192.168.20.0/24  IoT and media devices
+192.168.30.0/24  servers and NAS
+192.168.40.0/24  guest Wi-Fi
+192.168.99.0/24  network management
+
+Gateway convention: .1
+Infrastructure reservations: .2 through .49
+Dynamic DHCP pool: .50 through .240
+Spare room: .241 through .254
+```
+
+Use `home.arpa` for local names. It is reserved for home networks and avoids the
+leakage/conflict problems of ad hoc names like `home.lan`.
+
+```text
+nas.home.arpa
+pihole.home.arpa
+gateway.home.arpa
+switch-01.home.arpa
+```
+
+## DHCP And DNS
+
+- Use DHCP reservations for anything you SSH into, bookmark, monitor, or expose
+  as a service.
+- Hand out the gateway as DNS until a local resolver is intentionally deployed.
+- If using Pi-hole or another DNS filter, give it a reservation first, then point
+  DHCP DNS options at that address.
+- Keep a small static/reserved range per subnet so replacements do not collide
+  with dynamic leases.
+
+## Cabling And Wi-Fi
+
+- Prefer wired AP backhaul over mesh when you can run Ethernet.
+- Use a PoE switch for APs and cameras if the budget allows it.
+- Label both ends of each cable and keep a simple port map.
+- Put the gateway, switch, DNS server, and NAS on UPS power if outages are common.
+
+## Examples
+
+### Beginner Upgrade
+
+Goal: Keep the ISP router but stabilize a small lab.
+
+1. Set DHCP reservations for NAS, Pi, and any SSH hosts.
+2. Move local names to `home.arpa`.
+3. Disable duplicate DHCP servers on secondary routers or APs.
+4. Wire the main AP instead of relying on wireless backhaul.
+
+### VLAN-Ready Plan
+
+Goal: Prepare for future segmentation without enabling it immediately.
+
+1. Choose non-overlapping /24 ranges for trusted, IoT, servers, guest, and
+   management.
+2. Reserve .1 for the gateway and .2-.49 for infrastructure on every subnet.
+3. Buy a gateway and switch that support VLANs and inter-VLAN firewall rules.
+4. Document which SSIDs and switch ports will eventually map to each network.
+
+## Anti-Patterns
+
+- Double NAT without a reason or documentation.
+- Using `192.168.1.0/24` when VPN access is planned.
+- Dynamic addresses for NAS, Pi-hole, Home Assistant, or other service hosts.
+- Consumer routers repurposed as APs while their DHCP servers are still enabled.
+- Flat networks with cameras, smart plugs, laptops, and servers all sharing the
+  same trust boundary.
+
+## See Also
+
+- Skill: `network-interface-health`
+- Skill: `network-config-validation`