forgecommandline 0.8.0__py3-none-any.whl

forgecli/worktrees.py

@@ -0,0 +1,79 @@
+"""Separate git worktrees for parallel agents, so two agents editing the same project never overwrite
+each other. Each agent gets its own checkout of the current commit on its own branch
+(forge/agent-N-<time>) under .forge/worktrees/; its changes are committed there and the main agent
+(or you) merges the branches it wants. Turned on with FORGE_WORKTREES=1 or the run_parallel `isolate`
+option; needs git and a project that is a git repository with at least one commit."""
+from __future__ import annotations
+
+import os
+import pathlib
+import shutil
+import subprocess
+import time
+
+
+def _git(args, cwd, timeout=60):
+    return subprocess.run(["git", *args], cwd=str(cwd), capture_output=True, text=True,
+                          encoding="utf-8", errors="replace", timeout=timeout)
+
+
+def wanted(isolate: bool | None = None) -> bool:
+    if isolate is not None:
+        return bool(isolate)
+    return os.environ.get("FORGE_WORKTREES", "").strip().lower() in ("1", "on", "true", "yes")
+
+
+def repo_root(cwd) -> pathlib.Path | None:
+    if not shutil.which("git"):
+        return None
+    try:
+        r = _git(["rev-parse", "--show-toplevel"], cwd, 10)
+        if r.returncode != 0:
+            return None
+        if _git(["rev-parse", "--verify", "HEAD"], cwd, 10).returncode != 0:
+            return None                         # no commit yet: nothing to check out
+        return pathlib.Path(r.stdout.strip())
+    except (OSError, subprocess.TimeoutExpired):
+        return None
+
+
+def create(root: pathlib.Path, n: int, stamp: str | None = None) -> tuple[pathlib.Path, str] | None:
+    stamp = stamp or time.strftime("%Y%m%d-%H%M%S")
+    branch = f"forge/agent-{n}-{stamp}"
+    path = root / ".forge" / "worktrees" / f"agent-{n}-{stamp}"
+    path.parent.mkdir(parents=True, exist_ok=True)
+    _exclude(root)
+    r = _git(["worktree", "add", "-b", branch, str(path), "HEAD"], root)
+    return (path, branch) if r.returncode == 0 else None
+
+
+def _exclude(root: pathlib.Path) -> None:
+    """Keep .forge/worktrees out of `git status` without touching the project's .gitignore."""
+    try:
+        info = pathlib.Path(_git(["rev-parse", "--git-path", "info/exclude"], root, 10).stdout.strip())
+        info = info if info.is_absolute() else root / info
+        text = info.read_text(encoding="utf-8") if info.exists() else ""
+        if ".forge/worktrees/" not in text:
+            info.parent.mkdir(parents=True, exist_ok=True)
+            info.write_text(text + ("" if text.endswith("\n") or not text else "\n") + ".forge/worktrees/\n",
+                            encoding="utf-8")
+    except (OSError, subprocess.TimeoutExpired):
+        pass
+
+
+def finish(root: pathlib.Path, path: pathlib.Path, branch: str, task: str) -> str:
+    """Commit the agent's work on its branch; remove the checkout (the branch stays). One-line summary."""
+    try:
+        _git(["add", "-A"], path)
+        changed = _git(["diff", "--cached", "--stat"], path).stdout.strip()
+        if changed:
+            _git(["-c", "user.name=Forge agent", "-c", "user.email=forge@localhost", "commit", "-q",
+                  "-m", f"forge agent: {task[:70]}"], path)
+        _git(["worktree", "remove", "--force", str(path)], root)
+        if not changed:
+            _git(["branch", "-D", branch], root)
+            return "no file changes (branch removed)"
+        last = changed.splitlines()[-1].strip()
+        return f"committed on branch `{branch}` ({last}); merge with `git merge {branch}`"
+    except (OSError, subprocess.TimeoutExpired) as e:
+        return f"worktree left at {path} on branch `{branch}` ({e})"

forgecommandline-0.8.0.data/data/skills/commit/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: commit
+description: Commit changes - stage the current changes and write a clear git commit message
+---
+# Commit
+
+1. Run `git status` and `git diff` to see every change. If nothing changed, say so and stop.
+2. Check for files that should not be committed (.env, keys, large binaries, build output).
+   If you see any, stop and ask the user before staging.
+3. Stage the relevant files by name (avoid `git add -A` if unrelated files are present).
+4. Write the message: a subject line under 70 characters in the imperative ("Add …", "Fix …"),
+   a blank line, then a short body saying why the change was made.
+5. Commit, then run `git log -1 --stat` and report the result.
+Never push, amend, or force anything unless the user asks.

forgecommandline-0.8.0.data/data/skills/debug/SKILL.md

@@ -0,0 +1,17 @@
+---
+name: debug
+description: Find and fix the real cause of a bug, error or crash - reproduce, narrow down, fix, prove it
+---
+# Debug
+
+1. Reproduce first. Run the failing command or test and capture the exact error. If you can't make it
+   fail, ask the user for the steps or input — don't fix blind.
+2. Read the stack trace from the bottom up to the first line in this project's code. Read that code and
+   what calls it.
+3. Form one hypothesis at a time and test it cheaply: print/log the values, run a smaller input, check
+   the git history of the lines (`git log -L` or `git blame`) to see what changed recently.
+4. Fix the cause, not the symptom. Avoid try/except that hides the error, sleeps that hide timing bugs,
+   or special cases for one input.
+5. Prove it: rerun the reproduction (now passes), then the related tests. Where it fits, add a test
+   that would have caught the bug.
+6. Report: the cause in one or two sentences, the fix, and how you verified it.

forgecommandline-0.8.0.data/data/skills/explain/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: explain
+description: Explain how a file, folder, function or feature works - what this code does and why, for someone new to the code
+---
+# Explain
+
+1. Find the entry points: list the folder, read the README if there is one, then the files the
+   user named (or the main file).
+2. Follow the flow the user asked about by reading the code; grep for names you are unsure of.
+3. Explain in this order:
+   - What it is for, in two sentences.
+   - The main pieces and how data moves between them (reference `path:line`).
+   - Anything surprising: hidden side effects, config it depends on, known gotchas.
+4. Keep it short. Use a small diagram in a code block only if it truly helps.

forgecommandline-0.8.0.data/data/skills/init/SKILL.md

@@ -0,0 +1,19 @@
+---
+name: init
+description: Study this project and write a FORGE.md with how to build, run and test it, its structure and conventions
+---
+# Init: write FORGE.md
+
+Forge reads FORGE.md (or CLAUDE.md / AGENTS.md) from the project folder into every conversation,
+so this file should hold what a new teammate needs and can't guess quickly.
+
+1. Look around: list_dir the root, read the README, package files (package.json, pyproject.toml,
+   requirements.txt, Cargo.toml, go.mod…), CI config, and a couple of central source files.
+2. Find the real commands: install, run/dev server, build, test, lint, format. Prefer ones you saw in
+   config files or scripts; run the test command once if it's quick, to confirm it works.
+3. Write FORGE.md (if CLAUDE.md or AGENTS.md exists, update that instead) with short sections:
+   - Commands (copy-pasteable)
+   - Layout: the main folders and what lives in each, in a few lines
+   - Conventions you saw: code style, naming, how errors are handled, where tests go
+   - Gotchas: anything surprising (env vars needed, generated files not to edit, slow steps)
+4. Keep it under ~80 lines. No generic advice ("write clean code") — only things specific to this project.

forgecommandline-0.8.0.data/data/skills/library/LICENSES/agent-skills-MIT.txt

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 Addy Osmani
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

forgecommandline-0.8.0.data/data/skills/library/LICENSES/wondelai-MIT.txt

@@ -0,0 +1,23 @@
+MIT License
+
+Copyright (c) wondelai
+
+Applies to: architecture-optimization, improve-code-quality, remove-technical-debt, system-design (each SKILL.md declares license: MIT, author: wondelai).
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

forgecommandline-0.8.0.data/data/skills/library/README.md

@@ -0,0 +1,9 @@
+# Bundled engineering skills
+
+These ship with Forge so they work without Claude Code and without `/skills sync`.
+
+- From [addyosmani/agent-skills](https://github.com/addyosmani/agent-skills), MIT (LICENSES/agent-skills-MIT.txt): api-and-interface-design, browser-testing-with-devtools, ci-cd-and-automation, code-review-and-quality, code-simplification, constraint-driven-development, context-engineering, debugging-and-error-recovery, deprecation-and-migration, documentation-and-adrs, doubt-driven-development, frontend-ui-engineering, git-workflow-and-versioning, idea-refine, incremental-implementation, interview-me, observability-and-instrumentation, performance-optimization, planning-and-task-breakdown, security-and-hardening, shipping-and-launch, source-driven-development, spec-driven-development, test-driven-development, using-agent-skills.
+- From wondelai, MIT (LICENSES/wondelai-MIT.txt): architecture-optimization, improve-code-quality, remove-technical-debt, system-design.
+
+`_references/` holds the checklists the agent-skills link to. Refresh with the bundle script; a skill in ~/.forge/skills or .forge/skills with the same name overrides one here.
+- By the Forge author (Harry Sigei), shipped with Forge: awwwards-tier-web-application.

forgecommandline-0.8.0.data/data/skills/library/_references/accessibility-checklist.md

@@ -0,0 +1,160 @@
+# Accessibility Checklist
+
+Quick reference for WCAG 2.1 AA compliance. Use alongside the `frontend-ui-engineering` skill.
+
+## Table of Contents
+
+- [Essential Checks](#essential-checks)
+- [Common HTML Patterns](#common-html-patterns)
+- [Testing Tools](#testing-tools)
+- [Quick Reference: ARIA Live Regions](#quick-reference-aria-live-regions)
+- [Common Anti-Patterns](#common-anti-patterns)
+
+## Essential Checks
+
+### Keyboard Navigation
+- [ ] All interactive elements focusable via Tab key
+- [ ] Focus order follows visual/logical order
+- [ ] Focus is visible (outline/ring on focused elements)
+- [ ] Custom widgets have keyboard support (Enter to activate, Escape to close)
+- [ ] No keyboard traps (user can always Tab away from a component)
+- [ ] Skip-to-content link at top of page - visible (at least) on keyboard focus
+- [ ] Modals trap focus while open, return focus on close
+
+### Screen Readers
+- [ ] All images have `alt` text (or `alt=""` for decorative images)
+- [ ] All form inputs have associated labels (`<label>` or `aria-label`)
+- [ ] Buttons and links have descriptive text (not "Click here")
+- [ ] Icon-only buttons have `aria-label`
+- [ ] Page has one `<h1>` and headings don't skip levels
+- [ ] Dynamic content changes announced (`aria-live` regions)
+- [ ] Tables have `<th>` headers with scope
+
+### Visual
+- [ ] Text contrast ≥ 4.5:1 (normal text) or ≥ 3:1 (large text, 18px+)
+- [ ] UI components contrast ≥ 3:1 against background
+- [ ] Color is not the only way to convey information
+- [ ] Text resizable to 200% without breaking layout
+- [ ] No content that flashes more than 3 times per second
+
+### Forms
+- [ ] Every input has a visible label
+- [ ] Required fields indicated (not by color alone)
+- [ ] Error messages specific and associated with the field
+- [ ] Error state visible by more than color (icon, text, border)
+- [ ] Form submission errors summarized and focusable
+- [ ] Known fields use autocomplete (for example `type="email" autocomplete="email"`)
+
+### Content
+- [ ] Language declared (`<html lang="en">`)
+- [ ] Page has a descriptive `<title>`
+- [ ] Links distinguish from surrounding text (not by color alone)
+- [ ] Touch targets ≥ 44x44px on mobile
+- [ ] Meaningful empty states (not blank screens)
+
+## Common HTML Patterns
+
+### Buttons vs. Links
+
+```html
+<!-- Use <button> for actions -->
+<button onClick={handleDelete}>Delete Task</button>
+
+<!-- Use <a> for navigation -->
+<a href="/tasks/123">View Task</a>
+
+<!-- NEVER use div/span as buttons -->
+<div onClick={handleDelete}>Delete</div>  <!-- BAD -->
+```
+
+### Form Labels
+
+```html
+<!-- Explicit label association -->
+<label htmlFor="email">Email address</label>
+<input id="email" type="email" required />
+
+<!-- Implicit wrapping -->
+<label>
+  Email address
+  <input type="email" required />
+</label>
+
+<!-- Hidden label (visible label preferred) -->
+<input type="search" aria-label="Search tasks" />
+```
+
+### ARIA Roles
+
+```html
+<!-- Navigation -->
+<nav aria-label="Main navigation">...</nav>
+<nav aria-label="Footer links">...</nav>
+
+<!-- Status messages -->
+<div role="status" aria-live="polite">Task saved</div>
+
+<!-- Alert messages -->
+<div role="alert">Error: Title is required</div>
+
+<!-- Modal dialogs -->
+<dialog aria-modal="true" aria-labelledby="dialog-title">
+  <h2 id="dialog-title">Confirm Delete</h2>
+  ...
+</dialog>
+
+<!-- Loading states -->
+<div aria-busy="true" aria-label="Loading tasks">
+  <Spinner />
+</div>
+```
+
+### Accessible Lists
+
+```html
+<ul role="list" aria-label="Tasks">
+  <li>
+    <input type="checkbox" id="task-1" aria-label="Complete: Buy groceries" />
+    <label htmlFor="task-1">Buy groceries</label>
+  </li>
+</ul>
+```
+
+## Testing Tools
+
+```bash
+# Automated audit
+npx axe-core          # Programmatic accessibility testing
+npx pa11y             # CLI accessibility checker
+
+# In browser
+# Chrome DevTools → Lighthouse → Accessibility
+# Chrome DevTools → Elements → Accessibility tree
+
+# Screen reader testing
+# macOS: VoiceOver (Cmd + F5)
+# Windows: NVDA (free) or JAWS
+# Linux: Orca
+```
+
+## Quick Reference: ARIA Live Regions
+
+| Value | Behavior | Use For |
+|-------|----------|---------|
+| `aria-live="polite"` | Announced at next pause | Status updates, saved confirmations |
+| `aria-live="assertive"` | Announced immediately | Errors, time-sensitive alerts |
+| `role="status"` | Same as `polite` | Status messages |
+| `role="alert"` | Same as `assertive` | Error messages |
+
+## Common Anti-Patterns
+
+| Anti-Pattern | Problem | Fix |
+|---|---|---|
+| `div` as button | Not focusable, no keyboard support | Use `<button>` |
+| Missing `alt` text | Images invisible to screen readers | Add descriptive `alt` |
+| Color-only states | Invisible to color-blind users | Add icons, text, or patterns |
+| Autoplaying media | Disorienting, can't be stopped | Add controls, don't autoplay |
+| Custom dropdown with no ARIA | Unusable by keyboard/screen reader | Use native `<select>` or proper ARIA listbox |
+| Removing focus outlines | Users can't see where they are | Style outlines, don't remove them |
+| Empty links/buttons | "Link" announced with no description | Add text or `aria-label` |
+| `tabindex > 0` | Breaks natural tab order | Use `tabindex="0"` or `-1` only |

forgecommandline-0.8.0.data/data/skills/library/_references/definition-of-done.md

@@ -0,0 +1,67 @@
+# Definition of Done
+
+A standing, project-wide bar that every change must clear before it counts as done. Unlike acceptance criteria, which vary per task and answer "did we build the right thing?", the Definition of Done is the same every time and answers "is this finished to our standard?". Use it as the final gate in `planning-and-task-breakdown`, `incremental-implementation`, and `shipping-and-launch`.
+
+## Definition of Done vs. Acceptance Criteria
+
+| | Acceptance Criteria | Definition of Done |
+|---|---|---|
+| Scope | Specific to one task or spec | Applies to every increment |
+| Changes | Different for each item | Fixed and reused |
+| Answers | "Did we build *this thing*?" | "Is it *ready*?" |
+| Owner | Defined when planning the task | Defined once for the project |
+| Example | "User can reset password via email link" | "Tests pass, no regressions, docs updated" |
+
+The two are complementary. A task is done only when **its** acceptance criteria are met **and** the standing Definition of Done is satisfied. Skipping either leaves work that looks finished but is not.
+
+## The Standing Checklist
+
+Apply this to every change before declaring it done.
+
+### Correctness
+- [ ] All acceptance criteria for the task are met
+- [ ] Code runs and behaves as intended, verified at runtime, not just compiled or typechecked
+- [ ] New behavior is covered by tests that fail without the change and pass with it
+- [ ] Existing tests still pass; no regressions introduced
+- [ ] Edge cases and error paths are handled, not just the happy path
+
+### Quality
+- [ ] Code reveals intent through naming and structure; no comments needed to explain *what* it does
+- [ ] No duplicated business logic
+- [ ] No dead code, debug output, or commented-out blocks left behind
+- [ ] Changes are scoped to the task; no unrelated refactors snuck in
+- [ ] Linting and formatting pass
+
+The depth behind these items lives in `code-review-and-quality` (the five-axis review) and `code-simplification` (reducing complexity without changing behavior).
+
+### Integration
+- [ ] Change works with the rest of the system, not just in isolation
+- [ ] Database migrations, config changes, and feature flags are accounted for
+- [ ] Backward compatibility considered for any public interface or API change
+
+### Documentation
+- [ ] Public interfaces, APIs, and user-facing behavior are documented
+- [ ] Architectural decisions worth preserving are recorded (see `documentation-and-adrs`)
+- [ ] Documentation describes the current state in timeless language, not the change history
+
+### Ship-readiness
+- [ ] Security implications reviewed for any untrusted input, auth, or data handling (see `security-and-hardening`)
+- [ ] Observability in place for new critical paths (logs, metrics, traces) (see `observability-and-instrumentation`)
+- [ ] Rollback path exists for anything risky (see `shipping-and-launch`)
+- [ ] The human has reviewed and approved before merge or deploy
+
+## How to Apply
+
+- **Per task**: confirm the Correctness and Quality sections before checking the task off.
+- **Per feature**: confirm Integration and Documentation before considering the feature complete.
+- **Per release**: the full checklist is the floor; `shipping-and-launch` adds the deploy-specific gates on top.
+
+Tailor the list to the project once, then reuse it unchanged. A Definition of Done that is renegotiated every sprint is not a Definition of Done.
+
+## Red Flags
+
+- "It's done, I just haven't run it yet": unverified work is not done.
+- "Tests pass" used as a synonym for done while docs, regressions, or runtime verification are skipped.
+- A different bar applied depending on deadline pressure.
+- Acceptance criteria treated as the whole bar, with no standing quality floor.
+- "Done" declared before human review on changes that need it.

forgecommandline-0.8.0.data/data/skills/library/_references/observability-checklist.md

@@ -0,0 +1,92 @@
+# Observability Checklist
+
+Quick reference for instrumenting production code. Use alongside the `observability-and-instrumentation` skill.
+
+## Table of Contents
+
+- [On-Call Questions (Start Here)](#on-call-questions-start-here)
+- [Structured Logging](#structured-logging)
+- [Metrics](#metrics)
+- [Distributed Tracing](#distributed-tracing)
+- [Alerting](#alerting)
+- [Dashboards](#dashboards)
+- [Verify the Telemetry](#verify-the-telemetry)
+- [Pre-Launch Gate](#pre-launch-gate)
+
+## On-Call Questions (Start Here)
+
+Telemetry without a question is noise. Before instrumenting anything:
+
+- [ ] 2–4 questions an on-call engineer will ask about this feature are written down
+- [ ] Every signal below maps to one of those questions
+- [ ] Each question is matched to the right signal type: metrics say **that** something is wrong, traces say **where**, logs say **why**
+
+## Structured Logging
+
+- [ ] Logs are structured (JSON) with stable event names — not free-form strings
+- [ ] Every log line carries a correlation/request ID, generated or accepted at the system boundary
+- [ ] Correlation ID is propagated on every outbound call and async boundary (HTTP headers, queue metadata)
+- [ ] Any log stream written by more than one entry point (scheduler, replay endpoint, manual run) carries an entry-point field, set where the run starts and propagated alongside the correlation ID
+- [ ] Log levels are consistent: `error` = invariant broken, someone may act; `warn` = degraded but handled; `info` = significant business event; `debug` = off in production
+- [ ] No secrets, tokens, passwords, or unredacted PII in any log line (hard rule from `security-and-hardening`)
+- [ ] Fields are allowlisted — no whole request/response bodies, no auth headers
+- [ ] External service calls logged with metadata only: endpoint, status, latency, attempt count, sanitized identifiers
+- [ ] Actual log output spot-checked: structured fields, not `[object Object]`
+
+## Metrics
+
+- [ ] **RED** instrumented for every endpoint and every external dependency: Rate, Errors, Duration
+- [ ] **USE** instrumented for every resource (queues, pools, hosts): Utilization, Saturation, Errors
+- [ ] Latency is a histogram; p50/p95/p99 queryable — never an average
+- [ ] All labels come from small, fixed sets (route template, status class, provider name)
+- [ ] No unbounded label values: no user IDs, tenant IDs, emails, raw URLs, request IDs, or error message text
+- [ ] Status codes grouped by class (`5xx`, not `503`)
+- [ ] Queue depth and processing duration tracked for every worker/queue
+
+## Distributed Tracing
+
+- [ ] OpenTelemetry (or equivalent) initialized at service startup, before other imports
+- [ ] Auto-instrumentation enabled for HTTP, gRPC, and DB clients
+- [ ] Trace context propagated on every outbound call (W3C `traceparent`/`tracestate`) and extracted from every inbound request
+- [ ] Context survives async boundaries — queue messages carry trace metadata
+- [ ] Manual spans only around meaningful internal units of work, with the attributes on-call will filter by
+- [ ] No secrets or PII as span attributes
+- [ ] Head-based sampling at a low default rate; 100% of errors kept if tail sampling is available
+
+## Alerting
+
+- [ ] Every alert is symptom-based (error rate, p99 latency, queue age) — causes (CPU, disk, restarts) go to dashboards, not pagers
+- [ ] Every alert is actionable; "ignore it, it self-heals" alerts are deleted
+- [ ] Every alert links to a runbook — minimum three lines: what it means, first query to run, escalation path
+- [ ] Thresholds and durations justified by an SLO or historical data, not guesses
+- [ ] Two severities only: **page** (user-facing, act now) and **ticket** (degradation, act this week)
+- [ ] Each new alert test-fired once: it reached the right channel and the runbook link works
+- [ ] No alerts that fire daily and get acknowledged without action
+
+## Dashboards
+
+- [ ] Service health dashboard exists: error rate, latency p99, traffic, saturation
+- [ ] Dependency health panel shows per-service error rates and latency
+- [ ] Dashboard answers the on-call questions from the top of this checklist — not "everything except the answer"
+- [ ] Default time range is sensible (1h–6h, not 30d)
+
+## Verify the Telemetry
+
+Instrumentation is code; it can be wrong:
+
+- [ ] Forced an error in staging → found it in the logs by correlation ID
+- [ ] Sent test traffic → metric series appear with expected labels and sane values
+- [ ] Followed one request end-to-end in the tracing UI → no broken spans
+- [ ] An induced failure was diagnosed from telemetry alone, without reading the source
+
+## Pre-Launch Gate
+
+Before a feature ships to production, all of the following are true:
+
+- [ ] Structured logs flowing to the log aggregator
+- [ ] RED metrics visible in dashboards for every new endpoint and dependency
+- [ ] At least one symptom-based alert configured, with runbook, test-fired
+- [ ] A request can be traced across every service it touches
+- [ ] On-call knows where the runbooks are
+
+For launch-day monitoring sequence and rollback triggers, see the `shipping-and-launch` skill.