winter-super-cli 2026.5.31 → 2026.6.5

package/resources/local/ecc/skills/hexagonal-architecture/SKILL.md

@@ -0,0 +1,276 @@
+---
+name: hexagonal-architecture
+description: Design, implement, and refactor Ports & Adapters systems with clear domain boundaries, dependency inversion, and testable use-case orchestration across TypeScript, Java, Kotlin, and Go services.
+origin: ECC
+---
+
+# Hexagonal Architecture
+
+Hexagonal architecture (Ports and Adapters) keeps business logic independent from frameworks, transport, and persistence details. The core app depends on abstract ports, and adapters implement those ports at the edges.
+
+## When to Use
+
+- Building new features where long-term maintainability and testability matter.
+- Refactoring layered or framework-heavy code where domain logic is mixed with I/O concerns.
+- Supporting multiple interfaces for the same use case (HTTP, CLI, queue workers, cron jobs).
+- Replacing infrastructure (database, external APIs, message bus) without rewriting business rules.
+
+Use this skill when the request involves boundaries, domain-centric design, refactoring tightly coupled services, or decoupling application logic from specific libraries.
+
+## Core Concepts
+
+- **Domain model**: Business rules and entities/value objects. No framework imports.
+- **Use cases (application layer)**: Orchestrate domain behavior and workflow steps.
+- **Inbound ports**: Contracts describing what the application can do (commands/queries/use-case interfaces).
+- **Outbound ports**: Contracts for dependencies the application needs (repositories, gateways, event publishers, clock, UUID, etc.).
+- **Adapters**: Infrastructure and delivery implementations of ports (HTTP controllers, DB repositories, queue consumers, SDK wrappers).
+- **Composition root**: Single wiring location where concrete adapters are bound to use cases.
+
+Outbound port interfaces usually live in the application layer (or in domain only when the abstraction is truly domain-level), while infrastructure adapters implement them.
+
+Dependency direction is always inward:
+
+- Adapters -> application/domain
+- Application -> port interfaces (inbound/outbound contracts)
+- Domain -> domain-only abstractions (no framework or infrastructure dependencies)
+- Domain -> nothing external
+
+## How It Works
+
+### Step 1: Model a use case boundary
+
+Define a single use case with a clear input and output DTO. Keep transport details (Express `req`, GraphQL `context`, job payload wrappers) outside this boundary.
+
+### Step 2: Define outbound ports first
+
+Identify every side effect as a port:
+
+- persistence (`UserRepositoryPort`)
+- external calls (`BillingGatewayPort`)
+- cross-cutting (`LoggerPort`, `ClockPort`)
+
+Ports should model capabilities, not technologies.
+
+### Step 3: Implement the use case with pure orchestration
+
+Use case class/function receives ports via constructor/arguments. It validates application-level invariants, coordinates domain rules, and returns plain data structures.
+
+### Step 4: Build adapters at the edge
+
+- Inbound adapter converts protocol input to use-case input.
+- Outbound adapter maps app contracts to concrete APIs/ORM/query builders.
+- Mapping stays in adapters, not inside use cases.
+
+### Step 5: Wire everything in a composition root
+
+Instantiate adapters, then inject them into use cases. Keep this wiring centralized to avoid hidden service-locator behavior.
+
+### Step 6: Test per boundary
+
+- Unit test use cases with fake ports.
+- Integration test adapters with real infra dependencies.
+- E2E test user-facing flows through inbound adapters.
+
+## Architecture Diagram
+
+```mermaid
+flowchart LR
+  Client["Client (HTTP/CLI/Worker)"] --> InboundAdapter["Inbound Adapter"]
+  InboundAdapter -->|"calls"| UseCase["UseCase (Application Layer)"]
+  UseCase -->|"uses"| OutboundPort["OutboundPort (Interface)"]
+  OutboundAdapter["Outbound Adapter"] -->|"implements"| OutboundPort
+  OutboundAdapter --> ExternalSystem["DB/API/Queue"]
+  UseCase --> DomainModel["DomainModel"]
+```
+
+## Suggested Module Layout
+
+Use feature-first organization with explicit boundaries:
+
+```text
+src/
+  features/
+    orders/
+      domain/
+        Order.ts
+        OrderPolicy.ts
+      application/
+        ports/
+          inbound/
+            CreateOrder.ts
+          outbound/
+            OrderRepositoryPort.ts
+            PaymentGatewayPort.ts
+        use-cases/
+          CreateOrderUseCase.ts
+      adapters/
+        inbound/
+          http/
+            createOrderRoute.ts
+        outbound/
+          postgres/
+            PostgresOrderRepository.ts
+          stripe/
+            StripePaymentGateway.ts
+      composition/
+        ordersContainer.ts
+```
+
+## TypeScript Example
+
+### Port definitions
+
+```typescript
+export interface OrderRepositoryPort {
+  save(order: Order): Promise<void>;
+  findById(orderId: string): Promise<Order | null>;
+}
+
+export interface PaymentGatewayPort {
+  authorize(input: { orderId: string; amountCents: number }): Promise<{ authorizationId: string }>;
+}
+```
+
+### Use case
+
+```typescript
+type CreateOrderInput = {
+  orderId: string;
+  amountCents: number;
+};
+
+type CreateOrderOutput = {
+  orderId: string;
+  authorizationId: string;
+};
+
+export class CreateOrderUseCase {
+  constructor(
+    private readonly orderRepository: OrderRepositoryPort,
+    private readonly paymentGateway: PaymentGatewayPort
+  ) {}
+
+  async execute(input: CreateOrderInput): Promise<CreateOrderOutput> {
+    const order = Order.create({ id: input.orderId, amountCents: input.amountCents });
+
+    const auth = await this.paymentGateway.authorize({
+      orderId: order.id,
+      amountCents: order.amountCents,
+    });
+
+    // markAuthorized returns a new Order instance; it does not mutate in place.
+    const authorizedOrder = order.markAuthorized(auth.authorizationId);
+    await this.orderRepository.save(authorizedOrder);
+
+    return {
+      orderId: order.id,
+      authorizationId: auth.authorizationId,
+    };
+  }
+}
+```
+
+### Outbound adapter
+
+```typescript
+export class PostgresOrderRepository implements OrderRepositoryPort {
+  constructor(private readonly db: SqlClient) {}
+
+  async save(order: Order): Promise<void> {
+    await this.db.query(
+      "insert into orders (id, amount_cents, status, authorization_id) values ($1, $2, $3, $4)",
+      [order.id, order.amountCents, order.status, order.authorizationId]
+    );
+  }
+
+  async findById(orderId: string): Promise<Order | null> {
+    const row = await this.db.oneOrNone("select * from orders where id = $1", [orderId]);
+    return row ? Order.rehydrate(row) : null;
+  }
+}
+```
+
+### Composition root
+
+```typescript
+export const buildCreateOrderUseCase = (deps: { db: SqlClient; stripe: StripeClient }) => {
+  const orderRepository = new PostgresOrderRepository(deps.db);
+  const paymentGateway = new StripePaymentGateway(deps.stripe);
+
+  return new CreateOrderUseCase(orderRepository, paymentGateway);
+};
+```
+
+## Multi-Language Mapping
+
+Use the same boundary rules across ecosystems; only syntax and wiring style change.
+
+- **TypeScript/JavaScript**
+  - Ports: `application/ports/*` as interfaces/types.
+  - Use cases: classes/functions with constructor/argument injection.
+  - Adapters: `adapters/inbound/*`, `adapters/outbound/*`.
+  - Composition: explicit factory/container module (no hidden globals).
+- **Java**
+  - Packages: `domain`, `application.port.in`, `application.port.out`, `application.usecase`, `adapter.in`, `adapter.out`.
+  - Ports: interfaces in `application.port.*`.
+  - Use cases: plain classes (Spring `@Service` is optional, not required).
+  - Composition: Spring config or manual wiring class; keep wiring out of domain/use-case classes.
+- **Kotlin**
+  - Modules/packages mirror the Java split (`domain`, `application.port`, `application.usecase`, `adapter`).
+  - Ports: Kotlin interfaces.
+  - Use cases: classes with constructor injection (Koin/Dagger/Spring/manual).
+  - Composition: module definitions or dedicated composition functions; avoid service locator patterns.
+- **Go**
+  - Packages: `internal/<feature>/domain`, `application`, `ports`, `adapters/inbound`, `adapters/outbound`.
+  - Ports: small interfaces owned by the consuming application package.
+  - Use cases: structs with interface fields plus explicit `New...` constructors.
+  - Composition: wire in `cmd/<app>/main.go` (or dedicated wiring package), keep constructors explicit.
+
+## Anti-Patterns to Avoid
+
+- Domain entities importing ORM models, web framework types, or SDK clients.
+- Use cases reading directly from `req`, `res`, or queue metadata.
+- Returning database rows directly from use cases without domain/application mapping.
+- Letting adapters call each other directly instead of flowing through use-case ports.
+- Spreading dependency wiring across many files with hidden global singletons.
+
+## Migration Playbook
+
+1. Pick one vertical slice (single endpoint/job) with frequent change pain.
+2. Extract a use-case boundary with explicit input/output types.
+3. Introduce outbound ports around existing infrastructure calls.
+4. Move orchestration logic from controllers/services into the use case.
+5. Keep old adapters, but make them delegate to the new use case.
+6. Add tests around the new boundary (unit + adapter integration).
+7. Repeat slice-by-slice; avoid full rewrites.
+
+### Refactoring Existing Systems
+
+- **Strangler approach**: keep current endpoints, route one use case at a time through new ports/adapters.
+- **No big-bang rewrites**: migrate per feature slice and preserve behavior with characterization tests.
+- **Facade first**: wrap legacy services behind outbound ports before replacing internals.
+- **Composition freeze**: centralize wiring early so new dependencies do not leak into domain/use-case layers.
+- **Slice selection rule**: prioritize high-churn, low-blast-radius flows first.
+- **Rollback path**: keep a reversible toggle or route switch per migrated slice until production behavior is verified.
+
+## Testing Guidance (Same Hexagonal Boundaries)
+
+- **Domain tests**: test entities/value objects as pure business rules (no mocks, no framework setup).
+- **Use-case unit tests**: test orchestration with fakes/stubs for outbound ports; assert business outcomes and port interactions.
+- **Outbound adapter contract tests**: define shared contract suites at port level and run them against each adapter implementation.
+- **Inbound adapter tests**: verify protocol mapping (HTTP/CLI/queue payload to use-case input and output/error mapping back to protocol).
+- **Adapter integration tests**: run against real infrastructure (DB/API/queue) for serialization, schema/query behavior, retries, and timeouts.
+- **End-to-end tests**: cover critical user journeys through inbound adapter -> use case -> outbound adapter.
+- **Refactor safety**: add characterization tests before extraction; keep them until new boundary behavior is stable and equivalent.
+
+## Best Practices Checklist
+
+- Domain and use-case layers import only internal types and ports.
+- Every external dependency is represented by an outbound port.
+- Validation occurs at boundaries (inbound adapter + use-case invariants).
+- Use immutable transformations (return new values/entities instead of mutating shared state).
+- Errors are translated across boundaries (infra errors -> application/domain errors).
+- Composition root is explicit and easy to audit.
+- Use cases are testable with simple in-memory fakes for ports.
+- Refactoring starts from one vertical slice with behavior-preserving tests.
+- Language/framework specifics stay in adapters, never in domain rules.

package/resources/local/ecc/skills/hipaa-compliance/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: hipaa-compliance
+description: HIPAA-specific entrypoint for healthcare privacy and security work. Use when a task is explicitly framed around HIPAA, PHI handling, covered entities, BAAs, breach posture, or US healthcare compliance requirements.
+origin: ECC direct-port adaptation
+version: "1.0.0"
+---
+
+# HIPAA Compliance
+
+Use this as the HIPAA-specific entrypoint when a task is clearly about US healthcare compliance. This skill intentionally stays thin and canonical:
+
+- `healthcare-phi-compliance` remains the primary implementation skill for PHI/PII handling, data classification, audit logging, encryption, and leak prevention.
+- `healthcare-reviewer` remains the specialized reviewer when code, architecture, or product behavior needs a healthcare-aware second pass.
+- `security-review` still applies for general auth, input-handling, secrets, API, and deployment hardening.
+
+## When to Use
+
+- The request explicitly mentions HIPAA, PHI, covered entities, business associates, or BAAs
+- Building or reviewing US healthcare software that stores, processes, exports, or transmits PHI
+- Assessing whether logging, analytics, LLM prompts, storage, or support workflows create HIPAA exposure
+- Designing patient-facing or clinician-facing systems where minimum necessary access and auditability matter
+
+## How It Works
+
+Treat HIPAA as an overlay on top of the broader healthcare privacy skill:
+
+1. Start with `healthcare-phi-compliance` for the concrete implementation rules.
+2. Apply HIPAA-specific decision gates:
+   - Is this data PHI?
+   - Is this actor a covered entity or business associate?
+   - Does a vendor or model provider require a BAA before touching the data?
+   - Is access limited to the minimum necessary scope?
+   - Are read/write/export events auditable?
+3. Escalate to `healthcare-reviewer` if the task affects patient safety, clinical workflows, or regulated production architecture.
+
+## HIPAA-Specific Guardrails
+
+- Never place PHI in logs, analytics events, crash reports, prompts, or client-visible error strings.
+- Never expose PHI in URLs, browser storage, screenshots, or copied example payloads.
+- Require authenticated access, scoped authorization, and audit trails for PHI reads and writes.
+- Treat third-party SaaS, observability, support tooling, and LLM providers as blocked-by-default until BAA status and data boundaries are clear.
+- Follow minimum necessary access: the right user should only see the smallest PHI slice needed for the task.
+- Prefer opaque internal IDs over names, MRNs, phone numbers, addresses, or other identifiers.
+
+## Examples
+
+### Example 1: Product request framed as HIPAA
+
+User request:
+
+> Add AI-generated visit summaries to our clinician dashboard. We serve US clinics and need to stay HIPAA compliant.
+
+Response pattern:
+
+- Activate `hipaa-compliance`
+- Use `healthcare-phi-compliance` to review PHI movement, logging, storage, and prompt boundaries
+- Verify whether the summarization provider is covered by a BAA before any PHI is sent
+- Escalate to `healthcare-reviewer` if the summaries influence clinical decisions
+
+### Example 2: Vendor/tooling decision
+
+User request:
+
+> Can we send support transcripts and patient messages into our analytics stack?
+
+Response pattern:
+
+- Assume those messages may contain PHI
+- Block the design unless the analytics vendor is approved for HIPAA-bound workloads and the data path is minimized
+- Require redaction or a non-PHI event model when possible
+
+## Related Skills
+
+- `healthcare-phi-compliance`
+- `healthcare-reviewer`
+- `healthcare-emr-patterns`
+- `healthcare-eval-harness`
+- `security-review`

package/resources/local/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/resources/local/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`