cellpycore 0.2.0__tar.gz → 0.2.2__tar.gz

{cellpycore-0.2.0 → cellpycore-0.2.2}/.cursor/rules/issueflow-rules.mdc

@@ -88,6 +88,8 @@ cellpycore/
         02-partly-solved-issues/
         03-solved-issues/
         04-designs-and-guides/
+        05-epics/
+            epicXX_plan.md
     pyproject.toml
     readme.md
     ...
@@ -124,6 +126,10 @@ When the user message is **exactly** one of these forms, or **starts with** it f
 
 | `iflow close`, `iflow-close`, `/iflow-close`, `/iflow close` | `iflow-close` |
 
+| `iflow cycle`, `iflow-cycle`, `/iflow-cycle`, `/iflow cycle` | `iflow-cycle` |
+
+| `iflow epic`, `iflow-epic`, `/iflow-epic`, `/iflow epic` | `iflow-epic` |
+
 | `iflow fix`, `iflow-fix`, `/iflow-fix`, `/iflow fix` | `iflow-fix` |
 
 | `iflow graphify`, `iflow-graphify`, `/iflow-graphify`, `/iflow graphify` | `iflow-graphify` |
@@ -174,6 +180,10 @@ Lifecycle skills include a **`### MODEL & EXECUTION DIRECTIVE`** section that te
 
 `/iflow-status` prints a **read-only** overview of where every issue stands — the local tracking state under `.issueflows/` (focus / parked / solved) plus open GitHub issues cross-referenced against it. It is off-path (never auto-dispatched) and changes nothing.
 
+`/iflow-epic <N>` plans a change **too large for one issue** as a staged epic: it drafts `.issueflows/05-epics/epic<N>_plan.md` (anchored to GitHub issue `<N>`), dividing the work into sequential stages of manageable issue specs with explicit dependencies and a per-issue yolo-fitness judgment. Drafting writes nothing on GitHub; **`/iflow-epic <N> publish [stage <k>]`** creates a confirmed stage's issues behind one consolidated confirm (yolo labels per the recorded judgment, task list maintained on the anchor issue, `Published: #<M>` recorded back into the plan so re-runs are idempotent). Off-path (never auto-dispatched); epics decompose into the normal single-issue lifecycle, never around it.
+
+`/iflow-cycle <queue-spec>` processes **many issues hands-off in a row** under a single up-front confirmation — the batch equivalent of `/iflow-yolo`. It resolves a queue via `issue-flow agent queue` (explicit numbers, `label:<L>`, or `epic <N> [stage <k>]`), then runs each issue through the full yolo chain (PR auto-merged), interrupting you only when input is **strictly necessary** (unfixable failure, refused merge / non-fast-forward pull, ambiguous or not-actually-small spec, or anything outside the confirmed queue). It stops the whole cycle on the first such condition, leaving the repo clean on the default branch. Off-path (never auto-dispatched); never weakens a yolo safeguard to keep moving.
+
 `/iflow-archive` condenses old solved issue groups under `.issueflows/03-solved-issues/` into a single dated `YYYY-MM-DD_archived_issues.md` summary file (recording the pre-archive git ref for recovery via `git show <ref>:<path>`), then deletes the original `issue<N>_*` files. It is off-path and destructive: nothing is deleted before one consolidated confirmation.
 
 > On tools without project slash commands (e.g. Codex CLI), invoke the mirrored Agent Skills instead (for example `iflow-init` in place of `/iflow-init`).

{cellpycore-0.2.0 → cellpycore-0.2.2}/.cursor/skills/iflow/SKILL.md

@@ -92,7 +92,7 @@ When `.issueflows/04-designs-and-guides/multi-repo-workspaces.md` exists, read i
 
 ## Constraints
 
-- Never auto-dispatch to `/iflow-pick`, `/iflow-pause`, `/iflow-cleanup`, `/iflow-yolo`, or `/iflow-fix`.
+- Never auto-dispatch to `/iflow-pick`, `/iflow-pause`, `/iflow-cleanup`, `/iflow-yolo`, `/iflow-fix`, `/iflow-epic`, or `/iflow-cycle`.
 - If the focus issue cannot be resolved (multiple groups, branch ambiguous), stop and ask.
 - Do not modify files beyond what the downstream command would normally modify. `/iflow` itself writes nothing — all file changes come from the dispatched command.
 - Dispatch to at most one command per `/iflow` invocation.

{cellpycore-0.2.0 → cellpycore-0.2.2}/.cursor/skills/iflow-cleanup/SKILL.md

@@ -71,7 +71,9 @@ When `.issueflows/04-designs-and-guides/multi-repo-workspaces.md` exists, read i
 
 5. **Optional folder sweep** (safe; no destructive git). In `.issueflows/01-current-issues/`, for each `issue<N>_*` group whose status file contains `- [x] Done` (case-insensitive on `done`), move the group to `.issueflows/03-solved-issues/`. Leave groups without a checked `Done` in place — routing them to `.issueflows/02-partly-solved-issues/` is `/iflow-pause`'s job.
 
-6. **Report.** Summarize: default branch, PR/merge status, commands run, branches deleted, branches skipped (with reason), folder sweep result. If `issue-flow agent resolve --json` reports `sibling_roots`, list them and remind the user that **each scaffolded repo needs its own `/iflow-cleanup`** — do not loop automatically in this step.
+6. **Epic stage gate (offer only).** If the just-merged issue belongs to an epic — its number appears in a `- Published: #<N>` line of an `epic<M>_plan.md` under `.issueflows/05-epics/` — check whether that closed the stage: run `issue-flow agent epic-status <M> --json` and see if the issue's stage now has no open issues left. If the stage just completed, **offer** (do not do automatically) to (a) post a short stage-summary comment on the epic anchor issue and (b) run `/iflow-epic <M> publish` to publish the next stage. Both are the user's explicit call — never auto-publish or auto-comment.
+
+7. **Report.** Summarize: default branch, PR/merge status, commands run, branches deleted, branches skipped (with reason), folder sweep result, and any epic stage-gate offer. If `issue-flow agent resolve --json` reports `sibling_roots`, list them and remind the user that **each scaffolded repo needs its own `/iflow-cleanup`** — do not loop automatically in this step.
 
 ## Constraints
 

cellpycore-0.2.2/.cursor/skills/iflow-cycle/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: iflow-cycle
+description: >-
+  Process many issues hands-off in a row: resolve a queue, then run each
+  through the yolo chain under one up-front confirm. Stops only when input is
+  strictly necessary.
+disable-model-invocation: true
+issue-flow-version: 0.4.2a4
+---
+
+# issue-flow — issue cycle (`/iflow-cycle`)
+
+Follow this skill to **process a queue of issues hands-off**, one after another, with a **single up-front confirmation** — the batch equivalent of `/iflow-yolo`. Each issue runs the full yolo chain (`init → plan → start → close yolo`, PR auto-merged, switch back to default); the cycle interrupts you only when input is **strictly necessary**.
+
+Use only when every queued issue is genuinely yolo-fit (small, low-risk, well-specified, test-guarded). A queue of risky changes belongs in the individual commands.
+
+## Input — queue spec
+
+- **explicit numbers** — e.g. `12 15 18`.
+- **`label:<L>`** — every open issue carrying label `<L>`.
+- **`epic <N> [stage <k>]`** — the current stage of epic `<N>` (or stage `<k>`).
+- **`resume`** — pick up an interrupted cycle from its state file (see **Resuming** below).
+- **`onfail:stop`** (default) / **`onfail:skip`** — failure policy (see step 7).
+- **`max:<n>`** — raise the safety cap (default 10) for this run.
+- **`stay`** — forward `stay` to each close so the working copy stays on each issue branch (rarely wanted in a cycle).
+
+
+**Invoke:** type `iflow cycle` in chat, or `/iflow-cycle` from the slash menu (`iflow-cycle` also works).
+
+
+
+
+### MODEL & EXECUTION DIRECTIVE
+
+
+**Profile: reasoning** — Prioritize deep thinking and careful trade-offs over speed or token economy.
+
+In Cursor: switch to a thinking-capable model before invoking this step (not Auto-only).
+
+
+
+Keep scope tight to what this step requires.
+
+
+
+
+### Resolve project root (multi-root workspaces)
+
+Before any `git`, `gh`, or `.issueflows/` path operation in this workflow:
+
+**Resolution order** (stop when unambiguous):
+
+1. **Explicit hints** in slash input — `root:<path>`, `repo:<folder-basename>` (directory name, e.g. `cellpy-core`), or `repo:owner/name`.
+2. **CLI fast path** — `issue-flow agent resolve [-C <start>] [--from-file <active-file>] [--json]`. Use the returned `project_root` and `repo`; pass `-C <project_root>` to other `issue-flow agent …` subcommands. When the answer came from the workspace registry, the payload sets `resolved_via_workspace_default: true`.
+3. **Branch context** — exactly one workspace repo whose branch matches `^\d+-` → that root.
+4. **Single scaffold** — exactly one `.issueflows/` tree visible in the workspace → that root.
+5. **Workspace default** — an `issueflow-workspace.toml` at the workspace root (created with `issue-flow workspace init`) may name a `default` member repo; use it when no scaffold matched above. Tell the user the default was used.
+6. **Ambiguous** → **stop and ask**; never guess between sibling repos.
+
+After resolution, treat the result as `<project_root>` and `<owner/repo>`:
+
+- **Git:** `git -C <project_root> …` (or `issue-flow agent … -C <project_root>` for supported ops).
+- **GitHub:** always `gh … --repo <owner/repo>` — never rely on `gh`'s implicit cwd default.
+- **Paths:** all `.issueflows/…` paths are under `<project_root>`.
+
+When `.issueflows/04-designs-and-guides/multi-repo-workspaces.md` exists, read it for layout and cross-repo guidance.
+
+## Instructions
+
+1. **Resolve the queue.** Run `issue-flow agent queue <spec> --json` (numbers, `--label`, or `--epic`). Use its `queue` (ordered), `blocked`, and `skipped_closed` output as the source of truth — do not re-derive the order by hand. If it reports a dependency `cycle`, **stop** and show it; nothing runs. If the CLI is unavailable, fall back to reading the issues and ordering by `Depends on #N` lines yourself, but prefer the CLI.
+
+2. **Cap check.** If the ordered queue is longer than **10** and the input did not pass `max:<n>` raising the limit, **stop** and ask the user to confirm a larger run explicitly. Long unattended runs compound risk.
+
+3. **One consolidated confirm** (the only planned interruption). Present, in normal prose:
+   - the **ordered** queue (numbers + titles), and which issues are **skipped** (closed) or **blocked** (open dependency outside the queue) with the reason;
+   - that each issue runs the **full yolo chain** and its PR is **auto-merged**;
+   - the failure policy (`onfail:stop`, the default, or `onfail:skip` — see step 7);
+   - the default-branch preflight that must hold before starting (clean tree, tests passing).
+   Require an explicit yes; anything else aborts before any work.
+
+4. **Write the cycle state file.** After the confirm, write `.issueflows/01-current-issues/cycle_status.md` — the durable record that makes the run resumable and visible to `/iflow-status`. Include: the queue spec, the `onfail` policy, an ISO timestamp, and the ordered queue as a checklist with one line per issue (`- [ ] #<N> — <title> — pending`). Update this file as the loop progresses (see step 5); it is a normal tracking file (not an `issue<N>_*` group), so the folder sweep never touches it.
+
+5. **Per-issue loop.** For each issue in order, from a clean default branch:
+   - mark it `in-progress` in `cycle_status.md`, then create/switch to its `<N>-<slug>` branch and follow `.cursor/skills/iflow-yolo/SKILL.md` **verbatim** — including its own preflight (refuse on default branch, refuse with dirty unrelated changes, tests pass up front) and its consolidated-confirm step, which the up-front batch confirm in step 3 satisfies (do not re-ask per issue).
+   - after the yolo close merges and switches back to the default branch, record the outcome in `cycle_status.md` (`- [x] #<N> — <title> — merged <PR-url>`) and continue to the next issue.
+   - Every yolo safeguard stays in force. A safeguard that trips is a **stop condition** (step 6), never a guard to skip.
+
+6. **Strictly-necessary-input rule.** Between issues the cycle runs unattended. **Stop and ask only** when:
+   a. tests or lint fail in a way you cannot fix within the current issue's scope;
+   b. a merge is refused or a `git pull --ff-only` will not fast-forward (divergence);
+   c. the issue spec is ambiguous, contradictory, or turns out **not** small (yolo's scope check aborts);
+   d. an action would fall **outside the confirmed queue** (touching an unlisted issue, an unrelated dirty file, a destructive op).
+   Anything else — routine implementation choices, passing tests, clean merges — proceeds without asking.
+
+7. **Failure policy** (from the `onfail:` token; default **stop**). When a stop condition (step 6) trips on an issue:
+   - **`onfail:stop`** (default) — **halt the cycle**: finish no further issues, leave the repo on the **default branch, clean** (the in-flight issue's branch stays as-is for the user to inspect), record the stop reason and the not-reached issues in `cycle_status.md`, and report. Do not attempt the rest of the queue.
+   - **`onfail:skip`** — **park and continue**: record the failure against that issue in `cycle_status.md` (`- [~] #<N> — <title> — failed: <reason>`), park its work per `.cursor/skills/iflow-pause/SKILL.md` conventions (status note + move to `02-partly-solved-issues/`), return to a clean default branch, and proceed to the next queued issue. A skip never bypasses a yolo safeguard — it records the trip and moves on.
+
+8. **Finish.** When the queue is exhausted (or halted), finalize `cycle_status.md` (mark it `- [x] Done`) and move it to `.issueflows/03-solved-issues/cycle_status_<YYYY-MM-DD>.md` so it is archived, not re-detected as in-flight.
+
+9. **Batch report.** Summarize the whole run: per issue — number, title, PR URL, merge result (merged / queued via `--auto` / failed-and-skipped / not reached), and duration if tracked; then the queue items **skipped** (closed), **blocked** (with blockers), and — on a halt — the **stop reason** and which issues were **not reached**. End by reminding the user to run `/iflow-cleanup` once to prune the merged local branches.
+
+## Resuming
+
+`/iflow-cycle resume` picks up an interrupted cycle:
+
+1. Read `.issueflows/01-current-issues/cycle_status.md`. If it is missing, tell the user there is no in-flight cycle and stop.
+2. Take the **remaining** issues (those still `pending` / `in-progress`) and **re-verify** them with `issue-flow agent queue <original-spec> --json` — an issue that has since closed, or become blocked, is dropped/deferred with a note (state can move while a cycle is paused).
+3. **Do not re-ask the original consolidated confirm** for the unchanged remaining items — the batch was already authorized. Ask again only if the re-verified queue differs materially from what was confirmed (new blockers, added issues), and only about the delta.
+4. Continue the per-issue loop (step 5) with the same `onfail` policy recorded in the file.
+
+## Parallel dispatch (experimental, opt-in)
+
+By default the cycle is **sequential** — one issue fully lands before the next starts. When the input passes **`parallel:<n>`** *and* the harness supports background execution, provably independent issues may run concurrently (up to `n` at a time). This is experimental; the sequential path above is always the default and is never weakened to enable it.
+
+- **Only independent issues qualify.** Use `issue-flow agent queue`'s **`independent`** list — issues with *no* dependency relation (either direction) to any other queue member. Everything else runs sequentially.
+- **Harness gate.** If you cannot confirm the harness supports background execution (worktrees + parallel agents/subagents), **refuse `parallel:<n>` and run sequentially** — never pretend to parallelize.
+- **Worktree per issue.** `git worktree add ../<repo>-<N> <N>-<slug>` so each issue has an isolated tree; run the yolo work there.
+- **Serialize merges.** Never merge PRs concurrently — the coordinating session merges them one at a time on the default branch, pulling between merges and rebasing/retrying on a non-fast-forward or CI refusal.
+- **Shared files via the coordinator only.** Parallel workers must **not** each edit `HISTORY.md`; each leaves its changelog bullet in its issue status file / PR body, and the coordinator appends them in **merge order** during the serial merge step.
+
+When in doubt, prefer the sequential run — parallel dispatch trades safety for speed and every one of the rules above must hold.
+
+## Constraints
+
+- **Off-path**: `/iflow` never auto-dispatches to `/iflow-cycle`; it is an explicit, deliberate batch action.
+- **Sequential is the default and floor.** Parallelism (`parallel:<n>`) is opt-in and experimental; refusing it must always leave a working sequential run.
+- Never weaken a yolo safeguard to keep the cycle moving — safeguards are stop conditions, not obstacles.
+- Never run `/iflow-cleanup` from this skill; batch branch deletion still needs the user to see the merged PRs first.
+- One consolidated confirm covers the batch; never silently expand the queue beyond what was confirmed.
+- `cycle_status.md` is the single source of truth for an in-flight cycle: keep it current so `resume` and `/iflow-status` stay accurate. It is not an `issue<N>_*` group, so the folder sweep leaves it alone; archive it (step 8) when the run ends.

cellpycore-0.2.2/.cursor/skills/iflow-epic/SKILL.md

@@ -0,0 +1,137 @@
+---
+name: iflow-epic
+description: >-
+  Plan a larger change as a staged epic: draft epic<N>_plan.md with stages of
+  manageable issue specs, then publish confirmed stages as GitHub issues.
+disable-model-invocation: true
+issue-flow-version: 0.4.2a4
+---
+
+# issue-flow — epic planning (`/iflow-epic`)
+
+Follow this skill to plan a change that is **too large for one issue**: divide it into sequential **stages**, each stage into **manageable issues** that flow through the normal lifecycle (`/iflow-init` → `/iflow-plan` → `/iflow-start` → `/iflow-close`).
+
+The surface has two actions. **Drafting** (the default) is write-free on GitHub: its deliverable is `.issueflows/05-epics/epic<N>_plan.md`, and it never creates GitHub issues, labels, or milestones. **`publish`** is the single exception — it turns a *confirmed* plan into real GitHub issues, stage by stage, behind one consolidated confirm.
+
+## Input
+
+- **`<N>`** — the GitHub issue number of the **epic anchor** (an umbrella issue describing the large change). Required: an epic without an anchor has nowhere to track progress. If no anchor issue exists yet, stop and ask the user to create one (title prefixed `Epic:`, label `epic` when available) — creating it is the user's call, not this skill's.
+- **`publish [stage <k>]`** — run the publish action (below) instead of drafting. Without a stage number, the earliest stage with unpublished specs is chosen.
+- Optional free text — extra context, constraints, or a proposed stage split to seed the draft.
+
+
+**Invoke:** type `iflow epic` in chat, or `/iflow-epic` from the slash menu (`iflow-epic` also works).
+
+
+
+
+### MODEL & EXECUTION DIRECTIVE
+
+
+**Profile: reasoning** — Prioritize deep thinking and careful trade-offs over speed or token economy.
+
+In Cursor: switch to a thinking-capable model before invoking this step (not Auto-only).
+
+
+
+Keep scope tight to what this step requires.
+
+
+
+
+### Resolve project root (multi-root workspaces)
+
+Before any `git`, `gh`, or `.issueflows/` path operation in this workflow:
+
+**Resolution order** (stop when unambiguous):
+
+1. **Explicit hints** in slash input — `root:<path>`, `repo:<folder-basename>` (directory name, e.g. `cellpy-core`), or `repo:owner/name`.
+2. **CLI fast path** — `issue-flow agent resolve [-C <start>] [--from-file <active-file>] [--json]`. Use the returned `project_root` and `repo`; pass `-C <project_root>` to other `issue-flow agent …` subcommands. When the answer came from the workspace registry, the payload sets `resolved_via_workspace_default: true`.
+3. **Branch context** — exactly one workspace repo whose branch matches `^\d+-` → that root.
+4. **Single scaffold** — exactly one `.issueflows/` tree visible in the workspace → that root.
+5. **Workspace default** — an `issueflow-workspace.toml` at the workspace root (created with `issue-flow workspace init`) may name a `default` member repo; use it when no scaffold matched above. Tell the user the default was used.
+6. **Ambiguous** → **stop and ask**; never guess between sibling repos.
+
+After resolution, treat the result as `<project_root>` and `<owner/repo>`:
+
+- **Git:** `git -C <project_root> …` (or `issue-flow agent … -C <project_root>` for supported ops).
+- **GitHub:** always `gh … --repo <owner/repo>` — never rely on `gh`'s implicit cwd default.
+- **Paths:** all `.issueflows/…` paths are under `<project_root>`.
+
+When `.issueflows/04-designs-and-guides/multi-repo-workspaces.md` exists, read it for layout and cross-repo guidance.
+
+> **CLI fast path (optional).** If the `issue-flow` CLI is on `PATH`, run
+> `issue-flow agent epic-status <N> --json` for a deterministic picture of an
+> existing epic: stages, per-issue state and blockers, the current stage, and
+> the next open, unblocked candidates. Use it before re-drafting a stage and
+> in the publish action's stage selection. Read-only; add `--local` to skip
+> the GitHub lookups.
+
+## Instructions
+
+1. **Gather context (read-only).** Read the epic anchor (`gh issue view <N> --repo <owner/repo>`), skim `.issueflows/04-designs-and-guides/` for relevant design docs (cite them in the plan when they shape the approach), and — when `graphify-out/GRAPH_REPORT.md` exists — skim it before grepping.
+
+2. **Draft the staged plan** at `.issueflows/05-epics/epic<N>_plan.md` using exactly this structure (the publish step parses it):
+
+   ```markdown
+   # Epic #<N>: <title>
+
+   Anchor: <GitHub issue URL>
+   Status: draft
+
+   ## Goal
+
+   <what the whole epic achieves, and how we know it is done>
+
+   ## Constraints
+
+   <hard boundaries, non-goals, ordering requirements>
+
+   ## Stage 1 — <stage title>
+
+   <one paragraph: what this stage proves or delivers>
+
+   ### Issue: <title as it will appear on GitHub>
+
+   - Spec: <self-contained paragraph: context, scope, acceptance criteria>
+   - Depends on: none | #<M> | stage <j> issue <k>
+   - yolo: yes | no — <one-line judgment against the yolo-fitness criteria>
+
+   ### Issue: <next issue title>
+   ...
+
+   ## Stage 2 — <stage title>
+   ...
+   ```
+
+   The `publish` action later appends a `- Published: #<M>` line to each spec it creates — never add those by hand.
+
+3. **Sizing rules for issue specs** — every issue must be *manageable*:
+   - one issue = one branch = one PR, implementable in roughly a day or less;
+   - a **crisp acceptance criterion** someone else could verify;
+   - dependencies stated explicitly: `#<M>` for already-published issues, `stage <j> issue <k>` placeholders for unpublished ones (the publish step resolves placeholders to real numbers);
+   - a **yolo-fitness judgment** per issue: `yes` only when it is well-specified, mechanical or pattern-following, low blast radius, and guarded by existing tests — umbrella work, design decisions, and flag-day changes are `no`.
+
+4. **Stage discipline** — stages are sequential milestones, each small enough that finishing it can change the plan for the next. Front-load the stage that retires the most risk. Do not plan more than 2–3 stages in detail; sketch later stages as bullets under a `## Later (unstaged)` heading instead of fake-precise issue specs.
+
+5. **Review with the user.** Present the draft (stage titles, issue titles, dependency graph, yolo flags) and iterate until they confirm. Record the confirmation by changing `Status: draft` to `Status: confirmed` in the plan file.
+
+6. **Stop.** Creating the GitHub issues is the `publish` action below, with its own consolidated confirm — never create them from the drafting flow, even if asked to "just create them": run `/iflow-epic <N> publish` explicitly so the confirm gates stay distinct.
+
+## Action: publish
+
+Turn one stage of a **confirmed** plan into real GitHub issues. Requires `Status: confirmed` in `epic<N>_plan.md` — refuse drafts and point at the review step instead.
+
+1. **Select the stage.** A named `stage <k>` publishes exactly that stage; otherwise pick the earliest stage containing specs without a `Published:` line. Specs that already carry `- Published: #<M>` are **skipped** (this makes re-runs idempotent).
+2. **Dry-run listing.** Show what would be created: per spec — title, labels (`yolo` when the judgment says yes **and** the label exists per `gh label list`; otherwise note the gap), and the dependency lines after placeholder resolution. `stage <j> issue <k>` placeholders pointing at already-published specs are rewritten to their real `#<M>`; placeholders at still-unpublished specs stay verbatim with a note.
+3. **Consolidated confirm** (destructive-ish — outward-facing writes; normal prose, never shortened). One prompt covering exactly: which issues get created, with which labels, and that the anchor issue's task list will be updated. Do not proceed without a clear yes.
+4. **Create, in dependency order within the stage.** For each spec: `gh issue create --repo <owner/repo>` with the self-contained body (context, scope, acceptance criteria, resolved `Depends on: #<M>` lines, and a closing `Part of epic #<N>.` line). Immediately record the new number in the plan file as `- Published: #<M>` under that spec.
+5. **Update the anchor issue's task list** (append/patch only — never rewrite the user's own body text): fetch the body, append a `## Stage <k> — <title>` section (or extend it) with one `- [ ] #<M>` line per created issue, and write it back via `gh issue edit <N> --body-file`.
+6. **Report.** Created issues (numbers + titles + labels), skipped already-published specs, unresolved placeholders, and the reminder that the next stage publishes only after this one's issues close.
+
+## Constraints
+
+- **Drafting writes nothing on GitHub**: no `gh issue create`, no label or milestone writes, no task-list edits on the anchor issue. Reading with `gh issue view` / `gh issue list` is always fine. The `publish` action is the single exception and never runs without its consolidated confirm.
+- **Off-path**: `/iflow` never auto-dispatches to `/iflow-epic`; the user opts in explicitly.
+- Epics decompose **into** the normal single-issue lifecycle, never around it — no issue spec may assume work happens outside a normal issue branch + PR.
+- The plan file is user-owned working state under `.issueflows/`: `issue-flow update` never touches it.

{cellpycore-0.2.0 → cellpycore-0.2.2}/.cursor/skills/iflow-pick/SKILL.md

@@ -68,8 +68,9 @@ When `.issueflows/04-designs-and-guides/multi-repo-workspaces.md` exists, read i
 2. **`fix` shortcut.** If the user passed `fix`, skip selection and go to step 5 (create a new general-fixes issue), then Phase 2.
 3. **Source candidates** (precedence):
    - **Parked work first** — list `issue<n>_*` groups in `.issueflows/02-partly-solved-issues/` as the primary candidates (already-started work to finish first).
+   - **Active epic next** — if an epic plan under `.issueflows/05-epics/` has open issues (or the user named one, e.g. `epic 144`), prefer its **current stage's unblocked issues**. Use the fast path `issue-flow agent epic-status <N> --json` when the CLI is on `PATH` — its `next_candidates` are exactly the open, dependency-satisfied issues of the current stage. Surface those at the top of the shortlist so an epic advances stage by stage instead of stalling.
    - **Else GitHub** — `gh issue list --state open --json number,title,labels,milestone,updatedAt` (add `--repo owner/repo` if ambiguous). Drop issues already captured under `01-current-issues/`, `02-partly-solved-issues/`, or `03-solved-issues/`.
-4. **Rank and present.** Rank by **milestone** (nearest/active, honour any hint) + **labels** (match recent work / hint) + **topical similarity** to recently solved issues (skim `.issueflows/03-solved-issues/` and recent branch names). Show a numbered shortlist (~3–7) with number, title, labels, milestone, and **ask the user to confirm** the pick or override. Never pick silently.
+4. **Rank and present.** Rank by **epic membership** (an active epic's current-stage `next_candidates` first) + **milestone** (nearest/active, honour any hint) + **labels** (match recent work / hint) + **topical similarity** to recently solved issues (skim `.issueflows/03-solved-issues/` and recent branch names). Show a numbered shortlist (~3–7) with number, title, labels, milestone, and (for epic issues) the epic + stage, and **ask the user to confirm** the pick or override. Never pick silently.
 5. **Create a `fix` issue (only when requested).** Use `gh issue create` (e.g. `chore: general fixes`), confirm title/body first, capture the new number. A fresh issue is created each time — never reuse an existing open general-fixes issue.
 6. **Over-large issue (note only).** If the chosen issue is too big for one PR, **mention** that breaking it into sub-issues is possible and tracked as a follow-up (Phase B of issue #63). Do **not** auto-create sub-issues here.
 

{cellpycore-0.2.0 → cellpycore-0.2.2}/.cursor/skills/iflow-status/SKILL.md

@@ -75,6 +75,8 @@ When `.issueflows/04-designs-and-guides/multi-repo-workspaces.md` exists, read i
 
 4. **Solved archive** (`.issueflows/03-solved-issues/`). Report the count of distinct solved issue numbers and the most recent few.
 
+4a. **In-flight cycle.** If `.issueflows/01-current-issues/cycle_status.md` exists, a `/iflow-cycle` batch run is paused or active — report it and its progress (from the file's checklist), and note that `/iflow-cycle resume` continues it. (`issue-flow status --json` reports this as `cycle_active`.)
+
 5. **Open GitHub issues** (skip if the user passed `local`). Run `gh issue list --state open --json number,title,labels,milestone,updatedAt` and tag each issue's local state: **focus**, **parked**, **solved-locally**, or **untracked**. If `gh` is missing/unauthenticated, skip this section and note it (suggest `gh auth login`) — never fail.
 
 6. **Summary line.** One terse line, e.g. `Focus: #20 (start). Parked: 2. Solved: 31. Open on GitHub: 7 (5 untracked).`

cellpycore-0.2.2/.gitattributes

@@ -0,0 +1,14 @@
+# GitHub Linguist: keep language stats focused on library source.
+# Without this, graphify-out/graph.html (~3.8MB) dominates as HTML.
+
+graphify-out/** linguist-generated
+docs/** linguist-documentation
+tests/** linguist-documentation
+.issueflows/** linguist-documentation
+dev/** linguist-documentation
+scripts/** linguist-documentation
+
+# Cross-platform line endings for shell helpers
+.aliases     text eol=lf
+*.sh         text eol=lf
+*.lock       text eol=lf

cellpycore-0.2.2/.issueflows/03-solved-issues/issue136_original.md

@@ -0,0 +1,60 @@
+# Issue #136: Legacy bridge: preserve test_id through steps/summary output; legacy-schema support for merge_data
+
+Source: https://github.com/cellpy/cellpy-core/issues/136
+
+## Original issue text
+
+## Summary
+
+The `OldCellpyCellCore` legacy bridge strips `test_id` from the outbound
+step/summary frames, which degrades multi-test (campaign-merged) objects to
+cycle-only summary grouping. cellpy #507 works around it; these requests make
+the workaround unnecessary and unblock campaign merges that keep original
+per-test cycle numbers.
+
+## Details
+
+1. **Outbound `test_id` stripping.** `_native_steps_to_legacy` re-projects to a
+   fixed legacy column order (cell_core.py ~781-815) and the summary path
+   filters to `_legacy_summary_column_order` (~928-1065); `test_id` is in
+   `NATIVE_ONLY_STEP` / `NATIVE_ONLY_CYCLE` (mapping.py ~191-196, 227-231). The
+   inbound side is fine: a raw `test_id` column passes through (exception
+   lists, mapping.py ~129-144) and `make_step_table` groups on
+   `(test_id, cycle_num, step_num)` (proven by the cycler_small golden).
+2. **Bridge summary rebuilds native steps from the stripped legacy steps**
+   (`make_core_summary`, cell_core.py ~1010-1012), so
+   `use_tid` (summarizers.py ~792) is always False through the bridge —
+   cycle-only grouping, no per-test windowing, and cross-test collision when
+   cycle numbers overlap. cellpy #507's workaround: re-stamp `test_id` onto the
+   legacy steps frame post-bridge (depends on the inbound step rename staying
+   rename-only with no column filtering — please treat that as a contract or
+   provide the fix below).
+3. **`_add_legacy_summary_cruft`** (cell_core.py ~960-978) does global pandas
+   cumsums (cumulated CE, shifted_*, cumulated_ric*) even when the engine
+   windowed per test — these columns are wrong for multi-test objects.
+4. **`merge_data(schema=<legacy Schema>)` raises `AttributeError`** —
+   `HeadersNormal` lacks the native attribute names (`datapoint_num`,
+   `cycle_num`, `test_id`), and passing the native schema instead silently
+   skips offsets on legacy-named frames (`_max_column` returns 0 for missing
+   columns). Either document legacy schemas as unsupported for merge/update, or
+   add attribute aliases so bridge consumers can call
+   `merge_data`/`update_data` directly (cellpy #507 mirrors the semantics in
+   pandas instead).
+
+## Requests
+
+- [ ] Carry `test_id` through the legacy step output (or have
+      `make_core_summary` reuse the native steps it already computed instead of
+      rebuilding from the stripped legacy frame).
+- [ ] Optionally expose `test_id` in the legacy summary output behind a flag.
+- [ ] Window `_add_legacy_summary_cruft` per `test_id` when present.
+- [ ] Resolve the `merge_data` legacy-schema story (docs or aliases).
+- [ ] Together these unblock `renumber_cycles=False` (original per-test cycle
+      numbers) for cellpy's campaign merge ahead of the native-schema path
+      (cellpy #511).
+
+## Refs
+
+cellpy jepegit/cellpy#507 (campaign merge + workaround), jepegit/cellpy#511
+(native schema opt-in), core tests test_golden.py (cycler_small composite-key
+golden), test_merge.py / test_e2e.py (native multi-test invariants).

cellpycore-0.2.2/.issueflows/03-solved-issues/issue136_plan.md

@@ -0,0 +1,87 @@
+# Issue #136 — plan
+
+Source: https://github.com/cellpy/cellpy-core/issues/136
+
+## Goal
+
+Legacy bridge keeps `test_id` on outbound steps (and summary when present) so
+campaign-merged multi-test objects get per-test summary windowing through the
+bridge — no cellpy #507 re-stamp workaround. Also fix legacy-cruft cumsums and
+clarify `merge_data` + legacy schema.
+
+## Constraints
+
+- Back-compat: single-test objects already have `test_id=0` on raw; emitting
+  `test_id` on steps/summary is **additive** (extra column). Goldens that pin
+  exact column sets may need updates.
+- Mapping totality (`NATIVE_ONLY_*` / attr maps) must stay consistent.
+- Do not change native engine behaviour; bridge-only (+ headers/mapping).
+- Unblocks cellpy #510 V2-15 pin after a **new** cellpycore PyPI release.
+
+### Prior art
+
+| Hit | Role | Plan |
+|-----|------|------|
+| [`OldCellpyCellCore._native_steps_to_legacy`](../../src/cellpycore/cell_core.py) / `_legacy_step_column_order` | Drops unknown cols via fixed order | **Extend** order with `test_id` when present |
+| [`make_core_summary`](../../src/cellpycore/cell_core.py) rebuilds native steps from legacy `data.steps` | `use_tid` false after strip | Fixed once steps carry `test_id` through rename |
+| [`_add_legacy_summary_cruft`](../../src/cellpycore/cell_core.py) | Global pandas cumsums | **Window** by `test_id` when column present |
+| [`NATIVE_ONLY_STEP` / `NATIVE_ONLY_CYCLE`](../../src/cellpycore/legacy/mapping.py) | Declares `test_id` intentionally unbridged | **Remove** `test_id`; add identity scalar/cycle pairs |
+| [`HeadersStepTable` / `HeadersSummary`](../../src/cellpycore/legacy/headers.py) | No `test_id` field today | **Add** `test_id: str = "test_id"` |
+| cellpy [`cellreader.make_step_table` re-stamp](../../../cellpy/cellpy/readers/cellreader.py) (~2293) | Workaround | Becomes redundant after this; leave for a cellpy follow-up |
+| [`merge_data`](../../src/cellpycore/merge.py) | Expects native `Schema` attrs | **Document + hard error** on legacy header schema (cellpy already uses pandas merge) |
+| Toolbox `00-tools/` | Empty | None |
+| Graph | Bridge / mapping communities | Touch `cell_core` + `legacy/mapping` + `legacy/headers` |
+
+## Approach
+
+1. **Steps outbound:** Add `HeadersStepTable.test_id`. Put `test_id` early in
+   `_legacy_step_column_order` (before cycle/step). Add identity
+   `STEP_SCALAR_PAIRS` entry `("test_id", "test_id")`; drop `test_id` from
+   `NATIVE_ONLY_STEP`. Update attr maps (`LEGACY_ATTR_TO_SCHEMA` /
+   `LEGACY_ATTR_UNMAPPED`) for the new header field.
+2. **Summary outbound:** Add `HeadersSummary.test_id`. Include in
+   `_legacy_summary_column_order` (near `cycle_index`) when present after rename.
+   Add identity `CYCLE_PAIRS` entry; drop `test_id` from `NATIVE_ONLY_CYCLE`.
+   No flag — always pass through when the native summary has it (single-test →
+   all `0`).
+3. **Cruft:** In `_add_legacy_summary_cruft`, if `test_id` in summary columns and
+   `nunique > 1` (or always when column present): compute cumsums / shifted /
+   ric **per group**; else keep today's global behaviour.
+4. **`merge_data` + legacy schema:** At entry, if `schema.raw` is
+   `HeadersNormal` (or lacks `datapoint_num` / `cycle_num` / `test_id`), raise
+   `TypeError` with a clear message: use `config.default_schema()` / native
+   `Schema`. Document in `merge_data` docstring. No full legacy-schema merge
+   implementation in this issue (cellpy does not call it).
+5. **Tests:** Bridge multi-test fixture (or reuse schema/e2e multi-test raw) →
+   `make_core_step_table` / `make_core_summary` → assert `test_id` on steps and
+   summary `{0,1}`; assert summary cumulatives restart per test. Mapping
+   totality tests update with the exception-set moves. One test that
+   `merge_data(..., schema=legacy.schema)` raises the new TypeError.
+
+## Files to touch
+
+| Path | Change |
+|------|--------|
+| `src/cellpycore/legacy/headers.py` | `test_id` on step + summary headers |
+| `src/cellpycore/legacy/mapping.py` | pairs / `NATIVE_ONLY_*` / attr maps + comments |
+| `src/cellpycore/cell_core.py` | column order, cruft windowing |
+| `tests/test_*.py` (bridge / mapping / merge) | new + update totality |
+| `CHANGELOG` / HISTORY if present | note for 0.2.2 release |
+
+## Test strategy
+
+```bash
+uv run pytest
+uv run ruff check && uv run ruff format --check
+```
+
+Focus: new bridge multi-test test + `tests/test_header_mapping.py` totality +
+`tests/test_merge.py` legacy-schema error.
+
+## Decisions (confirmed 2026-07-17)
+
+1. **Summary `test_id`:** always when present (no flag).
+2. **`merge_data` legacy schema:** hard `TypeError` + docstring (also
+   `update_data`).
+3. **Cruft windowing:** when `test_id` column exists (groupby).
+4. **Goldens:** regenerate stage-B step/summary snapshots (additive `test_id`).

cellpycore-0.2.2/.issueflows/03-solved-issues/issue136_status.md

@@ -0,0 +1,18 @@
+# Issue #136 — status
+
+- [x] Done
+
+## What's done
+
+- Plan confirmed (2026-07-17): carry `test_id` on steps+summary; window cruft;
+  hard-error legacy schema on merge/update; regenerate goldens.
+- Implemented on `136-legacy-bridge-preserve-test-id`.
+- Version bumped `0.2.1` → `0.2.2` (static `pyproject.toml`); HISTORY promoted.
+- `uv run pytest` 261 passed; ruff clean.
+- Close: commit + PR; PyPI release via `release` from `main` after merge
+  (see `release-procedure.md`).
+
+## Remaining work
+
+- None for the code issue. Post-merge: `iflow cleanup` + cut GitHub/PyPI
+  release for `0.2.2`, then re-pin cellpy.

cellpycore-0.2.2/.issueflows/04-designs-and-guides/legacy-bridge-test-id.md

@@ -0,0 +1,15 @@
+# Legacy bridge carries `test_id` (#136)
+
+**Context.** `OldCellpyCellCore` used to drop `test_id` from outbound steps /
+summary via fixed column orders + `NATIVE_ONLY_*` exceptions. That forced cellpy
+#507 to re-stamp steps so campaign summaries could window per test.
+
+**Decision.** Bridge `test_id` as an identity column on steps and summary when
+present. Window `_add_legacy_summary_cruft` by `test_id`. `merge_data` /
+`update_data` require native `config.Schema` (hard `TypeError` on `Headers*`).
+
+**Alternatives.** Opt-in flag for summary `test_id` — rejected (additive is
+enough). Full legacy-schema merge aliases — rejected (step/cycle attrs incomplete;
+cellpy uses pandas merge).
+
+**Refs.** cellpy #507 / #510 / #511; release after this → re-pin cellpy.

{cellpycore-0.2.0 → cellpycore-0.2.2}/.issueflows/04-designs-and-guides/this-project.md

@@ -79,3 +79,13 @@ uv run pre-commit install
   the public API.
 - Per-step stat column names (`<signal>_<stat>`) are a fixed engine contract,
   not schema-injected (issue #70).
+
+## Release & version bump
+
+Static version in ``pyproject.toml`` (``project.version``). Bump with::
+
+    uv version --bump patch|minor|major
+
+Cut a GitHub release from ``main`` after merge (``release`` alias / see
+``release-procedure.md``) so ``release.yml`` publishes ``cellpycore`` to PyPI.
+

{cellpycore-0.2.0 → cellpycore-0.2.2}/AGENTS.md

@@ -81,6 +81,8 @@ cellpycore/
         02-partly-solved-issues/
         03-solved-issues/
         04-designs-and-guides/
+        05-epics/
+            epicXX_plan.md
     pyproject.toml
     readme.md
     ...
@@ -117,6 +119,10 @@ When the user message is **exactly** one of these forms, or **starts with** it f
 
 | `iflow close`, `iflow-close`, `/iflow-close`, `/iflow close` | `iflow-close` |
 
+| `iflow cycle`, `iflow-cycle`, `/iflow-cycle`, `/iflow cycle` | `iflow-cycle` |
+
+| `iflow epic`, `iflow-epic`, `/iflow-epic`, `/iflow epic` | `iflow-epic` |
+
 | `iflow fix`, `iflow-fix`, `/iflow-fix`, `/iflow fix` | `iflow-fix` |
 
 | `iflow graphify`, `iflow-graphify`, `/iflow-graphify`, `/iflow graphify` | `iflow-graphify` |
@@ -167,6 +173,10 @@ Lifecycle skills include a **`### MODEL & EXECUTION DIRECTIVE`** section that te
 
 `/iflow-status` prints a **read-only** overview of where every issue stands — the local tracking state under `.issueflows/` (focus / parked / solved) plus open GitHub issues cross-referenced against it. It is off-path (never auto-dispatched) and changes nothing.
 
+`/iflow-epic <N>` plans a change **too large for one issue** as a staged epic: it drafts `.issueflows/05-epics/epic<N>_plan.md` (anchored to GitHub issue `<N>`), dividing the work into sequential stages of manageable issue specs with explicit dependencies and a per-issue yolo-fitness judgment. Drafting writes nothing on GitHub; **`/iflow-epic <N> publish [stage <k>]`** creates a confirmed stage's issues behind one consolidated confirm (yolo labels per the recorded judgment, task list maintained on the anchor issue, `Published: #<M>` recorded back into the plan so re-runs are idempotent). Off-path (never auto-dispatched); epics decompose into the normal single-issue lifecycle, never around it.
+
+`/iflow-cycle <queue-spec>` processes **many issues hands-off in a row** under a single up-front confirmation — the batch equivalent of `/iflow-yolo`. It resolves a queue via `issue-flow agent queue` (explicit numbers, `label:<L>`, or `epic <N> [stage <k>]`), then runs each issue through the full yolo chain (PR auto-merged), interrupting you only when input is **strictly necessary** (unfixable failure, refused merge / non-fast-forward pull, ambiguous or not-actually-small spec, or anything outside the confirmed queue). It stops the whole cycle on the first such condition, leaving the repo clean on the default branch. Off-path (never auto-dispatched); never weakens a yolo safeguard to keep moving.
+
 `/iflow-archive` condenses old solved issue groups under `.issueflows/03-solved-issues/` into a single dated `YYYY-MM-DD_archived_issues.md` summary file (recording the pre-archive git ref for recovery via `git show <ref>:<path>`), then deletes the original `issue<N>_*` files. It is off-path and destructive: nothing is deleted before one consolidated confirmation.
 
 > On tools without project slash commands (e.g. Codex CLI), invoke the mirrored Agent Skills instead (for example `iflow-init` in place of `/iflow-init`).