Rename workflow steps for lexical order

.claude/commands/formspec.0.init.md

@@ -14,7 +14,7 @@ You are initializing a formal-specification-driven development project. Your job
 
 Use Glob to check if `spec/system.md` already exists in the project root.
 
-If it exists: **STOP**. Tell the user that the project is already initialized and they should use `/formspec.design.1` to add features. Do not modify anything.
+If it exists: **STOP**. Tell the user that the project is already initialized and they should use `/formspec.1.design` to add features. Do not modify anything.
 
 ### 2. Gather system description
 
@@ -52,7 +52,7 @@ Write `spec/system.md` with the following structure. Fill in the System Overview
 
 ## Feature Index
 
-*No features designed yet. Use `/formspec.design.1 <feature-name>` to add features.*
+*No features designed yet. Use `/formspec.1.design <feature-name>` to add features.*
 
 ## Changelog
 
@@ -63,7 +63,7 @@ The System Overview should be a concise but complete description — enough for
 
 ### 5. Report
 
-Tell the user what was created and suggest they proceed with `/formspec.design.1 <feature-name>` to start designing features.
+Tell the user what was created and suggest they proceed with `/formspec.1.design <feature-name>` to start designing features.
 
 ## Hook convention
 
@@ -75,7 +75,7 @@ If a hook script does not exist, the command falls back to its default behavior
 
 **Path**: `spec/hooks/run-checks`
 
-**Called by**: `/formspec.formalize`, `/formspec.verify`, `/formspec.implement`, `/formspec.check`
+**Called by**: `/formspec.2.formalize`, `/formspec.3.verify`, `/formspec.6.implement`, `/formspec.8.check`
 
 **When**: When verification needs to be performed (TLC model checking, milestone tests, consistency checks).
 
@@ -85,7 +85,7 @@ If a hook script does not exist, the command falls back to its default behavior
 
 ```json
 {
-  "command": "formspec.implement",
+  "command": "formspec.6.implement",
   "project_root": "/home/user/projects/mutex",
   "checks": [
     {

.claude/commands/formspec.1.design.md

@@ -12,7 +12,7 @@ You are creating a detailed natural-language design document for a single featur
 
 ### 1. Validate preconditions
 
-**spec/system.md must exist.** Check with Glob. If it does not exist, tell the user to run `/formspec.init.0` first and stop.
+**spec/system.md must exist.** Check with Glob. If it does not exist, tell the user to run `/formspec.0.init` first and stop.
 
 **$ARGUMENTS must provide a feature name.** If empty, ask the user for a feature name. The feature name should be a short kebab-case identifier (e.g., `user-auth`, `billing`, `rate-limiting`).
 
@@ -103,7 +103,7 @@ SC-1: [Criterion with measurable target]
 
 ## Amendments
 
-[Do NOT create this section in new design docs. It is added by `/formspec.formalize.2` when TLC counterexamples force design changes. If this section already exists in a design doc you are editing, preserve it — amendments are permanent records of corrections discovered through formal verification. Only remove an amendment if the requirement it annotates is itself removed through a larger redesign, or changed significantly enough that a plain rewrite is simpler than preserving the amendment history.]
+[Do NOT create this section in new design docs. It is added by `/formspec.2.formalize` when TLC counterexamples force design changes. If this section already exists in a design doc you are editing, preserve it — amendments are permanent records of corrections discovered through formal verification. Only remove an amendment if the requirement it annotates is itself removed through a larger redesign, or changed significantly enough that a plain rewrite is simpler than preserving the amendment history.]
 ```
 
 **Quality bar**: The design must be specific enough that a different developer could implement it without further conversation. Vague statements like "should be fast" or "handle errors gracefully" are not acceptable — quantify or describe the specific behavior.
@@ -134,4 +134,4 @@ Also update the affected feature's design doc if the impact is significant enoug
 
 ### 6. Report
 
-Summarize what was created, highlight any cross-feature impacts, and note any open questions that need resolution before formalization. Suggest proceeding with `/formspec.formalize.2` to translate the design into a TLA+ specification.
+Summarize what was created, highlight any cross-feature impacts, and note any open questions that need resolution before formalization. Suggest proceeding with `/formspec.2.formalize` to translate the design into a TLA+ specification.

.claude/commands/formspec.2.formalize.md

@@ -85,7 +85,7 @@ Every requirement from Phase 1 must appear in this table. If a requirement canno
 
 ## Phase 4 — Run TLC model checker
 
-If `spec/hooks/run-checks` exists and is executable, delegate TLC verification to it instead of running locally (see `/formspec.init` for the hook interface). Present the returned results to the developer, including any dashboard URLs, and skip to Phase 5.
+If `spec/hooks/run-checks` exists and is executable, delegate TLC verification to it instead of running locally (see `/formspec.0.init` for the hook interface). Present the returned results to the developer, including any dashboard URLs, and skip to Phase 5.
 
 If the hook does not exist or fails, run TLC locally:
 
@@ -116,7 +116,7 @@ Parse the TLC output to determine:
 
 ### All properties pass
 
-Update all statuses in `spec/formal/traceability.md` from `formalized` to `checked`. Report success with a summary of what was verified: number of properties checked, state space explored, time taken. Suggest proceeding with `/formspec.plan.4` to create an implementation plan.
+Update all statuses in `spec/formal/traceability.md` from `formalized` to `checked`. Report success with a summary of what was verified: number of properties checked, state space explored, time taken. Suggest proceeding with `/formspec.4.plan` to create an implementation plan.
 
 ### Meaning drift detected (Phase 2 issue)
 
@@ -147,7 +147,7 @@ Present to the developer:
 5. **Classification**: Whether this violates an explicit design requirement or a best-practice property that you added
 
 **Do not proceed** until the developer explicitly acknowledges and decides how to resolve. Possible resolutions:
-- Redesign the component (go back to `/formspec.design.1`)
+- Redesign the component (go back to `/formspec.1.design`)
 - Add a constraint to the design
 - Accept the risk with documented justification
 - Modify the TLA+ model if the property was too strict
@@ -182,7 +182,7 @@ Amendments are permanent — they document the design's provenance and record wh
 **Evaluating amendment volume**: Multiple amendments in a single formalization run are not necessarily a problem — they may indicate that the design was written at a high level (e.g., by an AI agent or during an early brainstorming phase) and the formalization is doing its job of tightening it. The signal to watch for is not the count but the *pattern*:
 
 - **Amendments spread across different parts of the spec** (different user stories, different components, different properties) suggest the design was broadly sketched and TLC is finding the expected gaps. This is normal and productive.
-- **Amendments concentrated around the same requirement or interaction** suggest a localized design flaw that incremental patching may not resolve. After 2-3 amendments to the same area, consider whether the component needs a broader redesign via `/formspec.design.1` rather than further patching.
+- **Amendments concentrated around the same requirement or interaction** suggest a localized design flaw that incremental patching may not resolve. After 2-3 amendments to the same area, consider whether the component needs a broader redesign via `/formspec.1.design` rather than further patching.
 
 After recording the amendment, restart from Phase 2.
 

.claude/commands/formspec.3.verify.md

@@ -16,11 +16,11 @@ Check that both files exist:
 - `spec/formal/System.tla`
 - `spec/formal/System.cfg`
 
-If either is missing, tell the user to run `/formspec.formalize.2` first and stop.
+If either is missing, tell the user to run `/formspec.2.formalize` first and stop.
 
 ### 2. Run TLC
 
-If `spec/hooks/run-checks` exists and is executable, delegate verification to it instead of running TLC locally (see `/formspec.init` for the hook interface). Build the request from `spec/formal/traceability.md` (properties and their types) and `spec/formal/System.cfg` (the TLC invocation hint). Present the returned results to the developer, including any dashboard URLs.
+If `spec/hooks/run-checks` exists and is executable, delegate verification to it instead of running TLC locally (see `/formspec.0.init` for the hook interface). Build the request from `spec/formal/traceability.md` (properties and their types) and `spec/formal/System.cfg` (the TLC invocation hint). Present the returned results to the developer, including any dashboard URLs.
 
 If the hook does not exist or fails, run TLC locally:
 
@@ -52,4 +52,4 @@ Read the TLC output (or hook response) and produce a structured report:
 
 ### 4. No modifications
 
-Do not modify `System.tla`, `System.cfg`, `traceability.md`, or any other file. This command is purely diagnostic. If violations are found, advise the user to run `/formspec.formalize.2` to address them.
+Do not modify `System.tla`, `System.cfg`, `traceability.md`, or any other file. This command is purely diagnostic. If violations are found, advise the user to run `/formspec.2.formalize` to address them.

.claude/commands/formspec.4.plan.md

@@ -14,7 +14,7 @@ You are creating an implementation plan for a single feature, bridging its forma
 
 **$ARGUMENTS must provide a feature name.** If empty, ask the user for a feature name. The feature name should be the kebab-case identifier used when the feature was designed (e.g., `user-auth`, `billing`).
 
-**Locate the feature directory**: Glob for `spec/features/*-<feature-name>/design.md`. If no match is found, tell the user to run `/formspec.design.1 <feature-name>` first and stop. If multiple matches exist (unlikely), use the most recent by date prefix.
+**Locate the feature directory**: Glob for `spec/features/*-<feature-name>/design.md`. If no match is found, tell the user to run `/formspec.1.design <feature-name>` first and stop. If multiple matches exist (unlikely), use the most recent by date prefix.
 
 Read:
 - `spec/system.md`
@@ -30,7 +30,7 @@ All of these must exist. If any are missing, tell the user which prerequisite co
 
 Check `spec/formal/traceability.md`. Every formalizable property **sourced from this feature's design doc** must have status `checked` (meaning TLC has verified it). If any such property has status `formalized`, `violated`, or `not-yet-formalized` without adequate justification:
 - Tell the user which properties are not yet verified
-- Direct them to run `/formspec.formalize.2` first
+- Direct them to run `/formspec.2.formalize` first
 - Stop
 
 ### 3. Generate the feature's plan
@@ -106,4 +106,4 @@ Before finishing, verify:
 
 ### 5. Report
 
-Summarize the plan and suggest proceeding with `/formspec.tasks.5 <feature-name>` to break it into implementable tasks.
+Summarize the plan and suggest proceeding with `/formspec.5.tasks <feature-name>` to break it into implementable tasks.

.claude/commands/formspec.5.tasks.md

@@ -14,7 +14,7 @@ You are breaking a feature's implementation plan into concrete, dependency-order
 
 **$ARGUMENTS must provide a feature name.** If empty, ask the user for a feature name. The feature name should be the kebab-case identifier used when the feature was designed (e.g., `user-auth`, `billing`).
 
-**Locate the feature directory**: Glob for `spec/features/*-<feature-name>/plan.md`. If no match is found, tell the user to run `/formspec.plan.4 <feature-name>` first and stop.
+**Locate the feature directory**: Glob for `spec/features/*-<feature-name>/plan.md`. If no match is found, tell the user to run `/formspec.4.plan <feature-name>` first and stop.
 
 Read:
 - The feature's `plan.md`
@@ -95,4 +95,4 @@ Before finishing, check:
 - The dependency graph has a valid topological ordering
 - Every milestone's tasks collectively provide the components needed to execute its verification method (e.g., a milestone that verifies crash recovery must include tasks for persistence, the coordinator, and the recovery integration test)
 
-Report any gaps found during validation. Suggest proceeding with `/formspec.implement.6 <feature-name>` to start implementing tasks.
+Report any gaps found during validation. Suggest proceeding with `/formspec.6.implement <feature-name>` to start implementing tasks.

.claude/commands/formspec.6.implement.md

@@ -15,7 +15,7 @@ You are implementing tasks from a feature's `tasks.md` with continuous verificat
 
 **$ARGUMENTS must provide at least a feature name.** It may optionally include a task ID or milestone ID (e.g., `user-auth T-03` or `user-auth M-01`). If the feature name is missing, ask the user for it.
 
-**Locate the feature directory**: Glob for `spec/features/*-<feature-name>/tasks.md`. If no match is found, tell the user to run `/formspec.tasks.5 <feature-name>` first and stop.
+**Locate the feature directory**: Glob for `spec/features/*-<feature-name>/tasks.md`. If no match is found, tell the user to run `/formspec.5.tasks <feature-name>` first and stop.
 
 Read:
 - The feature's `tasks.md`
@@ -30,7 +30,7 @@ If $ARGUMENTS includes a task ID (e.g., `T-03`) or milestone ID (e.g., `M-01`):
 
 If no task ID is specified: find the next task in this feature's `tasks.md` whose dependencies are all complete. If multiple tasks are ready, pick the lowest-numbered one.
 
-If all tasks are complete, report that and suggest running `/formspec.docs.7` to generate documentation, then `/formspec.check.8` to validate consistency.
+If all tasks are complete, report that and suggest running `/formspec.7.docs` to generate documentation, then `/formspec.8.check` to validate consistency.
 
 ### 3. Implement the task
 
@@ -81,7 +81,7 @@ Stop regardless of the developer's preference when:
 
 After completing a task, check whether any verification milestones in the feature's `tasks.md` have all their tasks complete. For each newly-completed milestone:
 
-**a. Run the milestone's verification**: If `spec/hooks/run-checks` exists and is executable, delegate the milestone's verification to it (see `/formspec.init` for the hook interface). The request should include the milestone's properties, verification methods, and hints (e.g., the test commands from the plan). The external system runs the checks independently and returns results.
+**a. Run the milestone's verification**: If `spec/hooks/run-checks` exists and is executable, delegate the milestone's verification to it (see `/formspec.0.init` for the hook interface). The request should include the milestone's properties, verification methods, and hints (e.g., the test commands from the plan). The external system runs the checks independently and returns results.
 
 If the hook does not exist or fails, run the milestone's verification method locally (e.g., integration tests, property-based tests, recovery tests). These are the tests that validate TLA+ properties end-to-end across multiple components.
 
@@ -101,4 +101,4 @@ Update existing rows or add new ones. Set status to PASS with today's date. Only
 
 ### 5. Cross-check (periodic)
 
-After completing a milestone, briefly check whether the changes could have affected any previously verified properties. If there's a risk of regression, advise running `/formspec.check.8` or `/formspec.verify.3`.
+After completing a milestone, briefly check whether the changes could have affected any previously verified properties. If there's a risk of regression, advise running `/formspec.8.check` or `/formspec.3.verify`.

.claude/commands/formspec.7.docs.md

@@ -18,7 +18,7 @@ Read:
 - `spec/formal/traceability.md`
 - Existing documentation in the project root and `docs/` directory (Glob for `*.md`, `docs/**/*.md`, excluding `spec/`)
 
-All spec artifacts must exist. If `spec/system.md` or feature design docs are missing, direct the user to the prerequisite commands (`/formspec.init.0`, `/formspec.design.1`) and stop.
+All spec artifacts must exist. If `spec/system.md` or feature design docs are missing, direct the user to the prerequisite commands (`/formspec.0.init`, `/formspec.1.design`) and stop.
 
 ### 2. Determine documentation scope
 
@@ -50,7 +50,7 @@ Create or update documentation files. The exact structure depends on the project
 
 ### 4. Add spec traceability
 
-Documentation should link back to design documents where it describes feature behavior. Use inline references so that readers (and `/formspec.check.8`) can trace documentation claims to their source:
+Documentation should link back to design documents where it describes feature behavior. Use inline references so that readers (and `/formspec.8.check`) can trace documentation claims to their source:
 
 ```markdown
 <!-- spec: features/2026-02-10-user-auth/design.md#US-1 -->
@@ -74,4 +74,4 @@ Flag any discrepancies found.
 
 ### 6. Report
 
-Summarize what documentation was created or updated, which design documents it traces to, and any gaps where documentation could not be generated (e.g., design doc lacks enough detail for user-facing docs). Suggest running `/formspec.check.8` to validate full cross-artifact consistency.
+Summarize what documentation was created or updated, which design documents it traces to, and any gaps where documentation could not be generated (e.g., design doc lacks enough detail for user-facing docs). Suggest running `/formspec.8.check` to validate full cross-artifact consistency.

.claude/commands/formspec.8.check.md

@@ -86,7 +86,7 @@ Perform each of these checks and record findings:
 
 ### 3. Run verification
 
-If `spec/hooks/run-checks` exists and is executable, delegate all verification (TLC and language-specific tools) to it (see `/formspec.init` for the hook interface). Build the request from `spec/formal/traceability.md` (TLA+ properties), feature plans (verification methods), and detected source files (language-specific checks). The external system runs all checks independently and returns results.
+If `spec/hooks/run-checks` exists and is executable, delegate all verification (TLC and language-specific tools) to it (see `/formspec.0.init` for the hook interface). Build the request from `spec/formal/traceability.md` (TLA+ properties), feature plans (verification methods), and detected source files (language-specific checks). The external system runs all checks independently and returns results.
 
 If the hook does not exist or fails, run checks locally: