create-issflow 1.0.3 → 1.2.0

package/template/.claude/commands/replan.md

@@ -1,63 +1,68 @@
----
-description: Revise docs/PLAN.md when it no longer matches reality — add, cut, split, merge, or reorder phases.
-argument-hint: [what changed about the plan]
----
-
-Caveman ULTRA mode.
-
-Recommended: run from plan mode (Shift+Tab). Optional; the command stops for
-your approval regardless.
-
-Use when PLAN.md no longer matches reality. Change: $ARGUMENTS
-
----
-
-## Steps
-
-1. PRE-FLIGHT. Read docs/STATE.md and docs/PLAN.md.
-   - Phase in progress -> tell me which. Ask: revise around it, or is it the
-     thing being changed? Do not silently rewrite a mid-execution phase.
-   - Done phases are FROZEN. /replan never edits or reorders done phases.
-   - Phase 0 (infra), if present, is frozen once done.
-
-2. DESIGN RESEARCH CHECK. Scan $ARGUMENTS for signals that design research
-   is warranted before re-planning:
-   - The change involves architecture (a new integration pattern, auth change, etc.)
-   - A service tier or quota change is implied
-
-   If ANY of these signals are present: dispatch `researcher` in DESIGN mode
-   with the specific new service/pattern as the DESIGN TOPICS list. Show me the
-   key findings before proceeding to step 3.
-
-   If none: proceed directly to step 3 (impl-research may still be dispatched
-   in step 3 for non-trivial changes per the original logic).
-
-3. IMPL RESEARCH if needed. If the change is non-trivial but design research
-   was not needed, dispatch `researcher` in IMPL mode to ground the re-plan
-   in facts.
-
-4. RE-PLAN. Dispatch `planner` with the change + current PLAN.md. It must:
-   - Keep done phases untouched.
-   - Insert / cut / split / merge / reorder only PENDING phases.
-   - Place new phases in correct DEPENDENCY order.
-   - Keep every phase a vertical slice with its own acceptance spec.
-   - Ensure the LAST pending phase still contains the deploy task block.
-   - Renumber pending phases if needed; update STATE.md `phase:` pointer.
-
-5. RECONCILE THE REGRESSION CORPUS (scoped to `tests/regression/`):
-   - A CUT phase -> retire its regression tests.
-   - A MERGE -> consolidate the merged phases' regression tests.
-   - A REORDER -> keep the tests as-is (contracts are phase-independent).
-   Do NOT touch phase-local `tests/phase-<n>/` here beyond renumbering dirs.
-   After reconciling, run `scripts/regression.sh --real` to confirm the
-   reconciled corpus still passes against live services. A failure -> surface it
-   and stop before approval.
-
-6. SHOW ME the revised phase list + the regression-corpus changes, and STOP for
-   approval.
-
-7. ARCHITECTURE SELF-CHECK: re-planning is not normally a kit-architecture
-   change. Only run /log-decision if the workflow itself changed (rare).
-
-Report what changed: phases added / cut / split / reordered, and regression
-tests retired / consolidated.
+---
+description: Revise docs/PLAN.md when it no longer matches reality — add, cut, split, merge, or reorder phases.
+argument-hint: [what changed about the plan]
+---
+
+Caveman ULTRA mode.
+
+Recommended: run from plan mode (Shift+Tab). Optional; the command stops for
+your approval regardless.
+
+Use when PLAN.md no longer matches reality. Change: $ARGUMENTS
+
+NOTE: if the change alters SCOPE after a proposal is approved (cost/timeline impact),
+run `/change-request` instead — it does the impact analysis + re-estimate + change
+order, then calls this command. `/replan` is for plan-shape changes with no
+commercial impact (split/merge/reorder, a discovered technical re-slice).
+
+---
+
+## Steps
+
+1. PRE-FLIGHT. Read docs/STATE.md and docs/PLAN.md.
+   - Phase in progress -> tell me which. Ask: revise around it, or is it the
+     thing being changed? Do not silently rewrite a mid-execution phase.
+   - Done phases are FROZEN. /replan never edits or reorders done phases.
+   - Phase 0 (infra), if present, is frozen once done.
+
+2. DESIGN RESEARCH CHECK. Scan $ARGUMENTS for signals that design research
+   is warranted before re-planning:
+   - The change involves architecture (a new integration pattern, auth change, etc.)
+   - A service tier or quota change is implied
+
+   If ANY of these signals are present: dispatch `researcher` in DESIGN mode
+   with the specific new service/pattern as the DESIGN TOPICS list. Show me the
+   key findings before proceeding to step 3.
+
+   If none: proceed directly to step 3 (impl-research may still be dispatched
+   in step 3 for non-trivial changes per the original logic).
+
+3. IMPL RESEARCH if needed. If the change is non-trivial but design research
+   was not needed, dispatch `researcher` in IMPL mode to ground the re-plan
+   in facts.
+
+4. RE-PLAN. Dispatch `planner` with the change + current PLAN.md. It must:
+   - Keep done phases untouched.
+   - Insert / cut / split / merge / reorder only PENDING phases.
+   - Place new phases in correct DEPENDENCY order.
+   - Keep every phase a vertical slice with its own acceptance spec.
+   - Ensure the LAST pending phase still contains the deploy task block.
+   - Renumber pending phases if needed; update STATE.md `phase:` pointer.
+
+5. RECONCILE THE REGRESSION CORPUS (scoped to `tests/regression/`):
+   - A CUT phase -> retire its regression tests.
+   - A MERGE -> consolidate the merged phases' regression tests.
+   - A REORDER -> keep the tests as-is (contracts are phase-independent).
+   Do NOT touch phase-local `tests/phase-<n>/` here beyond renumbering dirs.
+   After reconciling, run `scripts/regression.sh --real` to confirm the
+   reconciled corpus still passes against live services. A failure -> surface it
+   and stop before approval.
+
+6. SHOW ME the revised phase list + the regression-corpus changes, and STOP for
+   approval.
+
+7. ARCHITECTURE SELF-CHECK: re-planning is not normally a kit-architecture
+   change. Only run /log-decision if the workflow itself changed (rare).
+
+Report what changed: phases added / cut / split / reordered, and regression
+tests retired / consolidated.

package/template/.claude/commands/security-audit.md

@@ -0,0 +1,56 @@
+---
+description: Holistic security audit — sweep the WHOLE product against the security cookbook (OWASP Top 10 / ASVS / WSTG / secrets / SCA / SAST / supply chain), score it, and produce a prioritized findings report. On-demand or before a release. NOT the per-phase gate — rule 11 checks one phase while coding; this audits the whole attack surface.
+argument-hint: [optional scope]
+---
+
+Caveman ULTRA mode. You are the ORCHESTRATOR.
+
+Purpose: a whole-product SECURITY audit — the security counterpart of `/ui-audit`
+and `/qa-audit`. The per-phase gate (rule 11) checks secrets/SCA/SAST + secure coding
+on ONE phase; this audit sweeps the ENTIRE attack surface and the product's security
+posture. Run before a release, after auth/data changes, or on request — and before
+the pre-deploy pentest, not instead of it.
+
+Security = "is it SAFE?" — a different axis from QA ("does it work?") and UI
+("does it look right?"). Passing those never implies this.
+
+## PRE-FLIGHT
+Read the rubric: `.claude/skills/security/SKILL.md` (the Secure SDLC cookbook) and
+its `references/` (OWASP Top 10 / ASVS / WSTG / ISO 27001 / SLSA). The cookbook IS the
+checklist — audit against it; don't invent criteria.
+
+## STEP 1 — INVENTORY (attack surface)
+Map it from `docs/ENDPOINTS.md` + the code: entry points (routes, inputs, file
+uploads, webhooks), trust boundaries, auth/session, data stores + PII, secrets,
+third-party deps, and outbound calls.
+
+## STEP 2 — SWEEP  (dispatch a worker to keep context lean)
+- **OWASP Top 10** — broken access control, crypto failures, injection (SQLi/XSS/
+  cmd), insecure design, misconfiguration, vulnerable components, auth failures,
+  integrity failures, logging/monitoring gaps, SSRF.
+- **AuthN / AuthZ** — every protected route enforces it; no IDOR; least privilege.
+- **Secrets** — none in code/history/config/prompts (run gitleaks/trufflehog if present).
+- **Dependencies (SCA)** — known CVEs (run `npm audit` / `pip-audit` / `osv-scanner`).
+- **SAST** — run semgrep / CodeQL if present; review hotspots otherwise.
+- **Input validation + output encoding** at every boundary; safe file handling.
+- **Crypto** — strong algorithms, no hardcoded keys, secrets at rest/in transit.
+- **Supply chain (SLSA)** — pinned deps, build integrity, no untrusted scripts.
+- **Logging / monitoring** — security events logged; no sensitive data in logs.
+- **Threat-model coverage** — were the design-stage abuse cases actually tested?
+
+## STEP 3 — SCORE + FINDINGS
+Rate each area PASS / WARN / FAIL. Per finding:
+- **severity**: CRITICAL · HIGH · MEDIUM · LOW (map to CVSS where it helps)
+- **location**: endpoint / file / dependency
+- **issue** + the OWASP/ASVS reference it breaks + **fix**
+
+## STEP 4 — REPORT
+Write `docs/security-audit-<YYYY-MM-DD>.md`: attack-surface map · per-area scoreboard ·
+findings sorted by severity · prioritized remediation. Log HIGH/CRITICAL to
+`docs/ISSUES.md`.
+**VERDICT: SHIP | FIX-FIRST** — never ship with an open HIGH or CRITICAL.
+
+## STEP 5 — REMEDIATE
+A security fix is security-sensitive (autonomy hard-stop): in AUTO, fix and re-audit
+but SURFACE the change for human sign-off before it lands. Park what's blocked +
+report. A clean `/security-audit` is a precondition for the pre-deploy pentest gate.

package/template/.claude/commands/store-wisdom.md

@@ -1,195 +1,195 @@
----
-description: Promote resolved issues and research findings from this project to the shared istartsoft-flow-kb repo. Analyzes, proposes candidates for your review, then pushes approved entries.
----
-
-Caveman ULTRA mode. You are the ORCHESTRATOR.
-
-Purpose: share what this project learned with all future projects.
-Only resolved issues and completed research qualify. Open issues do NOT.
-
----
-
-## PRE-FLIGHT
-
-1. Read `.claude/kb-config.json`.
-   - Not found -> STOP. Tell me: "KB not configured. Create `.claude/kb-config.json`
-     with `kb_path` + `kb_remote` pointing at the shared KB repo, then retry /store-wisdom."
-   - Found -> extract `kb_path` and `kb_remote`.
-
-2. Expand `kb_path` (resolve `~` to home directory).
-   Verify the path exists and is a git repo (`git -C <path> status`).
-   - Fails -> STOP. Tell me the path is broken and to fix `kb_path` in
-     `.claude/kb-config.json`.
-
----
-
-## STEP 1 — PULL LATEST KB
-
-Run: `git -C <kb_path> pull --ff-only`
-
-- Success -> continue.
-- Conflict or diverged -> STOP. Tell me:
-  "KB has a conflict. Resolve manually in <kb_path>, then retry /store-wisdom."
-- Offline (no network) -> WARN me, ask: "KB pull failed (offline?). Continue
-  with local KB copy, or abort?" Wait for answer.
-
----
-
-## STEP 2 — ANALYZE LOCAL PROJECT
-
-Scan this project for promotion candidates:
-
-### From docs/ISSUES.md — resolved issues only
-- Read all entries marked `- [x] resolved`.
-- Exclude: entries with no root cause filled in, entries without a solution.
-- For each qualifying entry, note: title, symptom, root cause, solution,
-  failed attempts.
-
-### From docs/research/ — completed research files
-- Read docs/research/INDEX.md. For each entry:
-  - Read the corresponding file.
-  - A research entry qualifies if: it documents an external service behavior,
-    API contract, SDK gotcha, architectural constraint, or cost finding that
-    would be useful in a different project.
-  - A research entry does NOT qualify if: it is a project-specific config
-    finding, a one-off trace with no generalizable conclusion, or a debug
-    trace (`debug-*.md`).
-- Note: research entries get a `created:` timestamp (today's date if not
-  already present in the file). Staleness is measured from this date.
-
-### Cross-check against KB
-- Read `<kb_path>/INDEX.md` (if it exists).
-- For each candidate: does a matching slug already exist in the KB?
-  - YES, fresh entry: skip (already in KB, not stale).
-  - YES, stale entry (marked [STALE] in the snapshot): flag as REWRITE candidate.
-  - NO: flag as NEW candidate.
-
----
-
-## STEP 3 — PROPOSE CANDIDATES
-
-Present candidates one at a time. For each:
-```
-
-[N of M] <type: NEW | REWRITE> — <slug>
-Tags: <tag1, tag2, tag3>
-Action: <“new entry” | “replaces stale entry from YYYY-MM-DD”>
-
-## Preview:
-
-## [<slug>]
-
-## created: <YYYY-MM-DD>
-tags: <tags>
-symptom/context: <…>
-root-cause / finding: <…>
-fix / recommendation: <…>
-
-[APPROVE / EDIT / SKIP]
-
-```
-- APPROVE: add to approved list.
-- EDIT: ask me for the edit, apply it, re-show, wait for APPROVE or SKIP.
-- SKIP: discard this candidate.
-
-After all candidates: show me the summary:
-```
-
-Approved: <N> entries
-Skipped: <M> entries
-Domains to write: <list>
-New domain folders to create: <list or “none”>
-Proceed? [yes / abort]
-
-```
-Wait for "yes" before writing anything.
-
----
-
-## STEP 4 — WRITE TO KB
-
-For each approved entry:
-
-1. Determine the domain file path: `<kb_path>/<domain>/<file>.md`
-   - If the directory does not exist: create it.
-   - If the file does not exist: create it with a `# <domain> — <file>` header.
-
-2. REWRITE candidates: find the existing `## [<slug>]` block in the file and
-   replace it entirely with the new entry.
-
-3. NEW candidates: append the entry to the end of the domain file.
-
-4. Update `<kb_path>/INDEX.md`:
-   - For NEW entries: append a line:
-     `YYYY-MM-DD | <domain>/<file> | <slug> | <one-sentence summary>`
-   - For REWRITE entries: update the existing line in-place (new date, same slug).
-
-5. If this is the first `/store-wisdom` run (no INDEX.md existed):
-   Also create `<kb_path>/KB_GUIDE.md` with the entry format reference:
-
-   ```markdown
-   # istartsoft-flow-kb — guide
-
-   This repo accumulates resolved issues and research findings from iStartSoftFlow projects.
-   Populated by `/store-wisdom`. Read by the iStartSoftFlow `researcher` agent at session start.
-
-   ## Entry format — issues
-   ## [slug]
-   created: YYYY-MM-DD
-   tags: tag1, tag2
-   symptom: what was observed
-   root-cause: the real underlying cause
-   fix: exact solution
-   failed-attempts: what did not work
-
-   ## Entry format — research
-   ## [slug]
-   created: YYYY-MM-DD
-   tags: tag1, tag2
-   symptom/context: what prompted the research
-   finding: what was discovered
-   recommendation: what to do
-
-   ## INDEX.md format
-   YYYY-MM-DD | domain/file | slug | one-sentence summary
-
-   ## Staleness
-   Research entries older than 6 months are flagged [STALE] at session load.
-   Stale entries are re-researched locally and rewritten via /store-wisdom.
-   Issue entries never go stale.
-```
-
------
-
-## STEP 5 — COMMIT AND PUSH
-
-Run from `<kb_path>`:
-
-```bash
-git add -A
-git commit -m "store-wisdom: <N> entries from <project-name> (<YYYY-MM-DD>)"
-git push
-```
-
-- Push success -> tell me:
-  
-  ```
-  KB updated.
-  - entries written: <N> (<list of slugs>)
-  - domains touched: <list>
-  - new domains created: <list or "none">
-  - pushed to: <kb_remote>
-  ```
-- Push fails -> tell me the push failed, show the git error.
-  The entries ARE written locally — tell me to push manually:
-  `git -C <kb_path> push`
-
------
-
-## NOTES
-
-- `/store-wisdom` never modifies docs/ISSUES.md or docs/research/ in this project.
-  It reads them; it does not change them.
-- If there are no qualifying candidates, tell me so and stop. Do not push an empty commit.
-- The KB is append-only except for REWRITE of stale research entries.
-  Issue entries are never deleted or overwritten — they are facts.
+---
+description: Promote resolved issues and research findings from this project to the shared istartsoft-flow-kb repo. Analyzes, proposes candidates for your review, then pushes approved entries.
+---
+
+Caveman ULTRA mode. You are the ORCHESTRATOR.
+
+Purpose: share what this project learned with all future projects.
+Only resolved issues and completed research qualify. Open issues do NOT.
+
+---
+
+## PRE-FLIGHT
+
+1. Read `.claude/kb-config.json`.
+   - Not found -> STOP. Tell me: "KB not configured. Create `.claude/kb-config.json`
+     with `kb_path` + `kb_remote` pointing at the shared KB repo, then retry /store-wisdom."
+   - Found -> extract `kb_path` and `kb_remote`.
+
+2. Expand `kb_path` (resolve `~` to home directory).
+   Verify the path exists and is a git repo (`git -C <path> status`).
+   - Fails -> STOP. Tell me the path is broken and to fix `kb_path` in
+     `.claude/kb-config.json`.
+
+---
+
+## STEP 1 — PULL LATEST KB
+
+Run: `git -C <kb_path> pull --ff-only`
+
+- Success -> continue.
+- Conflict or diverged -> STOP. Tell me:
+  "KB has a conflict. Resolve manually in <kb_path>, then retry /store-wisdom."
+- Offline (no network) -> WARN me, ask: "KB pull failed (offline?). Continue
+  with local KB copy, or abort?" Wait for answer.
+
+---
+
+## STEP 2 — ANALYZE LOCAL PROJECT
+
+Scan this project for promotion candidates:
+
+### From docs/ISSUES.md — resolved issues only
+- Read all entries marked `- [x] resolved`.
+- Exclude: entries with no root cause filled in, entries without a solution.
+- For each qualifying entry, note: title, symptom, root cause, solution,
+  failed attempts.
+
+### From docs/research/ — completed research files
+- Read docs/research/INDEX.md. For each entry:
+  - Read the corresponding file.
+  - A research entry qualifies if: it documents an external service behavior,
+    API contract, SDK gotcha, architectural constraint, or cost finding that
+    would be useful in a different project.
+  - A research entry does NOT qualify if: it is a project-specific config
+    finding, a one-off trace with no generalizable conclusion, or a debug
+    trace (`debug-*.md`).
+- Note: research entries get a `created:` timestamp (today's date if not
+  already present in the file). Staleness is measured from this date.
+
+### Cross-check against KB
+- Read `<kb_path>/INDEX.md` (if it exists).
+- For each candidate: does a matching slug already exist in the KB?
+  - YES, fresh entry: skip (already in KB, not stale).
+  - YES, stale entry (marked [STALE] in the snapshot): flag as REWRITE candidate.
+  - NO: flag as NEW candidate.
+
+---
+
+## STEP 3 — PROPOSE CANDIDATES
+
+Present candidates one at a time. For each:
+```
+
+[N of M] <type: NEW | REWRITE> — <slug>
+Tags: <tag1, tag2, tag3>
+Action: <“new entry” | “replaces stale entry from YYYY-MM-DD”>
+
+## Preview:
+
+## [<slug>]
+
+## created: <YYYY-MM-DD>
+tags: <tags>
+symptom/context: <…>
+root-cause / finding: <…>
+fix / recommendation: <…>
+
+[APPROVE / EDIT / SKIP]
+
+```
+- APPROVE: add to approved list.
+- EDIT: ask me for the edit, apply it, re-show, wait for APPROVE or SKIP.
+- SKIP: discard this candidate.
+
+After all candidates: show me the summary:
+```
+
+Approved: <N> entries
+Skipped: <M> entries
+Domains to write: <list>
+New domain folders to create: <list or “none”>
+Proceed? [yes / abort]
+
+```
+Wait for "yes" before writing anything.
+
+---
+
+## STEP 4 — WRITE TO KB
+
+For each approved entry:
+
+1. Determine the domain file path: `<kb_path>/<domain>/<file>.md`
+   - If the directory does not exist: create it.
+   - If the file does not exist: create it with a `# <domain> — <file>` header.
+
+2. REWRITE candidates: find the existing `## [<slug>]` block in the file and
+   replace it entirely with the new entry.
+
+3. NEW candidates: append the entry to the end of the domain file.
+
+4. Update `<kb_path>/INDEX.md`:
+   - For NEW entries: append a line:
+     `YYYY-MM-DD | <domain>/<file> | <slug> | <one-sentence summary>`
+   - For REWRITE entries: update the existing line in-place (new date, same slug).
+
+5. If this is the first `/store-wisdom` run (no INDEX.md existed):
+   Also create `<kb_path>/KB_GUIDE.md` with the entry format reference:
+
+   ```markdown
+   # istartsoft-flow-kb — guide
+
+   This repo accumulates resolved issues and research findings from iStartSoftFlow projects.
+   Populated by `/store-wisdom`. Read by the iStartSoftFlow `researcher` agent at session start.
+
+   ## Entry format — issues
+   ## [slug]
+   created: YYYY-MM-DD
+   tags: tag1, tag2
+   symptom: what was observed
+   root-cause: the real underlying cause
+   fix: exact solution
+   failed-attempts: what did not work
+
+   ## Entry format — research
+   ## [slug]
+   created: YYYY-MM-DD
+   tags: tag1, tag2
+   symptom/context: what prompted the research
+   finding: what was discovered
+   recommendation: what to do
+
+   ## INDEX.md format
+   YYYY-MM-DD | domain/file | slug | one-sentence summary
+
+   ## Staleness
+   Research entries older than 6 months are flagged [STALE] at session load.
+   Stale entries are re-researched locally and rewritten via /store-wisdom.
+   Issue entries never go stale.
+```
+
+-----
+
+## STEP 5 — COMMIT AND PUSH
+
+Run from `<kb_path>`:
+
+```bash
+git add -A
+git commit -m "store-wisdom: <N> entries from <project-name> (<YYYY-MM-DD>)"
+git push
+```
+
+- Push success -> tell me:
+  
+  ```
+  KB updated.
+  - entries written: <N> (<list of slugs>)
+  - domains touched: <list>
+  - new domains created: <list or "none">
+  - pushed to: <kb_remote>
+  ```
+- Push fails -> tell me the push failed, show the git error.
+  The entries ARE written locally — tell me to push manually:
+  `git -C <kb_path> push`
+
+-----
+
+## NOTES
+
+- `/store-wisdom` never modifies docs/ISSUES.md or docs/research/ in this project.
+  It reads them; it does not change them.
+- If there are no qualifying candidates, tell me so and stop. Do not push an empty commit.
+- The KB is append-only except for REWRITE of stale research entries.
+  Issue entries are never deleted or overwritten — they are facts.

package/template/.claude/commands/synthesize.md

@@ -1,26 +1,26 @@
----
-description: Compress handoff docs, dedup the issue log, prune snapshots. Run before /clear.
----
-
-Caveman ULTRA mode.
-
-Trigger: end of a phase, or any time STATE.md / ISSUES.md feel bloated.
-
-Dispatch the `synthesizer` subagent.
-
-For a normal phase: it rewrites STATE.md, dedups ISSUES.md, prunes snapshots,
-appends to HISTORY.md.
-
-For the FINAL phase (no further pending phases): also pass the signal
-"FINAL PHASE" so the synthesizer runs the extended pass — updating OVERVIEW.md
-and README.md to reflect the completed project state.
-
-To determine if this is the final phase: read docs/PLAN.md. If no phases remain
-with status "pending" after the current one, it is the final phase.
-
-When synthesizer returns "safe to /clear: yes", tell me:
-- before/after line counts
-- whether the final-pass ran
-- that I can now run /clear (or proceed to the endpoint summary if final phase)
-
-If it returns anything unsafe, show me what and stop.
+---
+description: Compress handoff docs, dedup the issue log, prune snapshots. Run before /clear.
+---
+
+Caveman ULTRA mode.
+
+Trigger: end of a phase, or any time STATE.md / ISSUES.md feel bloated.
+
+Dispatch the `synthesizer` subagent.
+
+For a normal phase: it rewrites STATE.md, dedups ISSUES.md, prunes snapshots,
+appends to HISTORY.md.
+
+For the FINAL phase (no further pending phases): also pass the signal
+"FINAL PHASE" so the synthesizer runs the extended pass — updating OVERVIEW.md
+and README.md to reflect the completed project state.
+
+To determine if this is the final phase: read docs/PLAN.md. If no phases remain
+with status "pending" after the current one, it is the final phase.
+
+When synthesizer returns "safe to /clear: yes", tell me:
+- before/after line counts
+- whether the final-pass ran
+- that I can now run /clear (or proceed to the endpoint summary if final phase)
+
+If it returns anything unsafe, show me what and stop.