@lifeaitools/rdc-skills 0.25.4 → 0.25.9

package/commands/fixit.md

@@ -1,150 +1,150 @@
----
-name: rdc:fixit
-description: >-
-  Usage `rdc:fixit <description>` — sanctioned bypass for quick fixes under 5 files / 30 min. Creates minimal work item, makes fix, commits, DELIVERS it to where it is consumed (publish/deploy/land) and verifies, then closes. The ONLY alternative to rdc:build. For typos, config patches, hotfixes, dep bumps.
----
-
-> **⚠️ OUTPUT CONTRACT (READ FIRST):** `guides/output-contract.md`
-> Checklist-only output. No tool-call narration. No raw MCP/JSON/log dumps.
-> One checklist upfront, updated in place, shown again at end with a 1-line verdict.
-
-> If dispatching subagents or running as a subagent: read `{PROJECT_ROOT}/.rdc/guides/agent-bootstrap.md` first (fallback: `{PROJECT_ROOT}/.rdc/guides/agent-bootstrap.md`).
-
-> **Sandbox contract:** This skill honors `RDC_TEST=1` per `guides/agent-bootstrap.md` § RDC_TEST Sandbox Contract. Destructive external calls short-circuit under the flag.
-
-
-# rdc:fixit — Sanctioned Quick Fix
-
-## When to Use
-- Typo or single-line text correction
-- Config value change (env vars, constants, feature flags)
-- Emergency hotfix that cannot wait for a full build cycle
-- Dependency version bump
-- CSS/styling tweak on a single component
-- Broken import or export fix
-- Single-file logic correction
-
-## When NOT to Use — escalate to rdc:build instead
-- New feature of any size
-- Refactor touching >5 files
-- Anything requiring architecture decisions
-- Work that will take longer than 30 minutes
-- Schema changes or migrations
-
-## Arguments
-- `rdc:fixit <description>` — fix the described issue
-
-## Procedure
-
-### 1. Scope check (mandatory — do this before touching any file)
-
-Will this fix touch more than **5 files** or take more than **30 minutes**?
-
-- **YES** → Stop. Use `/rdc:build` instead. Explain to the user why.
-- **NO** → Continue.
-
-### 2. Create a minimal work item (before touching any code)
-
-```sql
-SELECT insert_work_item(
-  p_title     := 'fixit: <description>',
-  p_item_type := 'bug',
-  p_priority  := 'urgent',
-  p_status    := 'in_progress',
-  p_source    := 'fixit'
-);
-```
-
-Note the returned `id`.
-
-### 3. Write the fixit session marker
-
-Write to `{USER_HOME}/.claude/fixit.marker`:
-```
-<work_item_id>
-<ISO timestamp>
-<description>
-```
-
-This signals the Stop hook that fixit is handling its own documentation.
-
-### 4. Make the fix
-
-Do the minimal work. Scope creep rule: if you discover the fix requires more than originally scoped, **stop immediately**:
-1. Close the work item: `update_work_item_status('<id>', 'blocked', '["Escalated — scope exceeded fixit threshold"]')`
-2. Delete the marker file
-3. Tell the user to use `/rdc:build` instead
-
-### 5. Commit
-
-```bash
-git add <specific files only — never git add -A for a fixit>
-git commit -m "fix(<scope>): <description>"
-if [ "$RDC_TEST" != "1" ]; then
-  git push origin {development-branch}
-else
-  echo "[RDC_TEST] skipping git push origin {development-branch}"
-fi
-```
-
-### 5.5 Deliver to done (MANDATORY — a fixit is not done until the change is LIVE)
-
-⛔ **"Committed and pushed" is NOT done.** Editing code and walking away is the exact
-failure this step exists to prevent. Carry the change to where it is consumed and verify it:
-
-| Target shape | "Done" = delivered means | How + structural proof |
-|---|---|---|
-| Published package (npm / PyPI) | new version live on the registry | `npm publish --access public` (or repo release path); verify `npm view <pkg> version` == new version |
-| Deployed app (`apps/*`, sites) | change live on the running host | `/rdc:deploy <slug>` (dev) / `promote` (prod); verify HTTP 200 + content probe |
-| Shared lib consumed in-repo | landed on the integration branch | `node scripts/land.mjs`; verify branch contains the SHA |
-| Standalone repo | its own release ritual completed | repo release script/tag; verify the artifact/tag exists |
-| Pure doc / internal-only change, NO consumer | committed + landed | no deploy; the ONLY case where commit == done |
-
-- **A version bump obligates a release.** A bumped-but-unshipped version is an unfinished fixit.
-- **Verify structurally** (registry version, HTTP status, tag presence), never by assumption.
-- **If delivery can't complete in-session** (missing OTP/secret, human approval, denied
-  command, manual prod promotion): set the work item `blocked` with the exact remaining
-  command + reason and tell the user the one step to run — do NOT mark `done`.
-
-Under `RDC_TEST=1`: echo `[RDC_TEST] skipping delivery (publish/deploy)` and proceed.
-
-### 6. Report, review, close, and clean up
-
-**Precondition: Step 5.5 delivery is verified.** If delivery is blocked, set `blocked` (not
-`done`) with the remaining step — never mark an undelivered change `done`.
-
-```sql
-SELECT submit_implementation_report('<id>'::uuid,
-  '{"tldr":"<one sentence>","assumptions":[],"deviations":[],"uncertainty":[],"detail":"<what was fixed>","flags":[],"transactional":false,"memory_records":[],"codeflow_post":{"agent_session_id":"<agent-session-id>","summary":"<what changed and why>","files_changed":["<path>"],"verification":["<command/evidence>"],"commit":"<hash optional>"}}'::jsonb
-);
-
-SELECT update_work_item_status('<id>'::uuid, 'review',
-  '["Fixed via rdc:fixit; ready for validation"]'::jsonb,
-  '<agent-session-id>',
-  'agent'
-);
-
-SELECT update_work_item_status('<id>'::uuid, 'done',
-  '["Validator verified rdc:fixit report, CodeFlow post, and checklist evidence"]'::jsonb,
-  '<validator-session-id>',
-  'validator'
-);
-```
-
-```bash
-rm {USER_HOME}/.claude/fixit.marker
-```
-
-### 7. Confirm to user
-
-Report: what was fixed, file(s) changed, commit hash. One sentence.
-
-## Rules
-- Work item created BEFORE any code change — never after
-- `git add` specific files only — never `-A` or `.` for a fixit
-- Branch: development branch always
-- Never run `pnpm build` — not needed for a fixit
-- If scope expands mid-fix: stop, escalate to rdc:build, don't finish under fixit
-- Marker file must be cleaned up whether fix succeeds or escalates
-- **Done = delivered, not committed.** Live where consumed (published/deployed/landed) +
-  verified. A version bump obligates a publish. Can't deliver in-session → `blocked`, never `done`.
+---
+name: rdc:fixit
+description: >-
+  Usage `rdc:fixit <description>` — sanctioned bypass for quick fixes under 5 files / 30 min. Creates minimal work item, makes fix, commits, DELIVERS it to where it is consumed (publish/deploy/land) and verifies, then closes. The ONLY alternative to rdc:build. For typos, config patches, hotfixes, dep bumps.
+---
+
+> **⚠️ OUTPUT CONTRACT (READ FIRST):** `guides/output-contract.md`
+> Checklist-only output. No tool-call narration. No raw MCP/JSON/log dumps.
+> One checklist upfront, updated in place, shown again at end with a 1-line verdict.
+
+> If dispatching subagents or running as a subagent: read `{PROJECT_ROOT}/.rdc/guides/agent-bootstrap.md` first (fallback: `{PROJECT_ROOT}/.rdc/guides/agent-bootstrap.md`).
+
+> **Sandbox contract:** This skill honors `RDC_TEST=1` per `guides/agent-bootstrap.md` § RDC_TEST Sandbox Contract. Destructive external calls short-circuit under the flag.
+
+
+# rdc:fixit — Sanctioned Quick Fix
+
+## When to Use
+- Typo or single-line text correction
+- Config value change (env vars, constants, feature flags)
+- Emergency hotfix that cannot wait for a full build cycle
+- Dependency version bump
+- CSS/styling tweak on a single component
+- Broken import or export fix
+- Single-file logic correction
+
+## When NOT to Use — escalate to rdc:build instead
+- New feature of any size
+- Refactor touching >5 files
+- Anything requiring architecture decisions
+- Work that will take longer than 30 minutes
+- Schema changes or migrations
+
+## Arguments
+- `rdc:fixit <description>` — fix the described issue
+
+## Procedure
+
+### 1. Scope check (mandatory — do this before touching any file)
+
+Will this fix touch more than **5 files** or take more than **30 minutes**?
+
+- **YES** → Stop. Use `/rdc:build` instead. Explain to the user why.
+- **NO** → Continue.
+
+### 2. Create a minimal work item (before touching any code)
+
+```sql
+SELECT insert_work_item(
+  p_title     := 'fixit: <description>',
+  p_item_type := 'bug',
+  p_priority  := 'urgent',
+  p_status    := 'in_progress',
+  p_source    := 'fixit'
+);
+```
+
+Note the returned `id`.
+
+### 3. Write the fixit session marker
+
+Write to `{USER_HOME}/.claude/fixit.marker`:
+```
+<work_item_id>
+<ISO timestamp>
+<description>
+```
+
+This signals the Stop hook that fixit is handling its own documentation.
+
+### 4. Make the fix
+
+Do the minimal work. Scope creep rule: if you discover the fix requires more than originally scoped, **stop immediately**:
+1. Close the work item: `update_work_item_status('<id>', 'blocked', '["Escalated — scope exceeded fixit threshold"]')`
+2. Delete the marker file
+3. Tell the user to use `/rdc:build` instead
+
+### 5. Commit
+
+```bash
+git add <specific files only — never git add -A for a fixit>
+git commit -m "fix(<scope>): <description>"
+if [ "$RDC_TEST" != "1" ]; then
+  git push origin {development-branch}
+else
+  echo "[RDC_TEST] skipping git push origin {development-branch}"
+fi
+```
+
+### 5.5 Deliver to done (MANDATORY — a fixit is not done until the change is LIVE)
+
+⛔ **"Committed and pushed" is NOT done.** Editing code and walking away is the exact
+failure this step exists to prevent. Carry the change to where it is consumed and verify it:
+
+| Target shape | "Done" = delivered means | How + structural proof |
+|---|---|---|
+| Published package (npm / PyPI) | new version live on the registry | `npm publish --access public` (or repo release path); verify `npm view <pkg> version` == new version |
+| Deployed app (`apps/*`, sites) | change live on the running host | `/rdc:deploy <slug>` (dev) / `promote` (prod); verify HTTP 200 + content probe |
+| Shared lib consumed in-repo | landed on the integration branch | `node scripts/land.mjs`; verify branch contains the SHA |
+| Standalone repo | its own release ritual completed | repo release script/tag; verify the artifact/tag exists |
+| Pure doc / internal-only change, NO consumer | committed + landed | no deploy; the ONLY case where commit == done |
+
+- **A version bump obligates a release.** A bumped-but-unshipped version is an unfinished fixit.
+- **Verify structurally** (registry version, HTTP status, tag presence), never by assumption.
+- **If delivery can't complete in-session** (missing OTP/secret, human approval, denied
+  command, manual prod promotion): set the work item `blocked` with the exact remaining
+  command + reason and tell the user the one step to run — do NOT mark `done`.
+
+Under `RDC_TEST=1`: echo `[RDC_TEST] skipping delivery (publish/deploy)` and proceed.
+
+### 6. Report, review, close, and clean up
+
+**Precondition: Step 5.5 delivery is verified.** If delivery is blocked, set `blocked` (not
+`done`) with the remaining step — never mark an undelivered change `done`.
+
+```sql
+SELECT submit_implementation_report('<id>'::uuid,
+  '{"tldr":"<one sentence>","assumptions":[],"deviations":[],"uncertainty":[],"detail":"<what was fixed>","flags":[],"transactional":false,"memory_records":[],"codeflow_post":{"agent_session_id":"<agent-session-id>","summary":"<what changed and why>","files_changed":["<path>"],"verification":["<command/evidence>"],"commit":"<hash optional>"}}'::jsonb
+);
+
+SELECT update_work_item_status('<id>'::uuid, 'review',
+  '["Fixed via rdc:fixit; ready for validation"]'::jsonb,
+  '<agent-session-id>',
+  'agent'
+);
+
+SELECT update_work_item_status('<id>'::uuid, 'done',
+  '["Validator verified rdc:fixit report, CodeFlow post, and checklist evidence"]'::jsonb,
+  '<validator-session-id>',
+  'validator'
+);
+```
+
+```bash
+rm {USER_HOME}/.claude/fixit.marker
+```
+
+### 7. Confirm to user
+
+Report: what was fixed, file(s) changed, commit hash. One sentence.
+
+## Rules
+- Work item created BEFORE any code change — never after
+- `git add` specific files only — never `-A` or `.` for a fixit
+- Branch: development branch always
+- Never run `pnpm build` — not needed for a fixit
+- If scope expands mid-fix: stop, escalate to rdc:build, don't finish under fixit
+- Marker file must be cleaned up whether fix succeeds or escalates
+- **Done = delivered, not committed.** Live where consumed (published/deployed/landed) +
+  verified. A version bump obligates a publish. Can't deliver in-session → `blocked`, never `done`.

package/commands/handoff.md

@@ -1,173 +1,173 @@
----
-name: rdc:handoff
-description: >-
-  Usage `rdc:handoff <topic>` — structured handoff from planning session to CLI agents. Produces plan doc in .rdc/plans/, work items in DB, prototype registry entry if applicable. Use when plan/prototype is finalized and ready for implementation.
----
-
-> **⚠️ OUTPUT CONTRACT (READ FIRST):** `guides/output-contract.md`
-> Checklist-only output. No tool-call narration. No raw MCP/JSON/log dumps.
-> One checklist upfront, updated in place, shown again at end with a 1-line verdict.
-
-> If dispatching subagents or running as a subagent: read `{PROJECT_ROOT}/.rdc/guides/agent-bootstrap.md` first (fallback: `{PROJECT_ROOT}/.rdc/guides/agent-bootstrap.md`).
-
-
-# rdc:handoff — Planning → CLI Bridge
-
-## When to Use
-
-- A prototype has been built and needs production implementation
-- A design decision has been made and needs to be executed
-- Project lead says "hand this off", "give this to the CLI", "write it up"
-- A plan exists in the conversation but hasn't been saved to disk or database yet
-
-## What This Skill Produces
-
-1. **Plan doc** → `.rdc/plans/<topic-slug>.md` (fallback: `.rdc/plans/<topic-slug>.md`)
-2. **Database epic + child tasks** (with agent types and guide file refs)
-3. **Prototype registry entry** (if a prototype was built)
-4. **Design context entries** (for decisions made in the session)
-
-## Procedure
-
-### Step 1 — Extract the Plan
-
-Identify from the conversation:
-- What is the goal?
-- What prototypes or designs were built? Where are they?
-- What decisions were made? What was rejected and why?
-- What is the sequencing (what depends on what)?
-- Which agent types are needed?
-
-### Step 2 — Write the Plan Doc
-
-```
-.rdc/plans/<topic-slug>.md
-```
-(fallback: `.rdc/plans/<topic-slug>.md` if `.rdc/` does not exist)
-
-Template:
-```markdown
-# Plan: <Topic>
-> Route: <app route or package>
-> Status: Ready for CLI build
-> Created: <date>
-> Source: planning session
-
----
-
-## What Already Exists (Do NOT Re-implement)
-
-[List any existing components, database tables, or files
- that agents must use rather than recreate]
-
-## What Was Built in Planning (Prototype)
-
-[Describe the prototype — file location, key design decisions,
- what to preserve vs what to adapt]
-
-## Work Packages
-
-### Package 1 — <Name>
-- Agent type: frontend | backend | data | design | infra | content | cs2 | viz
-- Guide: .rdc/guides/<type>.md (fallback: .rdc/guides/<type>.md)
-- Files to create/modify: [list]
-- Deliverables: [specific outputs]
-- Depends on: [other packages if sequential]
-
-### Package 2 — <Name>
-[...]
-
-## Sequencing
-
-Wave 1 (parallel): Package 1, Package 2
-Wave 2 (after Wave 1): Package 3
-
-## Definition of Done
-
-- [ ] [specific acceptance criterion]
-- [ ] [build verification: zero new TS errors]
-- [ ] [functional test]
-```
-
-### Step 3 — Create Database Epic + Tasks
-
-```sql
--- Check for existing epics first
-SELECT get_open_epics();
-
--- Create epic
-SELECT insert_work_item(
-  p_title       := 'EPIC: <Topic>',
-  p_description := 'See .rdc/plans/<topic-slug>.md for full spec.',
-  p_item_type   := 'epic',
-  p_priority    := 'high',
-  p_labels      := ARRAY['<system-label>'],
-  p_source      := 'planning'
-);
-
--- Create tasks (one per work package)
-SELECT insert_work_item(
-  p_title       := '<Package Name>',
-  p_description := 'What: <deliverable>
-Where: <files>
-Agent type: <type>
-Guide: .rdc/guides/<type>.md (fallback: .rdc/guides/<type>.md)
-Design doc: .rdc/plans/<topic-slug>.md (fallback: .rdc/plans/<topic-slug>.md)
-Depends on: <other task if applicable>
-Est: <hours>',
-  p_parent_id   := '<epic-uuid>'::uuid,
-  p_item_type   := 'task',
-  p_priority    := 'high',
-  p_labels      := ARRAY['<label>'],
-  p_estimated_hours := 2,
-  p_source      := 'planning'
-);
-```
-
-### Step 4 — Register Prototype (if one was built)
-
-```sql
-INSERT INTO prototype_registry (name, component, source_path, notes, created_by)
-VALUES (
-  '<Component Name> v1',
-  '<ComponentName>',
-  'docs/source/<filename>.jsx',
-  '<Key design decisions, data shapes, what to preserve>',
-  'planning'
-)
-ON CONFLICT DO NOTHING;
-```
-
-### Step 5 — Record Design Decisions
-
-```sql
-INSERT INTO design_context (topic, context_type, summary, source, created_by)
-VALUES
-  ('<Topic>', 'decision', '<What was decided and why>', 'planning session', 'planning'),
-  ('<Topic>', 'rejected', '<What was considered but not chosen, and why>', 'planning session', 'planning');
-```
-
-## System Labels Reference
-
-| Label | When |
-|-------|------|
-| `project-a` | Your-app-specific label |
-| `marketing` | Marketing / outreach work |
-| `ui` | Component library work |
-| `data` | Schema, migrations |
-| `infrastructure` | CI/CD, deployment |
-| `cs2` | Core paradigm packages |
-| `website` | Public-facing sites |
-| `media` | Media/asset work |
-
-## Output
-
-When complete, tell the project lead:
-```
-Handoff complete:
-- Plan: .rdc/plans/<topic-slug>.md
-- Epic: <epic-id> ("<title>")
-- Tasks: <N> tasks created, wave structure: [Wave 1: X, Y | Wave 2: Z]
-- Prototype: registered at docs/source/<file> (if applicable)
-- CLI agents will pick this up on next run.
-```
+---
+name: rdc:handoff
+description: >-
+  Usage `rdc:handoff <topic>` — structured handoff from planning session to CLI agents. Produces plan doc in .rdc/plans/, work items in DB, prototype registry entry if applicable. Use when plan/prototype is finalized and ready for implementation.
+---
+
+> **⚠️ OUTPUT CONTRACT (READ FIRST):** `guides/output-contract.md`
+> Checklist-only output. No tool-call narration. No raw MCP/JSON/log dumps.
+> One checklist upfront, updated in place, shown again at end with a 1-line verdict.
+
+> If dispatching subagents or running as a subagent: read `{PROJECT_ROOT}/.rdc/guides/agent-bootstrap.md` first (fallback: `{PROJECT_ROOT}/.rdc/guides/agent-bootstrap.md`).
+
+
+# rdc:handoff — Planning → CLI Bridge
+
+## When to Use
+
+- A prototype has been built and needs production implementation
+- A design decision has been made and needs to be executed
+- Project lead says "hand this off", "give this to the CLI", "write it up"
+- A plan exists in the conversation but hasn't been saved to disk or database yet
+
+## What This Skill Produces
+
+1. **Plan doc** → `.rdc/plans/<topic-slug>.md` (fallback: `.rdc/plans/<topic-slug>.md`)
+2. **Database epic + child tasks** (with agent types and guide file refs)
+3. **Prototype registry entry** (if a prototype was built)
+4. **Design context entries** (for decisions made in the session)
+
+## Procedure
+
+### Step 1 — Extract the Plan
+
+Identify from the conversation:
+- What is the goal?
+- What prototypes or designs were built? Where are they?
+- What decisions were made? What was rejected and why?
+- What is the sequencing (what depends on what)?
+- Which agent types are needed?
+
+### Step 2 — Write the Plan Doc
+
+```
+.rdc/plans/<topic-slug>.md
+```
+(fallback: `.rdc/plans/<topic-slug>.md` if `.rdc/` does not exist)
+
+Template:
+```markdown
+# Plan: <Topic>
+> Route: <app route or package>
+> Status: Ready for CLI build
+> Created: <date>
+> Source: planning session
+
+---
+
+## What Already Exists (Do NOT Re-implement)
+
+[List any existing components, database tables, or files
+ that agents must use rather than recreate]
+
+## What Was Built in Planning (Prototype)
+
+[Describe the prototype — file location, key design decisions,
+ what to preserve vs what to adapt]
+
+## Work Packages
+
+### Package 1 — <Name>
+- Agent type: frontend | backend | data | design | infra | content | cs2 | viz
+- Guide: .rdc/guides/<type>.md (fallback: .rdc/guides/<type>.md)
+- Files to create/modify: [list]
+- Deliverables: [specific outputs]
+- Depends on: [other packages if sequential]
+
+### Package 2 — <Name>
+[...]
+
+## Sequencing
+
+Wave 1 (parallel): Package 1, Package 2
+Wave 2 (after Wave 1): Package 3
+
+## Definition of Done
+
+- [ ] [specific acceptance criterion]
+- [ ] [build verification: zero new TS errors]
+- [ ] [functional test]
+```
+
+### Step 3 — Create Database Epic + Tasks
+
+```sql
+-- Check for existing epics first
+SELECT get_open_epics();
+
+-- Create epic
+SELECT insert_work_item(
+  p_title       := 'EPIC: <Topic>',
+  p_description := 'See .rdc/plans/<topic-slug>.md for full spec.',
+  p_item_type   := 'epic',
+  p_priority    := 'high',
+  p_labels      := ARRAY['<system-label>'],
+  p_source      := 'planning'
+);
+
+-- Create tasks (one per work package)
+SELECT insert_work_item(
+  p_title       := '<Package Name>',
+  p_description := 'What: <deliverable>
+Where: <files>
+Agent type: <type>
+Guide: .rdc/guides/<type>.md (fallback: .rdc/guides/<type>.md)
+Design doc: .rdc/plans/<topic-slug>.md (fallback: .rdc/plans/<topic-slug>.md)
+Depends on: <other task if applicable>
+Est: <hours>',
+  p_parent_id   := '<epic-uuid>'::uuid,
+  p_item_type   := 'task',
+  p_priority    := 'high',
+  p_labels      := ARRAY['<label>'],
+  p_estimated_hours := 2,
+  p_source      := 'planning'
+);
+```
+
+### Step 4 — Register Prototype (if one was built)
+
+```sql
+INSERT INTO prototype_registry (name, component, source_path, notes, created_by)
+VALUES (
+  '<Component Name> v1',
+  '<ComponentName>',
+  'docs/source/<filename>.jsx',
+  '<Key design decisions, data shapes, what to preserve>',
+  'planning'
+)
+ON CONFLICT DO NOTHING;
+```
+
+### Step 5 — Record Design Decisions
+
+```sql
+INSERT INTO design_context (topic, context_type, summary, source, created_by)
+VALUES
+  ('<Topic>', 'decision', '<What was decided and why>', 'planning session', 'planning'),
+  ('<Topic>', 'rejected', '<What was considered but not chosen, and why>', 'planning session', 'planning');
+```
+
+## System Labels Reference
+
+| Label | When |
+|-------|------|
+| `project-a` | Your-app-specific label |
+| `marketing` | Marketing / outreach work |
+| `ui` | Component library work |
+| `data` | Schema, migrations |
+| `infrastructure` | CI/CD, deployment |
+| `cs2` | Core paradigm packages |
+| `website` | Public-facing sites |
+| `media` | Media/asset work |
+
+## Output
+
+When complete, tell the project lead:
+```
+Handoff complete:
+- Plan: .rdc/plans/<topic-slug>.md
+- Epic: <epic-id> ("<title>")
+- Tasks: <N> tasks created, wave structure: [Wave 1: X, Y | Wave 2: Z]
+- Prototype: registered at docs/source/<file> (if applicable)
+- CLI agents will pick this up on next run.
+```