cellenium 0.1.0__tar.gz → 0.2.1__tar.gz

cellenium-0.2.1/.claude/commands/cellenium/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: /cellenium:artifact
+---
+
+Before doing anything else, read `.claude/skills/cellenium/artifact/SKILL.md` (or `~/.claude/skills/cellenium/artifact/SKILL.md` if it is not in the project) and follow it as your instructions. Each stage it names lives in a sibling folder, e.g. `prd-reader` is `.claude/skills/cellenium/prd-reader/SKILL.md`; read a stage's SKILL.md before applying it. 
+Pass `$ARGUMENTS` as the pipeline input and complete every reachable TestFlow stage.

{cellenium-0.1.0/.claude/commands/testflow → cellenium-0.2.1/.claude/commands/cellenium}/checklist/before-startup.md

@@ -1,7 +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
+command: /cellenium:checklist:before-startup
 ---
 
-Invoke the Skill tool with `skill: "testflow:before-startup"` before doing anything else.
+Before doing anything else, read `.claude/skills/cellenium/before-startup/SKILL.md` (or `~/.claude/skills/cellenium/before-startup/SKILL.md` if it is not in the project) and follow it as your instructions.

{cellenium-0.1.0/.claude/commands/testflow → cellenium-0.2.1/.claude/commands/cellenium}/checklist/cruising.md

@@ -1,7 +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
+command: /cellenium:checklist:cruising
 ---
 
-Invoke the Skill tool with `skill: "testflow:cruising"` before doing anything else.
+Before doing anything else, read `.claude/skills/cellenium/cruising/SKILL.md` (or `~/.claude/skills/cellenium/cruising/SKILL.md` if it is not in the project) and follow it as your instructions.

{cellenium-0.1.0/.claude/commands/testflow → cellenium-0.2.1/.claude/commands/cellenium}/checklist/fordec.md

@@ -6,7 +6,7 @@ description: |
   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
+command: /cellenium:checklist:fordec
 ---
 
-Invoke the Skill tool with `skill: "testflow:fordec"` before doing anything else.
+Before doing anything else, read `.claude/skills/cellenium/emergency/fordec/SKILL.md` (or `~/.claude/skills/cellenium/emergency/fordec/SKILL.md` if it is not in the project) and follow it as your instructions.

{cellenium-0.1.0/.claude/commands/testflow → cellenium-0.2.1/.claude/commands/cellenium}/checklist/landing.md

@@ -1,7 +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
+command: /cellenium:checklist:landing
 ---
 
-Invoke the Skill tool with `skill: "testflow:landing"` before doing anything else.
+Before doing anything else, read `.claude/skills/cellenium/landing/SKILL.md` (or `~/.claude/skills/cellenium/landing/SKILL.md` if it is not in the project) and follow it as your instructions.

{cellenium-0.1.0/.claude/commands/testflow → cellenium-0.2.1/.claude/commands/cellenium}/evaluator.md

@@ -2,9 +2,8 @@
 name: evaluator
 description: Evaluate pytest tests against requirements, specifications, implementation contracts, and execution evidence.
 argument-hint: <requirements, tests, and execution results>
-command: /testflow:evaluator
+command: /cellenium:evaluator
 ---
 
-Invoke the Skill tool with `skill: "testflow:evaluator"` 
-before doing anything else. Pass `$ARGUMENTS` as the evaluation 
+Before doing anything else, read `.claude/skills/cellenium/evaluator/SKILL.md` (or `~/.claude/skills/cellenium/evaluator/SKILL.md` if it is not in the project) and follow it as your instructions. 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 → cellenium-0.2.1/.claude/commands/cellenium}/executor.md

@@ -2,9 +2,9 @@
 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
+command: /cellenium:executor
 ---
 
-Invoke the Skill tool with `skill: "testflow:executor"` before doing anything else. 
+Before doing anything else, read `.claude/skills/cellenium/executor/SKILL.md` (or `~/.claude/skills/cellenium/executor/SKILL.md` if it is not in the project) and follow it as your instructions. 
 Pass `$ARGUMENTS` as the requested test selection and report exact commands, 
 results, failure classifications, and verdict.

cellenium-0.2.1/.claude/commands/cellenium/locator-writer.md

@@ -0,0 +1,9 @@
+---
+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: /cellenium:locator-writer
+---
+
+Before doing anything else, read `.claude/skills/cellenium/locator-writer/SKILL.md` (or `~/.claude/skills/cellenium/locator-writer/SKILL.md` if it is not in the project) and follow it as your instructions. 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 → cellenium-0.2.1/.claude/commands/cellenium}/prd-reader.md

@@ -2,9 +2,8 @@
 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
+command: /cellenium:prd-reader
 ---
 
-Invoke the Skill tool with `skill: "testflow:prd-reader"` 
-before doing anything else. Pass `$ARGUMENTS` as the product 
+Before doing anything else, read `.claude/skills/cellenium/prd-reader/SKILL.md` (or `~/.claude/skills/cellenium/prd-reader/SKILL.md` if it is not in the project) and follow it as your instructions. Pass `$ARGUMENTS` as the product 
 source and return the requirement matrix without running downstream stages.

cellenium-0.2.1/.claude/commands/cellenium/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: /cellenium:test-spec
+---
+
+Before doing anything else, read `.claude/skills/cellenium/test-spec/SKILL.md` (or `~/.claude/skills/cellenium/test-spec/SKILL.md` if it is not in the project) and follow it as your instructions. 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 → cellenium-0.2.1/.claude/commands/cellenium}/web.md

@@ -2,10 +2,9 @@
 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
+command: /cellenium:web
 ---
 
-Invoke the Skill tool with `skill: "testflow:web"` 
-before doing anything else. Pass `$ARGUMENTS` as the exploration charter. 
+Before doing anything else, read `.claude/skills/cellenium/web/SKILL.md` (or `~/.claude/skills/cellenium/web/SKILL.md` if it is not in the project) and follow it as your instructions. 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 → cellenium-0.2.1/.claude/commands/cellenium}/writer.md

@@ -2,9 +2,8 @@
 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
+command: /cellenium:writer
 ---
 
-Invoke the Skill tool with `skill: "testflow:writer"` 
-before doing anything else. Pass `$ARGUMENTS` as the 
+Before doing anything else, read `.claude/skills/cellenium/writer/SKILL.md` (or `~/.claude/skills/cellenium/writer/SKILL.md` if it is not in the project) and follow it as your instructions. Pass `$ARGUMENTS` as the 
 approved test specification, write the pytest tests, and return collection plus targeted execution evidence.

cellenium-0.2.1/.claude/skills/cellenium/before-startup/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: before-startup
+description: FORDEC departure checklist for software work. Use before writing implementation code to establish Facts, compare Options, assess Risks and Benefits, make an explicit Decision, Execute the departure plan, and Check that the branch, baseline, dependencies, environment, and task are safe to proceed.
+disable-model-invocation: true
+---
+
+# Before Startup — FORDEC Departure Checklist
+
+Purpose: make the first implementation move deliberately. This skill adapts the aviation **FORDEC** decision model to software delivery:
+
+1. **Facts** — establish the current state from fresh evidence.
+2. **Options** — identify viable courses of action, including holding position.
+3. **Risks & Benefits** — compare each option without hiding tradeoffs.
+4. **Decision** — select and state the course before acting.
+5. **Execution** — carry out the selected departure plan.
+6. **Check** — verify the expected state and monitor for reasons to reconsider.
+
+## Workflow position
+
+**1 of 3 — run first.** Use once before implementation starts. After this cycle is clear, use `cruising` for repeated FORDEC cycles at launch, commit, and PR boundaries. Use `landing` only for the final production-readiness cycle.
+
+## How to run
+
+Run the stages in order. Do not jump from Facts to Execution. Use fresh command output, repository rules, and observed state; memory and phrases such as "probably clean" are not evidence. A destructive action, history rewrite, protected-branch change, or one-way-door decision requires explicit user approval.
+
+## F — FACTS
+
+1. **Integration branch and remote state** — identify the integration branch from repository evidence, fetch the remote, and report the exact divergence between `HEAD` and `origin/<integration>`. Never assume the branch is `main`.
+2. **Branch and working-tree state** — report the current branch, commits ahead of the integration branch, every modified or untracked file, and any merge, rebase, or cherry-pick in progress. Distinguish existing user work from task work.
+3. **Baseline state** — run the repository's build, typecheck, lint, and test commands before implementation. Report actual results and pre-existing failures.
+4. **Dependencies and environment** — verify the lockfile and installed dependencies agree, then name every required variable, secret, emulator, service account, or local service and its observed status. Never expose secret values.
+5. **Traffic and blockers** — identify open PRs, active branches, upstream work, unresolved product or architecture decisions, and missing contracts that can collide with or block the task.
+
+## O — OPTIONS
+
+6. **Viable departures** — list the safe courses available from the facts. Typical options include creating a fresh branch from the remote tip, updating the current task branch, isolating existing work before branching, splitting the scope, coordinating an overlap, or holding position. Exclude any option that would overwrite user work.
+7. **No-go option** — always include stopping to resolve a red baseline, missing prerequisite, unsafe branch state, or unresolved one-way-door decision. "Proceed anyway" is not an option when evidence is missing.
+
+## R — RISKS & BENEFITS
+
+8. **Compare every option** — state the concrete benefit and risk of each option: lost work, history rewrite, merge-conflict debt, ambiguous test failures, dependency drift, environment mismatch, duplicated effort, or delay.
+9. **Irreversibility check** — identify protected-branch changes, force updates, destructive cleanup, public contracts, schema shapes, event formats, or data writes that cannot be safely reversed. Mark each as requiring user approval.
+
+## D — DECISION
+
+10. **Departure decision** — choose one option and state why its benefits outweigh its risks. Name the branch, base commit, task scope, unresolved accepted risks, owner, and the evidence that will permit execution. If the safe choice is to hold, say **NO-GO** and name the unblock condition.
+
+## E — EXECUTION
+
+11. **Execute the selected plan only** — fetch or synchronize as decided, create or switch to the correctly named task branch, isolate unrelated changes without discarding them, install locked dependencies, and resolve the named blockers. Do not improvise a different course mid-execution; new facts reopen the FORDEC cycle.
+
+## C — CHECK
+
+12. **Departure verification** — confirm all of the following from fresh evidence:
+    - the current branch is task-specific and not protected;
+    - its base is the intended remote integration tip;
+    - every ahead commit belongs to this task;
+    - the working tree contains no unexplained residue;
+    - the baseline is green, or every pre-existing failure is explicitly accepted;
+    - dependencies and environment are ready;
+    - no unresolved collision or prerequisite blocks implementation.
+13. **Monitoring trigger** — state what could invalidate the decision after departure, such as a conflicting PR merging, the integration branch moving, an environment dependency failing, or a contract changing. Name how it will be detected and when to run FORDEC again.
+
+## Report format
+
+Output:
+
+1. a `Stage | # | item | PASS/FAIL/N-A | evidence` table;
+2. an **Options** list with one-line Risks and Benefits for each;
+3. a **Decision** line: selected option, rationale, owner, and accepted risk;
+4. an **Execution** line: actions actually completed;
+5. a **Check** line: observed final state and monitoring trigger;
+6. the verdict **CLEAR TO DEPART** or **NO-GO: <failing items or unblock conditions>**.
+
+A FAIL is a hard stop. Never begin implementation past one silently.

cellenium-0.2.1/.claude/skills/cellenium/cruising/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: cruising
+description: Repeating FORDEC control cycle for implementation work. Use before launching or resuming an agent, committing a phase, or opening or updating a PR to establish Facts, compare Options, assess Risks and Benefits, make a Decision, Execute it with TDD and operational discipline, and Check results, drift, and monitoring.
+disable-model-invocation: true
+---
+
+# Cruising — Repeating FORDEC Control Cycle
+
+Purpose: prevent implementation momentum from turning assumptions into facts. Run the aviation-derived **FORDEC** sequence at every meaningful boundary:
+
+1. **Facts**
+2. **Options**
+3. **Risks & Benefits**
+4. **Decision**
+5. **Execution**
+6. **Check**
+
+## Workflow position
+
+**2 of 3 — repeat during implementation.** Use after `before-startup` has cleared the initial departure. Run a complete cycle at each **LAUNCH**, **COMMIT**, and **PR** boundary. Hand off to `landing` only after the PR cycle is checked and the completed change is ready for its final production decision.
+
+## How to run
+
+First name the boundary:
+
+- **LAUNCH** — starting or resuming an agent or implementation phase;
+- **COMMIT** — closing a phase or preparing a commit;
+- **PR** — opening or updating a pull request.
+
+Then run F → O → R → D → E → C in order for that boundary. Use command output, file paths, quoted contracts, and observed behavior. Do not choose an option before comparing risks and benefits. New material facts during Execution invalidate the decision and restart the cycle at Facts.
+
+## F — FACTS
+
+1. **Boundary and working tree** — identify LAUNCH, COMMIT, or PR; run `git status`; account for every uncommitted file and any partial output from a previous or killed agent. Never treat ambient changes as belonging to the current task.
+2. **Architecture and contracts** — state the layer, module boundary, dependency direction, established pattern, documented invariants, and one-way-door contracts affected by the work. Cite their sources.
+3. **Scope and delta** — compare the actual diff and commits with the ticket, plan, and current phase exit criteria. Name adjacent or deferred work that has entered the diff.
+4. **Agent and environment state** — for LAUNCH, verify the delegation contains the goal, exact paths, binding plan substance, constraints, and session decisions; verify agent identity directly when resuming; confirm the machine, connection, services, and quota can survive the run.
+5. **Quality evidence** — for COMMIT or PR, show RED evidence for each new behavior, current build/typecheck/lint/test output, end-to-end observations, failed attempts, and unresolved risks. Green tests alone do not prove the RED phase occurred.
+6. **Operational state** — for PR, identify production surfaces, live-data and client compatibility, indexes, TTLs, rules, variables, secrets, scheduled work, migrations, manual steps, and repository deployment constraints.
+
+## O — OPTIONS
+
+7. **Viable courses** — list the realistic choices for this boundary:
+    - LAUNCH: proceed with the planned approach, choose an established alternative, reduce or split scope, obtain a missing decision, or hold;
+    - COMMIT: commit as one unit, split the change, remove drift, add missing evidence, revise the design, or hold;
+    - PR: open or update now, reduce scope, stage behind a control, complete operational prerequisites, or hold.
+8. **Fallback course** — include the safest recovery or no-go option. Do not present a destructive action, silent scope increase, or unapproved one-way-door decision as routine execution.
+
+## R — RISKS & BENEFITS
+
+9. **Engineering tradeoffs** — for every option, compare correctness, architectural fit, simplicity, reviewability, delivery speed, reversibility, dependency cost, and maintenance burden. Name the concrete present-day benefit; speculative flexibility does not count.
+10. **Failure interrogation** — evaluate failure, retry, duplicate delivery, concurrency, partial execution, empty or hostile input, cancellation, 10× scale, and the single assumption that would invalidate the option.
+11. **Production exposure** — for PR, compare blast radius, degradation mode, rollback safety, live-data compatibility, infrastructure-before-code hazards, notification needs, and the observability available if the option fails.
+
+## D — DECISION
+
+12. **Explicit course** — select one option before acting. State the rationale, in-scope result, deferred work, exit criteria, accepted risks and owners, rollback or recovery course, and evidence that will prove success.
+13. **Approval gate** — obtain explicit user approval for schema shapes, public APIs, event formats, irreversible data writes, new production dependencies, destructive actions, or any option with no safe rollback. Without approval, the decision is **HOLD**.
+
+## E — EXECUTION
+
+14. **LAUNCH execution** — send a self-contained delegation, preserve existing user work, ensure the environment will remain available, and implement through RED → GREEN → REFACTOR using the selected architecture.
+15. **COMMIT execution** — remove out-of-scope work, satisfy the phase exit criteria, run the repository's targeted validation, encode lessons from failed attempts, and prepare the smallest coherent commit. Do not commit unless the user requested it.
+16. **PR execution** — prepare the exact deployment sequence and complete operational notes with explicit yes/no entries for indexes, TTLs, variables/secrets, scheduled functions, migrations, notifications, and manual commands. Do not open or update a PR unless the user requested it.
+
+## C — CHECK
+
+17. **Decision conformance** — compare the result with the selected option, architecture, scope, contracts, and exit criteria. Name every deviation; revert it or reopen FORDEC rather than accepting silent drift.
+18. **Observed verification** — report the actual build, typecheck, lint, test, and end-to-end outputs applicable to the boundary. Confirm every new behavior and every reachable failure path has evidence.
+19. **Risk and lesson closure** — restate each open risk with its current status and owner. Record the root cause of failed attempts in the repository's durable learning mechanism where one exists.
+20. **Monitoring trigger** — define the signal, observation window, threshold, and owner that will reveal failure after this boundary. State the condition that reopens the cycle or causes a rollback, pause, or go-around.
+
+## Report format
+
+Output:
+
+1. `Boundary: LAUNCH | COMMIT | PR`;
+2. a `Stage | # | item | PASS/FAIL/N-A | evidence` table;
+3. an **Options** list with one-line Risks and Benefits for each;
+4. a **Decision** line with rationale, owner, exit criteria, and accepted risks;
+5. an **Execution** line with actions actually completed;
+6. a **Check** line with observed results and the monitoring trigger;
+7. the verdict **CLEAR TO PROCEED** or **HOLD: <failing items or reopen conditions>**.
+
+A FAIL is a hard stop. Fix it, select another option, or escalate it; never proceed silently.

cellenium-0.2.1/.claude/skills/cellenium/landing/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: landing
+description: Final FORDEC production-readiness cycle. Use before final PR approval, merge, release, or production deployment to establish Facts, compare land and go-around Options, assess Risks and Benefits, make an explicit Decision, define or perform the authorized Execution, and Check production signals with rollback triggers.
+disable-model-invocation: true
+---
+
+# Landing — Final FORDEC Production Decision
+
+Purpose: make the last pre-production decision with the discipline of the aviation **FORDEC** model:
+
+1. **Facts**
+2. **Options**
+3. **Risks & Benefits**
+4. **Decision**
+5. **Execution**
+6. **Check**
+
+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` and the applicable `cruising` cycles have passed, when the completed change awaits final approval, merge, release, or deployment. This is the terminal production-readiness cycle.
+
+## How to run
+
+Run F → O → R → D → E → C 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 cycle.
+
+## F — FACTS
+
+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.
+
+## O — 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.
+
+## R — RISKS & 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.
+
+## D — 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.
+
+## E — 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.
+
+## C — CHECK
+
+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 starts a new FORDEC cycle with the new facts.
+
+## Report format
+
+Output:
+
+1. a `Stage | # | 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.

cellenium-0.2.1/.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 → cellenium-0.2.1}/.env.example

@@ -6,3 +6,4 @@ OPENAI_MODEL=openai/gpt-5.5
 OPENAI_API_KEY=
 TEST_HEADLESS=false
 LOGFIRE_TOKEN=
+CREDENTIALS_JSON=credentials.json

{cellenium-0.1.0 → cellenium-0.2.1}/.gitignore

@@ -1,11 +1,11 @@
-.env
-.*
-!.claude
-!.env.example
-data/
-*.egg-info/
-dist/
-credentials.json
-__pycache__/
-*.pyc
-.gstack/
+.env
+.*
+!.claude
+!.env.example
+data/
+*.egg-info/
+dist/
+credentials.json
+__pycache__/
+*.pyc
+.gstack/