oh-my-agent-commandcode 0.0.0-stage → 20.38.4

package/skills/oma-mobile/variants/swift-ios/stack.yaml

@@ -0,0 +1,25 @@
+# yaml-language-server: $schema=../stack.schema.json
+language: swift
+framework: swiftui
+ui: swiftui
+state: observation
+navigation: navigationstack
+http_client: urlsession
+local_storage: swiftdata
+api_generator: swift-openapi-generator
+api_spec: Core/Networking/openapi.yaml
+response_cache: hyperoslo-cache
+structure: App/Core/Features/Shared
+source: variant
+
+verify:
+  detect: Package.swift
+  syntax:
+    cmd: "swift build"
+    skip_if_missing: swift
+  tests:
+    cmd: "swift test"
+    # Substring match must cover both XCTest ("Test Suite 'All tests' passed")
+    # and Swift Testing ("Test run with N tests passed") summaries.
+    pass_signal: "passed"
+    skip_if_missing: swift

package/skills/oma-mobile/variants/swift-ios/tech-stack.md

@@ -0,0 +1,174 @@
+# Mobile Agent - Tech Stack Reference (Swift iOS Native)
+
+Starter reference for the selected platform. Preserve existing project choices. The caching implementation below applies only when caching is required; do not add it for an unrelated screen or widget change.
+
+## Framework: SwiftUI + Observation
+
+- **Language**: Swift 6.0+ floor, strict-concurrency clean (current stable is Swift 6.3, July 2026)
+- **UI Framework**: SwiftUI
+- **State Management**: Observation framework (`@Observable`, iOS 17+)
+- **Concurrency**: Swift async/await + structured concurrency (`Task`, `TaskGroup`, `AsyncStream`)
+- **Minimum Deployment**: iOS 17.0
+- **Tooling**: Xcode 16+ floor (current stable is Xcode 26, July 2026), Swift Package Manager (SwiftPM)
+
+`@Observable` replaces `ObservableObject`/`@Published` for SwiftUI view models. The macro synthesizes observation tracking at compile time with zero boilerplate and no Combine dependency.
+
+## API Client: swift-openapi-generator
+
+| Component | Package |
+|-----------|---------|
+| Code generator | `apple/swift-openapi-generator` |
+| Runtime types | `apple/swift-openapi-runtime` |
+| URLSession transport | `apple/swift-openapi-urlsession` |
+
+The generated `Client` is the **only** way to call the backend API; never hand-roll
+`URLRequest`/`JSONDecoder` for endpoints covered by the spec. **Regenerate, don't hand-edit**
+generated sources.
+
+### Two codegen modes — both valid; `/stack-set` records the project's choice
+
+`swift-openapi-generator` runs in one of two modes — **both build a real app**; the choice is
+a workflow trade-off, not a capability one. This variant is the baseline default; the
+<!-- oma-docs:ignore-start -->
+per-project `stack/stack.yaml` (seeded by `/stack-set`) pins which mode the repo uses.
+
+| Mode | Mechanics | Trade-off |
+|------|-----------|-----------|
+| **Build plugin** (Apple-recommended default) | Generator runs during the build; output is ephemeral (not committed). Declared in `Package.swift` `plugins:` for SwiftPM targets, **and works in Xcode app targets too** — Xcode requires "trust & enable" for the plugin (Xcode Cloud needs a post-clone script to bypass fingerprint validation). Spec vendored at `Core/Networking/openapi.yaml`. | Zero commit noise, always in sync; but extra Xcode/CI setup, generated diffs invisible in review, regen on every clean build. |
+| **Committed (command plugin / CLI)** | Apple's documented fallback "if the build plugin cannot be used". Run `swift package generate-code-from-openapi` (or a task: `mise` / `make` / script) → write `Core/Networking/Generated/` → **commit** it; the build sees plain checked-in source. | Generated code is reviewable and CI is simpler; but a human must remember to regenerate + commit on spec changes. |
+<!-- oma-docs:ignore-end -->
+
+### Where the API contract comes from
+
+The backend owns the contract; the iOS app is purely a **consumer** and never edits the spec.
+The spec is produced upstream (FastAPI, NestJS Swagger, or hand-maintained) and fed to the
+generator. In a monorepo a single task (e.g. `mise gen:api`) often chains the backend export
+and the mobile generation so the spec stays linked end-to-end. Either way, breaking schema
+changes surface as Swift compile errors after regeneration, not at runtime.
+
+> **3.0 vs 3.1 gotcha.** `swift-openapi-generator` drops OpenAPI **3.1** `anyOf:[X,{type:null}]`
+> nullable fields. If the backend emits 3.1 (FastAPI does), down-convert to **3.0.3** before
+> generating — 3.0's `nullable:true` round-trips correctly. Don't "upgrade" it back.
+
+## Response Cache: hyperoslo/Cache
+
+| Component | Package |
+|-----------|---------|
+| Hybrid (memory + disk) cache | `hyperoslo/Cache` |
+
+When response caching is required, implement it at the Repository (Service) layer, backed by `hyperoslo/Cache`. The generated `Components.Schemas.*` types are `Codable`, so they are cached directly through `Cache`'s `Storage<Key, Value>` with `TransformerFactory.forCodable`. This memoizes **decoded models**, not raw bytes — the cache sits between the `@Observable` view model and the generated `Client`, never inside a `ClientMiddleware`.
+
+**Placement rule — Repository layer, not transport.** Do **not** intercept `HTTPBody` in a `ClientMiddleware` to cache responses: `HTTPBody` is a single-consumption async stream, so capturing it for replay corrupts the request/response lifecycle. Cache the typed result *after* the generated `Client` call returns instead.
+
+```
+@Observable ViewModel
+  |  calls
+  v
+Core Service (Repository)  ──reads/writes──►  ResponseCache (hyperoslo/Cache)
+  |  on miss / revalidate
+  v
+Generated Client → URLSession → Backend
+```
+
+**Mandatory rules:**
+
+1. Every read endpoint (`GET`-shaped operation) goes through a `ResponseCache` actor that wraps `hyperoslo/Cache`'s `Storage`. The `Storage` type is not `Sendable`, so it is **always** owned by an `actor` to stay Swift 6 strict-concurrency clean.
+2. Cache **key** = `operationID` + a stable encoding of its path/query params (e.g. `"listTodos"`, `"getTodo:\(id)"`). Never key on URLs.
+3. Apply a **stale-while-revalidate** policy: return the cached value immediately when present, then refresh in the background and update state. Memory expiry and disk expiry are set explicitly per resource via `MemoryConfig` / `DiskConfig` — no implicit infinite TTL.
+4. Any **write** endpoint (`POST`/`PATCH`/`DELETE`) must `removeObject`/`removeAll` the affected keys after success so the next read repopulates.
+5. `Cache` is for transient/server-owned data. **Durable, user-owned** state (drafts, offline records) still belongs in **SwiftData**; **secrets** still belong in **Keychain**. Do not use `hyperoslo/Cache` as a system of record.
+
+See `snippets.md` §10 for the canonical `ResponseCache` actor and cached `TodoService`.
+
+## Local Storage
+
+- **hyperoslo/Cache** — hybrid memory+disk cache for **API response memoization** at the Repository layer (see above). Transient, server-owned data only.
+- **SwiftData** (iOS 17+) — Swift-native ORM built on Core Data; preferred for **durable, user-owned** structured persistence (system of record). See `snippets.md` §11 for a compact `@Model` + `ModelContainer` + repository-fetch example.
+- **UserDefaults / `@AppStorage`** — lightweight key-value preferences.
+- **Keychain** (`Security` framework) — tokens and credentials.
+
+## Testing
+
+| Layer | Framework |
+|-------|-----------|
+| Unit (domain + services) | XCTest or Swift Testing (`@Test`) |
+| UI / snapshot | XCUITest |
+| Mocking | Protocol-based; no third-party mock lib required |
+
+Run tests with `swift test` (SwiftPM projects) or via Xcode's test runner. Target pass signal for CI: `Test Suite 'All tests' passed`.
+
+## Project Layout: App / Core / Features / Shared
+
+This is **not a Swift-specific standard** — it is the idiomatic Swift expression of
+the same *feature-first* principle the Frontend Agent applies (`../../../../rules/frontend.md`
+§Architecture). Apple's own SwiftUI samples and the 2025+ community consensus both say
+**group by feature, not by type** (no flat `Views/` `Models/` `ViewModels/`). The shared
+rules across platforms are: feature slices own their UI + state, **no cross-feature
+imports** (unidirectional), and self-describing file names. Only the folder *vocabulary*
+differs from frontend FSD — do **not** import FSD layer names (`entities/`, `widgets/`,
+`pages/`) into Swift; `widgets/` in particular collides with WidgetKit.
+
+```
+<AppName>/                       # SwiftPM package or Xcode project
+├── <AppName>App.swift           # @main entry point (top-level)
+├── Assets.xcassets/             # design tokens — color sets (top-level)
+│
+├── App/                         # app shell: composition root + routing (not a feature)
+├── Core/                        # feature-agnostic domain + infrastructure
+│   ├── Models/                  #   pure domain models
+│   ├── Networking/              #   API client · Mock · Generated/ (openapi-generator output; never hand-edit)
+│   ├── Cache/                   #   ResponseCache actor over hyperoslo/Cache (read-through, stale-while-revalidate)
+│   └── Services/                #   Repository/Store layer (DI, @Observable stores)
+│
+├── Features/<Feature>/          # vertical slice: owns its View + ViewModel
+│   ├── <Feature>View.swift      #   nest a sub-slice folder when a screen grows complex
+│   └── <Feature>ViewModel.swift #   @MainActor @Observable, dependencies via init(client:)
+│
+└── Shared/                      # stateless, reusable UI + extensions (zero feature knowledge)
+    ├── Components/
+    └── DesignSystem/            #   Typography, etc.
+```
+
+**Dependency direction (the principle, not the tree):**
+
+```
+Features ──→ Core ←── Shared        Features never import each other.
+   └─────────┐                      Core / Shared never import Features.
+App ──→ assembles (Features, Core, Shared)
+```
+
+**Scaling beyond folders.** The Swift-idiomatic graduation path for a growing codebase is
+**Swift Package Manager modules** — promote `Core` and stable `Features/<Feature>` slices to
+local SwiftPM packages for build-time isolation and enforced boundaries. This is the 2026
+modular-iOS convention; reach for it before inventing deeper folder hierarchies.
+
+## Naming Conventions
+
+Self-describing names, same principle as the Frontend Agent — the basename alone must
+answer "what domain + what role". Swift specifics:
+
+1. **No `+` in file names.** Use a descriptive suffix instead: `ProfileViewSections.swift`,
+   not `ProfileView+Sections.swift`. (`+` reads as an extension-file convention but breaks
+   some tooling and is banned here.)
+2. **Types `PascalCase`, members `camelCase`, one primary type per file**; filename = that type
+   (`SettingsViewModel.swift` → `SettingsViewModel`).
+3. **No grab-bag names** (`Utils.swift`, `Helpers.swift`, `Misc.swift`) and no version/status
+   suffixes (`*V2`, `*Old`, `*Final`) — git owns history.
+4. **Design-token symbols name the full family** to avoid colliding with built-ins. When color
+   sets shadow SwiftUI symbols (`Color.secondary`, `AccentColor`), prefix the family
+   (`SecondaryBlue*`, `AccentYellow*`) rather than the bare `Secondary*` / `Accent*`, which
+   reintroduce build warnings.
+
+## Navigation: NavigationStack + swipe-back
+
+Path-based `NavigationStack(path:)` with typed routes registered via
+`navigationDestination`. Swipe-back is a **navigation-layer** concern, not a
+per-screen one.
+
+Apps that hide the nav bar for custom headers (`.toolbar(.hidden, for: .navigationBar)`)
+lose the system edge swipe-back, because UIKit ties `interactivePopGestureRecognizer`
+to the system back button and re-disables it on every nav-bar-hidden transition.
+Restore it at the **route-registration layer** with a `swipeBackDestination`
+wrapper (see `snippets.md` §9) so every pushed route keeps the gesture and tab
+roots are excluded for free. Never restore it ad-hoc per `View` body — that drifts
+silently because forgetting it still compiles.

package/skills/oma-observability/SKILL.md

@@ -0,0 +1,225 @@
+---
+name: oma-observability
+description: Design or troubleshoot telemetry, SLOs, and incident diagnostics.
+  Route to the relevant signal, system boundary, or vendor guide.
+---
+
+# Observability Agent - Intent-based Router
+
+## Scheduling
+
+### Goal
+Route, design, tune, and review observability work across MELT+P signals, layers, boundaries, vendor categories, transport choices, meta-observability, and incident forensics.
+
+### Intent signature
+- User asks for observability, telemetry, OTel, metrics, logs, traces, profiles, SLOs, RUM, APM, incident forensics, trace propagation, transport tuning, or observability-as-code.
+- User needs vendor/category routing or observability architecture instead of a single vendor's already-covered setup.
+
+### When to use
+- Setting up an observability pipeline (OTel SDK + Collector + vendor backend)
+- Designing traceability across service and domain boundaries (W3C propagators, baggage, multi-tenant, multi-cloud)
+- Tuning transport layer (UDP/MTU, OTLP gRPC vs HTTP, Collector DaemonSet vs sidecar topology)
+- Running incident forensics (6-dimension localization: code / service / layer / host / region / infra)
+- Selecting a vendor category (OSS full-stack vs commercial SaaS vs high-cardinality specialist vs profiling specialist)
+- Implementing observability-as-code (Grafana Jsonnet dashboards, PrometheusRule CRD, OpenSLO YAML, SLO burn-rate alerts)
+- Meta-observability (pipeline self-health, clock skew detection, cardinality guardrails, retention matrix)
+- Covering the MELT+P signal set: metrics, logs, traces, profiles (OTEP 0239), cost (OpenCost), audit (SOC2/ISO), privacy (GDPR/PIPA)
+- Evaluating log-pipeline migrations against current upstream support and project requirements
+
+### When NOT to use
+- LLM ops (prompt versioning, evals, gen_ai span deep dive); use Langfuse, Arize Phoenix, LangSmith, or Braintrust directly
+- Data pipeline lineage: use OpenLineage + Marquez, dbt test, or Airflow lineage backends
+- IoT / hardware / datacenter physical-layer telemetry (IPMI, BMC, SNMP); use vendor DCIM tooling (Nlyte, Sunbird, Device42)
+- Chaos engineering orchestration: use Chaos Mesh, Litmus, Gremlin, or ChaosToolkit (this skill consumes their telemetry; it does not orchestrate chaos)
+- GPU / TPU infrastructure observability: use NVIDIA DCGM Exporter + Prometheus
+- Software supply chain (SBOM, attestation): use sigstore (cosign / rekor), in-toto framework, SLSA level attestations
+- Incident response workflow (on-call rotation, paging, escalation); use PagerDuty, OpsGenie, or Grafana OnCall
+- Full TLS packet inspection: use packet-analysis or vendor TLS inspection tooling
+- Single-vendor setup already fully covered by that vendor's own published skill; invoke the vendor skill directly
+
+### Expected inputs
+- Observability intent, target system, architecture boundary, signals, vendor context, and incident symptoms if any
+- Existing OTel/collector/vendor configs, dashboards, SLOs, trace/log/metric examples, or deployment topology
+
+### Expected outputs
+- Routed observability guidance, setup/migration/tuning plan, incident-forensics path, alerting/SLO guidance, or observability-as-code recommendations
+- Transport, meta-observability, privacy, audit, and retention checks
+- Vendor delegation target when appropriate
+
+### Dependencies
+Load resources conditionally: start with the execution protocol and one intent guide. Read only relevant matrix rows, then add a boundary, signal, or transport section when evidence requires it. The reference list is an index, not a preload list.
+
+- OTel/W3C/CNCF references and resources under `resources/`
+- Vendor categories, matrix, standards, incident forensics, meta-observability, transport, layers, boundaries, and signal guides
+
+### Control-flow features
+- Branches by intent, vendor category, layer/boundary/signal matrix, transport topology, privacy/audit risk, and incident localization dimension
+- May read/write observability config and docs; generally delegates vendor-specific implementation
+- Requires live status verification for load-bearing CNCF/vendor currency
+
+## Structural Flow
+
+### Entry
+1. Classify the intent: setup, migrate, investigate, alert, trace, tune, or route.
+2. Identify layers, boundaries, signals, and vendor category.
+3. Load only the relevant resource guide(s).
+
+### Scenes
+1. **PREPARE**: Classify intent and matrix coverage.
+2. **ACQUIRE**: Read configs, topology, telemetry examples, or incident signals.
+3. **REASON**: Route vendor/category, tune transport, assess meta-observability, or localize incident.
+4. **ACT**: Produce setup/migration/tuning/alert/trace/forensics guidance or config changes.
+5. **VERIFY**: Check pipeline health, clock skew, cardinality, retention, privacy, and audit concerns.
+6. **FINALIZE**: Report route, evidence, risks, and handoff references.
+
+### Transitions
+- If a vendor-owned skill fully covers setup, delegate instead of duplicating docs.
+- If migration is requested, verify upstream support and compatibility before choosing a replacement.
+- If incident investigation is requested, use 6-dimensional localization.
+- If transport tuning appears, load transport-specific resources.
+
+### Failure and recovery
+- If live CNCF/vendor status is load-bearing, verify current status.
+- If telemetry samples are missing, provide instrumentation/collection steps before analysis.
+- If scope belongs to out-of-scope domains, route to external authoritative tools.
+
+### Exit
+- Success: observability path is routed, evidence-backed, and checks are explicit.
+- Partial success: missing telemetry, stale vendor status, or external-domain handoff is explicit.
+
+## Logical Operations
+
+### Actions
+| Action | SSL primitive | Evidence |
+|--------|---------------|----------|
+| Classify observability intent | `SELECT` | Intent rules |
+| Read telemetry/config evidence | `READ` | OTel/vendor configs, dashboards, samples |
+| Route vendor/category | `SELECT` | Vendor categories |
+| Infer coverage gaps | `INFER` | Matrix and signal/boundary mapping |
+| Validate meta-observability | `VALIDATE` | Clock, cardinality, retention, health |
+| Write guidance/config | `WRITE` | OaC/config/docs when requested |
+| Notify result | `NOTIFY` | Routed recommendation |
+
+### Tools and instruments
+- OTel/CNCF/W3C standards references
+- Vendor categories, matrix, incident forensics, meta-observability, transport and signal guides
+- Optional CLI/config tooling from the target stack
+
+### Canonical workflow path
+```text
+1. Classify intent: setup, migrate, investigate, alert, trace, tune, or route.
+2. Select layer/boundary/signal coverage from `resources/matrix.md`.
+3. Load the specific vendor, transport, incident, or signal guide before producing guidance.
+```
+
+When CNCF/vendor status is load-bearing, verify live state at `https://landscape.cncf.io`.
+
+### Resource scope
+| Scope | Resource target |
+|-------|-----------------|
+| `CODEBASE` | Observability config, dashboards, alert rules, instrumentation |
+| `LOCAL_FS` | Resource guides and generated docs |
+| `NETWORK` | Vendor/CNCF status and telemetry backends when checked |
+| `USER_DATA` | Incident symptoms, logs, metrics, traces, profiles |
+
+### Preconditions
+- Observability intent and system boundary are identifiable.
+- Relevant telemetry/config evidence is available or missing evidence is stated.
+
+### Effects and side effects
+- May recommend or modify observability config, dashboards, alerts, and instrumentation docs.
+- May route to vendor-owned skills or external tools.
+
+### Guardrails
+1. Classify intent and use `resources/vendor-categories.md` only when category selection or vendor delegation is needed.
+2. Load the transport guide matching the observed problem: UDP/MTU, OTLP protocol, Collector topology, or sampling.
+3. Before declaring a setup complete, verify pipeline health, clock synchronization, cardinality limits, and retention against the project's requirements. Record checks that could not run.
+4. Verify current upstream support, attribute stability, and migration guidance when they affect the recommendation. Use official project documentation and CNCF status; stored versions are assumptions, not proof of current status.
+5. Use W3C Trace Context by default, with cloud translations from `resources/boundaries/cross-application.md` where required.
+6. Apply PII redaction and sampling-aware baggage controls at collection. Check retention, erasure, and audit requirements for the target system.
+7. Deliver working configuration or explicitly labeled proposals. Scaffolds and unverified checks cannot count as completed setup.
+8. Use existing OMA skill names for cross-skill handoffs; do not present future skills as available.
+
+The coverage matrix has four layers (L3, L4, mesh, L7), four boundaries (multi-tenant, cross-application, SLO, release), and seven signals (metrics, logs, traces, profiles, cost, audit, privacy). Read matching rows in `resources/matrix.md`; N/A cells do not require implementation.
+
+### Routes (Intent)
+
+| Intent | Primary target | Fallback |
+|--------|---------------|----------|
+| `setup` | `resources/vendor-categories.md` → vendor-owned skill | Generic OTel semconv in `resources/standards.md` |
+| `migrate` | Current upstream migration docs + `resources/vendor-categories.md` log-pipeline section | OTel Collector bridge config |
+| `investigate` | `resources/incident-forensics.md` (MRA + 6-dim localization) | `resources/signals/traces.md` + `resources/signals/logs.md` |
+| `alert` | `resources/boundaries/slo.md` (burn-rate alert rules) | `resources/observability-as-code.md` |
+| `trace` | `resources/boundaries/cross-application.md` (propagator matrix) | `resources/layers/mesh.md` (zero-code auto-instrumentation) |
+| `tune` | `resources/transport/` (4 files: UDP/MTU, OTLP, topology, sampling) | `resources/meta-observability.md` (cardinality guardrails) |
+| `route` | `resources/boundaries/multi-tenant.md` + `resources/transport/collector-topology.md` | `resources/boundaries/cross-application.md` (data residency) |
+
+### Invocation and loading
+For example: `/oma-observability --investigate "5xx spike in checkout"`.
+Other skills pass the intent, system boundary, and evidence; the result returns guidance, checks, and any vendor handoff.
+
+Read `resources/execution-protocol.md` first. Use the selected route above, then only relevant checklist sections before delivery. Load `resources/examples.md` for an unfamiliar output shape and `resources/anti-patterns.md` only for the affected category. Do not load all transport, layer, boundary, and signal guides together.
+
+### Integrations with OMA Ecosystem
+
+| Skill | Integration point |
+|-------|------------------|
+| `oma-debug` | On failure: pull traces + logs by `request_id` → trigger `resources/incident-forensics.md` 6-dim localization playbook |
+| `oma-qa` | Canary post-deploy loop via chrome-devtools MCP: console errors + Core Web Vitals trend; INP/LCP/CLS from `resources/layers/L7-application/web-rum.md` |
+| `oma-tf-infra` | Terraform modules for OTel Collector, Grafana, and Loki stack provisioning |
+| `oma-scm` | Deployment SHA → `service.version` OTel attribute + release marker events; see `resources/boundaries/release.md` |
+| `oma-backend` | Propagator and baggage rules; DB N+1 + Kafka patterns in `resources/signals/traces.md`. Back-reference: `oma-backend/SKILL.md` §References "Observability handoff" |
+| `oma-frontend` | `resources/layers/L7-application/web-rum.md` INP/LCP/CLS checklist. Back-reference: `oma-frontend/SKILL.md` §References "Observability handoff" |
+| `oma-mobile` | `resources/layers/L7-application/mobile-rum.md` offline-queuing pattern. Back-reference: `oma-mobile/SKILL.md` §References "Observability handoff" |
+| `oma-db` | `resources/signals/traces.md` DB patterns (N+1, connection pool). Back-reference: `oma-db/SKILL.md` §References "Observability handoff" |
+
+### Versioning & Deprecation
+
+- **Spec version pinning**: `otel_spec` / `otel_semconv` keys in each file's frontmatter document the assumed version. If content depends on a specific attribute stability tier, the tier is stated inline.
+- **Update triggers** (not scheduled):
+  - OTel semconv promotion (Development → RC → Stable) affecting attributes cited in this skill → update `resources/standards.md` and the affected file, bump minor version.
+  - Attribute deprecation → replace across all citing files; migration note in `resources/standards.md`.
+  - CNCF status change for a vendor/project named in `vendor-categories.md` (Graduated / Archived / acquired) → update the vendor table.
+- **Authoritative live state**: `https://landscape.cncf.io` for CNCF project status. This skill does not promise to track it on any schedule; verify at use time if the information is load-bearing.
+- Use `git log path/to/file` to inspect file changes; verify upstream status separately when it affects the task.
+
+Run `resources/checklist.md §1 Setup validation` before merging observability changes.
+
+## References
+- Execution steps: `resources/execution-protocol.md`
+- Intent classification: `resources/intent-rules.md`
+- Coverage matrix: `resources/matrix.md`
+- Standards (OTel spec, W3C, ISO): `resources/standards.md`
+- Vendor categories: `resources/vendor-categories.md`
+- Incident forensics: `resources/incident-forensics.md`
+- Meta-observability: `resources/meta-observability.md`
+- Observability-as-code: `resources/observability-as-code.md`
+- Anti-patterns catalog (72 entries): `resources/anti-patterns.md`
+- Checklist: `resources/checklist.md`
+- Examples: `resources/examples.md`
+- Transport:
+  - `resources/transport/udp-statsd-mtu.md`
+  - `resources/transport/otlp-grpc-vs-http.md`
+  - `resources/transport/collector-topology.md`
+  - `resources/transport/sampling-recipes.md`
+- Layers:
+  - `resources/layers/L3-network.md`
+  - `resources/layers/L4-transport.md`
+  - `resources/layers/mesh.md`
+  - `resources/layers/L7-application/web-rum.md`
+  - `resources/layers/L7-application/mobile-rum.md`
+  - `resources/layers/L7-application/crash-analytics.md`
+  - `resources/layers/L7-application/waf.md`
+- Boundaries:
+  - `resources/boundaries/multi-tenant.md`
+  - `resources/boundaries/cross-application.md`
+  - `resources/boundaries/slo.md`
+  - `resources/boundaries/release.md`
+- Signals:
+  - `resources/signals/metrics.md`
+  - `resources/signals/logs.md`
+  - `resources/signals/traces.md`
+  - `resources/signals/profiles.md`
+  - `resources/signals/cost.md`
+  - `resources/signals/audit.md`
+  - `resources/signals/privacy.md`