cellenium 0.1.0__tar.gz

cellenium-0.1.0/.claude/bin/checklist.js

@@ -0,0 +1,114 @@
+#!/usr/bin/env node
+'use strict';
+
+const fs = require('node:fs');
+const os = require('node:os');
+const path = require('node:path');
+
+const PACKAGE_ROOT = path.resolve(__dirname, '..');
+const FEATURE = 'checklist';
+// Each skill is independent; fordec is the standalone emergency skill.
+// `relPath` is where the skill lives under skills/checklist/ in this repo;
+// it installs flat as skills/checklist/<name> regardless of source nesting.
+const SKILLS = [
+  { name: 'before-startup', relPath: 'before-startup' },
+  { name: 'cruising', relPath: 'cruising' },
+  { name: 'landing', relPath: 'landing' },
+  { name: 'fordec', relPath: 'emergency/fordec' },
+];
+
+function filesMatch(left, right) {
+  return (
+    fs.existsSync(left) &&
+    fs.existsSync(right) &&
+    fs.readFileSync(left).equals(fs.readFileSync(right))
+  );
+}
+
+function installSkills({ projectRoot = process.cwd(), global = false, force = false } = {}) {
+  const target = global
+    ? path.join(os.homedir(), '.claude', 'skills', FEATURE)
+    : path.join(path.resolve(projectRoot), '.claude', 'skills', FEATURE);
+  const unchanged = [];
+  const pending = [];
+
+  for (const { name: skill, relPath } of SKILLS) {
+    const source = path.join(PACKAGE_ROOT, 'skills', FEATURE, relPath);
+    const destination = path.join(target, skill);
+    const sourceSkill = path.join(source, 'SKILL.md');
+    const destinationSkill = path.join(destination, 'SKILL.md');
+
+    if (!fs.existsSync(destination)) {
+      pending.push({ destination, source, skill });
+      continue;
+    }
+
+    if (filesMatch(sourceSkill, destinationSkill)) {
+      unchanged.push(skill);
+      continue;
+    }
+
+    if (!force) {
+      throw new Error(
+        `Refusing to overwrite existing skill: ${skill}. Re-run with --force to replace it.`,
+      );
+    }
+
+    pending.push({ destination, source, skill });
+  }
+
+  fs.mkdirSync(target, { recursive: true });
+  for (const { destination, source } of pending) {
+    fs.rmSync(destination, { force: true, recursive: true });
+    fs.cpSync(source, destination, { recursive: true });
+  }
+
+  return {
+    installed: pending.map(({ skill }) => skill),
+    target,
+    unchanged,
+  };
+}
+
+function printHelp() {
+  process.stdout.write(`Checklist skills installer (before-startup, cruising, landing, fordec)\n\nUsage:\n  fordec-checklist [--global] [--force]\n\nOptions:\n  --global   Install into ~/.claude/skills/testflow instead of ./.claude/skills/testflow\n  --force    Replace skills with local modifications\n  --help     Show this help\n  --version  Show the package version\n`);
+}
+
+function run(argv = process.argv.slice(2)) {
+  const known = new Set(['--force', '--global', '--help', '-h', '--version', '-v']);
+  const unknown = argv.find((argument) => !known.has(argument));
+  if (unknown) {
+    throw new Error(`Unknown option: ${unknown}`);
+  }
+
+  if (argv.includes('--help') || argv.includes('-h')) {
+    printHelp();
+    return;
+  }
+
+  if (argv.includes('--version') || argv.includes('-v')) {
+    const { version } = require('../../package.json');
+    process.stdout.write(`${version}\n`);
+    return;
+  }
+
+  const result = installSkills({
+    force: argv.includes('--force'),
+    global: argv.includes('--global'),
+  });
+  const installed = result.installed.length
+    ? `Installed: ${result.installed.join(', ')}`
+    : 'All skills already match this package.';
+  process.stdout.write(`${installed}\nClaude Code skills directory: ${result.target}\n`);
+}
+
+if (require.main === module) {
+  try {
+    run();
+  } catch (error) {
+    process.stderr.write(`${error.message}\n`);
+    process.exitCode = 1;
+  }
+}
+
+module.exports = { installSkills, run };

cellenium-0.1.0/.claude/commands/testflow/artifact.md

@@ -0,0 +1,9 @@
+---
+name: artifact
+description: Turn a PRD or specification into traceable pytest tests, execute them, and evaluate their quality through the complete TestFlow pipeline.
+argument-hint: <PRD/spec path and test target>
+command: /testflow:artifact
+---
+
+Invoke the Skill tool with `skill: "testflow:artifact"` before doing anything else. 
+Pass `$ARGUMENTS` as the pipeline input and complete every reachable TestFlow stage.

cellenium-0.1.0/.claude/commands/testflow/checklist/before-startup.md

@@ -0,0 +1,7 @@
+---
+name: before-startup
+description: System readiness check before building tests. Use before starting TestFlow or writing any test to verify that the repository, toolchain, browsers, configuration, external services, test infrastructure, baseline, and inputs are healthy and ready for test creation.
+command: /before-startup
+---
+
+Invoke the Skill tool with `skill: "testflow:before-startup"` before doing anything else.

cellenium-0.1.0/.claude/commands/testflow/checklist/cruising.md

@@ -0,0 +1,7 @@
+---
+name: cruising
+description: In-flight check while tests are being built. Use after any TestFlow stage, after writing or changing tests, or before a commit or PR to verify that everything is in place and to hunt for critical errors and potential bugs in the tests, locators, fixtures, and observed product behavior.
+command: /cruising
+---
+
+Invoke the Skill tool with `skill: "testflow:cruising"` before doing anything else.

cellenium-0.1.0/.claude/commands/testflow/checklist/fordec.md

@@ -0,0 +1,12 @@
+---
+name: fordec
+description: |
+  Software incident and emergency decision cycle using the aviation-derived FORDEC model: 
+  Facts, Options, Risks & Benefits, Decision, Execution, Check. 
+  Use when a production outage, failed deploy, broken main branch, 
+  data corruption, security incident, or other consequential engineering 
+  problem needs a clear, time-aware choice, assigned actions, and active reassessment.
+command: /fordec
+---
+
+Invoke the Skill tool with `skill: "testflow:fordec"` before doing anything else.

cellenium-0.1.0/.claude/commands/testflow/checklist/landing.md

@@ -0,0 +1,7 @@
+---
+name: landing
+description: Final production-readiness checklist. Use before final PR approval, merge, release, or production deployment to verify the final state, compare land and go-around options, make an explicit decision, define or perform the authorized execution, and check production signals with rollback triggers.
+command: /landing
+---
+
+Invoke the Skill tool with `skill: "testflow:landing"` before doing anything else.

cellenium-0.1.0/.claude/commands/testflow/evaluator.md

@@ -0,0 +1,10 @@
+---
+name: evaluator
+description: Evaluate pytest tests against requirements, specifications, implementation contracts, and execution evidence.
+argument-hint: <requirements, tests, and execution results>
+command: /testflow:evaluator
+---
+
+Invoke the Skill tool with `skill: "testflow:evaluator"` 
+before doing anything else. Pass `$ARGUMENTS` as the evaluation 
+scope and return the coverage matrix, evidence-backed findings, residual risks, and verdict.

cellenium-0.1.0/.claude/commands/testflow/executor.md

@@ -0,0 +1,10 @@
+---
+name: executor
+description: Run repository-native pytest commands, preserve exact evidence, and classify collection, environment, test, and product failures.
+argument-hint: <test paths, node IDs, or markers>
+command: /testflow:executor
+---
+
+Invoke the Skill tool with `skill: "testflow:executor"` before doing anything else. 
+Pass `$ARGUMENTS` as the requested test selection and report exact commands, 
+results, failure classifications, and verdict.

cellenium-0.1.0/.claude/commands/testflow/locator-writer.md

@@ -0,0 +1,10 @@
+---
+name: locator-writer
+description: Discover stable Playwright locators, validate the target elements, and upsert them into the configured Google Sheets Page Object Model.
+argument-hint: <page, screen, and required elements>
+command: /testflow:locator-writer
+---
+
+Invoke the Skill tool with `skill: "testflow:locator-writer"` 
+before doing anything else. Pass `$ARGUMENTS` as the UI target and element requirements. 
+Preview updates before replacing existing non-empty sheet rows.

cellenium-0.1.0/.claude/commands/testflow/prd-reader.md

@@ -0,0 +1,10 @@
+---
+name: prd-reader
+description: Extract testable, traceable pytest requirements from a PRD, feature brief, ticket, or acceptance criteria.
+argument-hint: <PRD path, issue, or requirements>
+command: /testflow:prd-reader
+---
+
+Invoke the Skill tool with `skill: "testflow:prd-reader"` 
+before doing anything else. Pass `$ARGUMENTS` as the product 
+source and return the requirement matrix without running downstream stages.

cellenium-0.1.0/.claude/commands/testflow/test-spec.md

@@ -0,0 +1,8 @@
+---
+name: test-spec
+description: Convert requirements and technical specifications into a complete, traceable pytest test specification.
+argument-hint: <requirements/spec path and target>
+command: /testflow:test-spec
+---
+
+Invoke the Skill tool with `skill: "testflow:test-spec"` before doing anything else. Pass `$ARGUMENTS` as specification context and return the test strategy, cases, file plan, environment contract, and traceability map.

cellenium-0.1.0/.claude/commands/testflow/web.md

@@ -0,0 +1,11 @@
+---
+name: web
+description: Explore a live web application in a real browser to discover and document reproducible potential bugs with evidence.
+argument-hint: <URL, scope, role, and optional PRD/spec>
+command: /testflow:web
+---
+
+Invoke the Skill tool with `skill: "testflow:web"` 
+before doing anything else. Pass `$ARGUMENTS` as the exploration charter. 
+Use a real browser, preserve safety boundaries, 
+and return verified findings plus regression-test candidates without modifying application code.

cellenium-0.1.0/.claude/commands/testflow/writer.md

@@ -0,0 +1,10 @@
+---
+name: writer
+description: Implement approved test cases as deterministic, behavior-focused pytest tests that follow repository conventions.
+argument-hint: <test specification and target>
+command: /testflow:writer
+---
+
+Invoke the Skill tool with `skill: "testflow:writer"` 
+before doing anything else. Pass `$ARGUMENTS` as the 
+approved test specification, write the pytest tests, and return collection plus targeted execution evidence.

cellenium-0.1.0/.claude/skills/checklist/before-startup/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: before-startup
+description: System readiness check before building tests. Use before starting TestFlow or writing any test to verify that the repository, toolchain, browsers, configuration, external services, test infrastructure, baseline, and inputs are healthy and ready for test creation.
+disable-model-invocation: true
+---
+
+# Before Startup — Ready to Build Tests
+
+Purpose: prove the system is healthy and ready to build tests before any test is designed or written. A test built on a broken environment produces failures that say nothing about the product.
+
+## Workflow position
+
+**1 of 3 — run first.** Use once before TestFlow (`prd-reader` → `test-spec` → `locator-writer` → `writer` → `executor` → `evaluator`) or any manual test work starts. When the verdict is **READY TO BUILD TESTS**, continue with `cruising` while tests are built. Use `landing` for the final check.
+
+## How to run
+
+Check every item from fresh command output and observed files. Memory and phrases such as "should be installed" are not evidence. Discover the real commands from the repository (`pyproject.toml`, `uv.lock`, CI workflow, README) before running them.
+
+Do not fix anything silently. For each FAIL, give the exact fix command or action. Run only non-destructive setup (for example `uv sync --frozen` or `playwright install chromium`) when the user agrees. Never print secret values. Report only whether a secret is present and valid.
+
+## 1. Repository
+
+1. **Branch and working tree:** report the current branch, every modified or untracked file, and any merge, rebase, or cherry-pick in progress. Separate existing user work from work for this task.
+2. **Integration state:** fetch the remote and report divergence from the integration branch. Do not assume it is `main`.
+
+## 2. Toolchain and dependencies
+
+3. **Python:** confirm the active interpreter matches the version `pyproject.toml` requires.
+4. **Locked dependencies:** confirm the lockfile and environment agree (for example `uv sync --frozen` succeeds with no changes) and that `pytest`, its plugins (such as `pytest-xdist`), and `playwright` import.
+5. **Browsers:** confirm the required Playwright browser is installed and launches. Run a headless launch smoke check, not just a file lookup.
+
+## 3. Configuration and secrets
+
+6. **Environment variables:** confirm `.env` exists and that every variable the settings contract requires is set and non-empty. List names only.
+7. **Credentials:** confirm required credential files (such as `credentials.json`) exist, parse, and contain the expected fields. Confirm they are ignored by Git.
+8. **Settings import:** import the settings module and confirm validation passes with no missing or malformed fields.
+
+## 4. External services
+
+9. **Application under test:** confirm the target URL or service responds with the expected page or status from this machine.
+10. **Locator source:** for UI work, confirm the Google Sheet is reachable with the service account and that every worksheet/screen required by the target flow can be read directly.
+11. **AI and model services:** when vision or LLM components are used, confirm the configured model and API key work with a minimal call.
+
+## 5. Test infrastructure
+
+12. **Collection:** `pytest --collect-only` completes with zero import, syntax, or fixture errors.
+13. **Fixtures and engine:** shared fixtures and `conftest.py` import, and a browser session can be opened and torn down cleanly with no leaked processes.
+14. **Output paths:** screenshot, report, and artifact directories exist and are writable.
+
+## 6. Baseline
+
+15. **Lint:** run the blocking CI lint command and report the result.
+16. **Existing suite:** run the existing tests and record every pre-existing failure with its cause. New failures must be distinguishable from this baseline later.
+
+## 7. Inputs for building tests
+
+17. **Requirements:** the PRD, ticket, spec, or acceptance criteria exist and are readable.
+18. **Target and data:** the flow, module, or endpoint under test is identified, and the required test accounts, data, and permissions are available.
+19. **Blocking unknowns:** list any open product question that would change an expected result. An unresolved one is a FAIL for the affected scope.
+
+## Report format
+
+Output:
+
+1. a `Area | # | item | PASS/FAIL/N-A | evidence` table;
+2. a **Fixes** list: the exact command or action for every FAIL;
+3. a **Baseline** line: pre-existing failures that are accepted;
+4. the verdict **READY TO BUILD TESTS** or **NOT READY: <failing items>**.
+
+A FAIL is a hard stop. Never start building tests past one silently.

cellenium-0.1.0/.claude/skills/checklist/cruising/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: cruising
+description: In-flight check while tests are being built. Use after any TestFlow stage, after writing or changing tests, or before a commit or PR to verify that everything is in place and to hunt for critical errors and potential bugs in the tests, locators, fixtures, and observed product behavior.
+disable-model-invocation: true
+---
+
+# Cruising — Everything in Place, No Hidden Bugs
+
+Purpose: while tests are being built, confirm that every piece is in place and catch critical errors and potential bugs before they harden into the suite.
+
+## Workflow position
+
+**2 of 3 — repeat while building tests.** Use after `before-startup` returns **READY TO BUILD TESTS**. Run it after each TestFlow stage (`prd-reader`, `test-spec`, `locator-writer`, `writer`, `executor`), after any manual test change, and before every commit or PR. Hand off to `landing` only when cruising returns **ON COURSE** with no open CRITICAL findings.
+
+## How to run
+
+First name the checkpoint: the TestFlow stage just finished, `TEST CHANGE`, `COMMIT`, or `PR`. Then run all four sections. Use command output, file paths with line numbers, and observed behavior. Green tests alone are not evidence that nothing is wrong.
+
+Report findings; do not silently rewrite code. When the user asks for fixes, route each finding to the stage that owns it (`prd-reader`, `test-spec`, `locator-writer`, `writer`, `executor`) and run cruising again afterward.
+
+## 1. Everything in place
+
+1. **Working tree:** run `git status` and account for every changed or untracked file, including partial output from earlier or interrupted runs. Nothing unexplained may remain.
+2. **Stage outputs:** every completed stage has its output. That means `PRD-*` requirements, `TST-*` cases with file plan, verified locators, and test files at the planned paths. Stable IDs are preserved across handoffs.
+3. **Traceability:** every `PRD-*` requirement maps to at least one `TST-*` case, every `TST-*` case maps to a test function, and no test exists without a requirement.
+4. **Locators:** every logical element the tests use exists in the correct Google Sheet worksheet/screen and resolves on the live page.
+5. **Fixtures and data:** every fixture, test-data file, account, and environment variable the new tests need exists and is wired in.
+6. **System still healthy:** recheck the `before-startup` critical items: dependencies, browser launch, settings import, and target reachability. An environment that has since degraded is a FAIL.
+
+## 2. Collection and execution
+
+7. **Collection:** `pytest --collect-only` is clean, and each new test is collected exactly once.
+8. **Targeted run:** run the new and changed tests and report the exact command, exit code, and pass/fail/skip counts.
+9. **Failure classification:** classify every failure as **product bug**, **test bug**, or **environment**. Use evidence: traceback, screenshot, and log. An environment failure is an invalid run, not a verdict.
+10. **Flakiness:** rerun each failing or newly passing test at least once, and also under the CI parallel mode (for example `-n auto --dist loadscope`). Any result that differs between runs is a finding.
+11. **Baseline drift:** compare the full-suite result with the `before-startup` baseline. Any new failure outside the changed tests is a finding.
+
+## 3. Critical errors (hard stop)
+
+Any item here is **CRITICAL**:
+
+12. **Broken suite:** syntax, import, collection, or fixture-setup errors, plus blocking CI lint errors.
+13. **Tests that cannot fail:** missing assertions, `assert True`, assertions on the wrong object, broad `except` that swallows failures, and `skip`/`xfail` without a stated reason and ticket.
+14. **Leaks and cleanup:** browser sessions or processes not torn down (no `finally`/fixture teardown), and temp data or files left behind.
+15. **Secrets and safety:** credentials, tokens, or `.env` values in code, logs, screenshots, or reports, and tests that write to production data or modify the shared Google Sheet unintentionally.
+16. **Wrong target:** tests pointed at the wrong environment, URL, or account.
+
+## 4. Potential bugs
+
+Scan the new and changed tests, fixtures, and helpers, and report each finding with `file:line`:
+
+17. **Fragile selectors:** index-based XPath, auto-generated classes, text that changes, and selectors matching more than one element.
+18. **Timing:** `sleep` instead of explicit waits, missing waits after navigation or actions, and race-prone assertions.
+19. **Isolation:** shared mutable state, order dependence, and fixtures with the wrong scope for parallel execution.
+20. **Hardcoding:** URLs, credentials, dates, locale, or time-zone assumptions inside tests instead of config or fixtures.
+21. **Coverage gaps:** boundaries, negative paths, empty or invalid input, and error states from `test-spec` that are missing or only partially asserted.
+22. **Correctness slips:** copy-paste errors in IDs, parameters, or expected values, wrong exception types, unhandled `None`, and tests whose name does not match what they assert.
+23. **Product bugs observed:** any application defect seen during runs, with reproduction steps and evidence, marked as a regression-test candidate.
+
+## Report format
+
+Output:
+
+1. `Checkpoint: <stage | TEST CHANGE | COMMIT | PR>`;
+2. an **In place** table: `# | item | PASS/FAIL/N-A | evidence`;
+3. a **Run** line: commands, exit codes, counts, and flaky tests;
+4. a **Findings** table: `severity (CRITICAL/MAJOR/MINOR) | file:line | issue | evidence | owning stage / fix`;
+5. the verdict **ON COURSE** or **HOLD: <CRITICAL findings and failing items>**.
+
+Any CRITICAL finding or FAIL is a hard stop. Fix it or escalate it; never continue building past one silently.

cellenium-0.1.0/.claude/skills/checklist/emergency/fordec/SKILL.md

@@ -0,0 +1,164 @@
+---
+name: fordec
+description: "Software incident and emergency decision cycle using the aviation-derived FORDEC model: Facts, Options, Risks & Benefits, Decision, Execution, Check. Use when a production outage, failed deploy, broken main branch, data corruption, security incident, or other consequential engineering problem needs a clear, time-aware choice, assigned actions, and active reassessment."
+disable-model-invocation: true
+---
+
+# FORDEC — Software Incident Decision Cycle
+
+Use FORDEC to turn an uncertain, consequential engineering situation into an explicit, reviewable decision:
+
+1. **Facts**
+2. **Options**
+3. **Risks & Benefits**
+4. **Decision**
+5. **Execution**
+6. **Check & Monitor**
+
+FORDEC is a decision aid, not a substitute for the team's incident-response process, runbooks, on-call escalation policy, security or legal obligations, or the judgment of the incident commander. The responsible human remains the decision owner.
+
+## Workflow position
+
+**Off-sequence — run on demand.** `before-startup`, `cruising`, and `landing` cover planned work. Use `fordec` whenever something goes wrong at any point: a production incident, a failed or partial deploy, a red main branch blocking the team, a suspected data loss, a leaked secret, or a regression discovered after merge. Return to the planned checklist only after this cycle reaches a stable state.
+
+## Severity and containment gate
+
+Before beginning the full cycle:
+
+1. Classify impact: users affected, revenue or SLA exposure, data integrity or loss, security or privacy exposure, and whether the problem is spreading.
+2. If damage is ongoing, contain first using the established, reversible lever: roll back the deploy, disable the feature flag, stop the job or queue consumer, shift or drain traffic, revoke and rotate an exposed credential, put the system in maintenance or read-only mode, or follow the runbook step.
+3. Do not delay a required containment action to complete FORDEC. Stabilize first, then use the shortest useful cycle.
+4. Declare the incident through the team's channel if it meets the threshold. State the incident commander (decision owner), the available decision time, and any limits on access or authority.
+5. Preserve evidence before it disappears: logs, metrics snapshots, failing request IDs, the deployed revision, and the state of affected data.
+
+Never invent runbook steps, system limits, root causes, or compliance requirements. Use observed evidence and the team's documented procedures. When an unknown could change the safe course, mark it clearly and pull in the owning team or a specialist.
+
+## Operating rules
+
+- Run **F → O → R → D → E → C** in order. Do not choose a fix before comparing its risks and benefits.
+- Separate observations (what the logs, metrics, and tests show) from hypotheses about the cause.
+- Mitigation comes before root cause. Restore service first; investigate afterward.
+- Prefer the safest reversible action when evidence or time is limited: rollback beats hotfix, flag-off beats code change, pause beats delete.
+- Include rollback, hold, freeze deploys, and escalate as options whenever they are viable.
+- Use all available resources: dashboards, logs, traces, alerts, error trackers, git history, CI results, runbooks, owning teams, and vendors' status pages.
+- Invite an independent challenge before the Decision when time permits. The person who wrote or deployed the change should not be the only one testing the diagnosis.
+- Use closed-loop communication: assign a named owner, require acknowledgment, and confirm completion in the incident channel.
+- A material new fact, failed assumption, or breached threshold invalidates the current decision. Stop and restart at **Facts**.
+- Never treat a green deploy, a passing CI run, or a quiet alert channel as proof that the system is healthy.
+
+## Time-pressure modes
+
+Choose the shortest mode that preserves safety:
+
+- **Full FORDEC** — the system is stable or degraded but contained. Gather evidence, compare realistic fixes, coordinate owners, and define monitoring.
+- **Rapid FORDEC** — users are impacted now. State only the decisive facts, two or three feasible options, the dominant risk and benefit of each, the decision, immediate assignments, and the next check.
+- **Immediate action** — delay is actively increasing damage (data being corrupted, secret being exploited, outage spreading). Execute the established containment lever first, announce it in the incident channel, then perform Rapid FORDEC once the bleeding stops.
+
+Time pressure permits compression, not omission of ownership, rollback readiness, or reassessment.
+
+## F — FACTS
+
+Establish what is true now:
+
+1. **Symptom** — what is failing, since when, error rates and latency vs. baseline, affected endpoints, services, jobs, regions, tenants, or user segments, and the alert or report that triggered the response.
+2. **Change correlation** — recent deploys, merges, config or flag changes, migrations, infrastructure or dependency updates, and third-party incidents in the window before onset. Identify the exact running revision.
+3. **Evidence quality** — label each material statement as **OBSERVED**, **REPORTED**, **INFERRED**, or **UNKNOWN**, with its source (dashboard, log query, trace, test, user report). Resolve conflicts where possible.
+4. **Blast radius and trend** — what still works, what is degraded or down, whether data is being written incorrectly, and whether the situation is stable, improving, or worsening.
+5. **Time** — SLA or SLO burn rate, queue backlogs, disk or quota exhaustion, certificate or token expiry, retry storms, and any point after which data becomes unrecoverable or rollback is no longer clean.
+6. **Constraints** — change freezes, access or permission limits, migrations that cannot be reversed, compliance or disclosure obligations, and unavailable tooling.
+7. **People and resources** — incident commander, on-call engineers, code owners of the affected area, communications owner, and vendor or platform support.
+8. **Objective** — the safety outcome to protect first (data integrity, security, user trust), then the service outcome to restore.
+
+Do not hide a missing fact inside an assumption. If it cannot be resolved in time, carry it into Risks & Benefits as uncertainty.
+
+## O — OPTIONS
+
+List only feasible courses:
+
+1. Generate distinct actions, not variations in wording. Typical candidates: roll back to the last known-good revision, disable a feature flag or config, revert the offending commit and redeploy, forward-fix with a hotfix, scale or reroute traffic, pause jobs or consumers, restore or repair data, fail over, hold and gather more evidence, or escalate.
+2. State what each option requires (access, build and deploy time, approvals, data steps), how quickly it can take effect, and any condition that makes it unavailable — for example, a migration that makes rollback unsafe.
+3. Eliminate an option if it violates a hard constraint, depends on unavailable access, or risks making data loss or exposure worse.
+4. Keep the list short enough to compare under incident workload. Do not manufacture alternatives to reach a count.
+5. Identify a fallback for any option whose failure would leave no safe course, such as a hotfix that fails CI or a rollback that fails on schema mismatch.
+
+## R — RISKS & BENEFITS
+
+Compare every remaining option against the same criteria:
+
+- user and business impact reduced, and how quickly;
+- credible failure modes and worst credible consequence (extended outage, data loss, duplicated side effects, security exposure);
+- likelihood, severity, blast radius, and uncertainty;
+- time to deploy and time until the effect is visible in metrics;
+- reversibility and point of no return (schema changes, emitted events, sent emails, external API calls, deleted data);
+- untested code paths: a hotfix that skipped review or tests carries risk the rollback does not;
+- compatibility with live data, in-flight requests, caches, queued messages, and older clients;
+- workload and coordination demand on the people involved;
+- mitigations, warning signs, and remaining risk after mitigation.
+
+Use qualitative ratings only when their meaning is explicit. Never collapse an uncertain high-consequence risk into an unsupported "low risk" label. Name the assumption most likely to invalidate each option.
+
+## D — DECISION
+
+Make the choice explicit before acting:
+
+1. Name the selected option and why its benefits outweigh its risks under the current facts.
+2. Name the decision owner and any approval required (code owner, security, data owner, release manager).
+3. Record rejected options and the decisive reason for rejecting each.
+4. State accepted residual risks, their owners, and the fallback course.
+5. Define success criteria in measurable terms (error rate, latency, queue depth, failing test now passing), abort thresholds, escalation triggers, and the next decision point.
+6. Record meaningful dissent. Resolve safety-critical disagreement through the incident commander or escalation path; do not manufacture consensus.
+
+If no option is acceptably safe, decide to **HOLD**, **ROLL BACK**, or **ESCALATE** rather than disguising uncertainty as permission to ship a fix.
+
+## E — EXECUTION
+
+Translate the Decision into coordinated action:
+
+1. Sequence actions so that containment, data integrity, and security come before full recovery, cleanup, or root-cause work.
+2. Assign each action to a named owner with a deadline or trigger, and post it in the incident channel.
+3. Specify communications: status page, affected customers or internal teams, stakeholders to update, and the handover if the incident outlives the shift.
+4. Confirm critical commands by readback. Double-check the target environment, revision, and scope before any destructive or irreversible command (database writes, deletes, force pushes, credential revocation).
+5. Prepare the rollback or fallback before crossing a point of no return. Take a backup or snapshot before data repair.
+6. Execute only the selected course and only within granted authority. Require explicit user approval for destructive or production-affecting actions unless an established runbook already authorizes them.
+7. Keep a timestamped log of actions taken for the postmortem.
+8. If execution exposes a material new fact or cannot proceed as planned, stop improvising and reopen FORDEC.
+
+## C — CHECK
+
+Verify outcomes and keep monitoring:
+
+1. Compare observed results with the Decision's success criteria. Report actual values from metrics, logs, and tests, not "looks fixed" or "deployed successfully."
+2. Confirm that assigned actions completed, communications were sent, and no affected service, job, tenant, or data set was missed.
+3. For each important risk, define the signal, expected state, threshold, observation window, owner, and response.
+4. Watch for secondary effects: retry backlogs draining, cache stampedes, delayed jobs catching up, and data written during the incident window.
+5. At the next decision point, explicitly choose one: continue monitoring, modify, roll back, hand over, escalate, close the incident, or restart FORDEC.
+6. Once stable, capture follow-ups: root-cause investigation, regression test for the failure, data repair verification, and a postmortem owner and date.
+
+The Check phase is continuous. A changed context starts a new cycle with new Facts; it does not merely append a note to the old decision.
+
+## Team challenge
+
+When another competent engineer is available and time permits:
+
+1. Give them the raw signals (graphs, logs, error samples, the diff) before sharing your preferred diagnosis.
+2. Ask for an independent diagnosis, an overlooked option, and the strongest reason the preferred fix could fail.
+3. Reconcile the two mental models and record unresolved disagreement.
+4. Let any participant call **STOP** when an assumption fails or execution diverges from the Decision.
+
+For a solo decision, perform the same challenge explicitly: "What evidence would prove my diagnosis wrong?" and "What safer, more reversible option have I not considered?"
+
+## Response format
+
+Lead with any immediate containment action. Then output:
+
+1. `Mode: FULL FORDEC | RAPID FORDEC | IMMEDIATE ACTION` and `Severity: <level and impact summary>`
+2. `Incident commander: <person or role> | Decision time: <deadline or window> | Running revision: <sha/version>`
+3. a **Facts** table: `fact | status (OBSERVED/REPORTED/INFERRED/UNKNOWN) | source | relevance`;
+4. an **Options** table: `option | requirements | benefits | risks | reversibility`;
+5. a **Decision** line: selected option, rationale, residual risk, and required approval;
+6. an **Execution** table: `priority | action | owner | trigger/deadline | confirmation`;
+7. a **Check** table: `signal | expected state | threshold | window | owner | response`;
+8. a **Follow-ups** list: root cause, regression test, data verification, postmortem owner;
+9. a verdict: **EXECUTE**, **HOLD**, **ROLL BACK**, or **ESCALATE**, followed by the next decision point.
+
+In Rapid mode, compress each section to the decisive content. Never omit the Decision, owner, immediate assignments, rollback path, or next Check.

cellenium-0.1.0/.claude/skills/checklist/landing/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: landing
+description: Final production-readiness checklist. Use before final PR approval, merge, release, or production deployment to verify the final state, compare land and go-around options, make an explicit decision, define or perform the authorized execution, and check production signals with rollback triggers.
+disable-model-invocation: true
+---
+
+# Landing — Final Production Decision
+
+Purpose: make the last pre-production decision deliberately.
+
+Green checks are inputs, not the decision. The final cycle must expose the weakest evidence, compare landing with a go-around, state who accepts residual risk, and define how production will be monitored.
+
+## Workflow position
+
+**3 of 3 — run last.** Use after `before-startup` returned **READY TO BUILD TESTS** and the latest `cruising` check returned **ON COURSE** with no open CRITICAL findings, when the completed change awaits final approval, merge, release, or deployment. This is the terminal production-readiness check.
+
+## How to run
+
+Run the sections in order against the final branch state. Evidence must come from the actual final diff, branch-tip validation, observed end-to-end behavior, repository rules, and deploy configuration. Do not merge, release, or deploy unless the user has authorized that action. If new facts appear during Execution or Check, stop and restart the checklist.
+
+## Current state
+
+1. **Uncomfortable truth** — name the part of the change with the weakest evidence and the question you most hope nobody asks. "Nothing" is a FAIL. Prove it safe or record it as residual risk with an owner.
+2. **Final state** — identify the exact branch tip and re-read the complete final diff adversarially. Confirm documented invariants for every touched area against what was built, not the original plan.
+3. **Validation evidence** — report build, typecheck, lint, full-suite, and relevant targeted-test results from the final state. Identify every changed branch that no test or manual run executed.
+4. **Operational evidence** — report the production-like end-to-end run, concrete failure signals, expected logs or metrics, affected user surfaces and jobs, data compatibility, rollback mechanism, and point of no return.
+5. **Deployment readiness** — list indexes, TTL policies, rules, variables, secrets, migrations, scheduled work, notifications, manual steps, and exact ordering constraints. State what happens if code arrives before infrastructure.
+
+## Options
+
+6. **Landing choices** — list the viable courses supported by the facts: land as-is, land through a staged or controlled rollout, fix and repeat the cycle, reduce scope, defer the change, or go around. Do not manufacture equivalence: eliminate any option that violates a hard invariant.
+7. **Simpler option** — explicitly test whether half the code, fewer abstractions, an existing dependency or pattern, or a narrower change satisfies the requirement with less production exposure.
+8. **Recovery options** — identify plain revert, feature or configuration disablement, forward fix, data repair, traffic shift, and full go-around. Mark unavailable recovery paths clearly.
+
+## Risks and benefits
+
+9. **Option comparison** — for each option, state user benefit, delivery benefit, operational burden, reversibility, blast radius, and the cost of delay. A vague "low risk" or "faster" is not evidence.
+10. **Hidden-bug audit** — assess never-executed handlers, fallbacks, retries, edge inputs, oversized and duplicate inputs, swallowed errors, idempotency, races, overlapping schedules, clock skew, time zones, and page boundaries. Name what happens for every reachable case.
+11. **Avoided-test audit** — name the test omitted because setup was hard or failure was likely. Run it, select an option that removes the exposure, or record the risk with an owner.
+12. **Simplicity audit** — challenge one-caller indirection, speculative flags and modes, new packages or patterns, hard-to-explain modules, dead code, debug output, scaffolding, tombstone names, and TODOs without tickets. State the present requirement that justifies anything retained.
+13. **Deployment risk** — assess live-data and in-flight-client compatibility, infra-before-code hazards, rollback after writes or emitted events, observability delay, and every point after which a go-around becomes harder.
+
+## Decision
+
+14. **Land or go around** — select one option and state why its benefits outweigh its risks. Record approver, residual risks and owners, prerequisites, success criteria, rollback threshold, and any point of no return. If a hard gate lacks evidence, the decision is **GO-AROUND**.
+15. **Authorization boundary** — distinguish approval of the readiness decision from authorization to merge, release, or deploy. Never infer production authorization from a request to review.
+
+## Execution
+
+16. **Execute the authorized course** — complete required fixes and validation, then follow the exact approved merge, release, infrastructure, migration, and deployment order. Use the selected rollout controls and prepare the rollback commands before crossing the point of no return. If authorization stops at review, produce the execution plan without performing the release.
+
+## Verification
+
+17. **Immediate verification** — after every executed step, verify the expected revision, environment, service health, user-visible behavior, data state, scheduled work, and required infrastructure. Report observed values, not "deployed successfully."
+18. **Monitor and decide again** — define each signal, baseline, observation window, threshold, owner, and response. A breached threshold triggers the selected rollback or go-around and restarts this checklist with the new facts.
+
+## Report format
+
+Output:
+
+1. a `Section | # | item | PASS/FAIL/N-A | evidence` table;
+2. an **Options** table: `option | benefits | risks | reversibility`;
+3. a **Decision** line: **LAND**, **STAGED LANDING**, or **GO-AROUND**, with rationale, approver, and residual-risk owners;
+4. an **Execution** line: authorized actions completed or the exact pending plan;
+5. a **Check** table: `signal | expected | threshold | window | owner | response`;
+6. the verdict **CLEAR TO LAND** or **GO-AROUND: <failing items or unblock conditions>**.
+
+A FAIL is a hard stop. Never land past one silently. An honest go-around is cheaper than an incident.