@urielsh/prodify 0.1.0

package/.prodify/artifacts/orientation_map.md

@@ -0,0 +1,32 @@
+# Orientation Map
+
+## Project Summary
+- Project name:
+- Primary tech stack:
+- Project type:
+- Runtime environment:
+
+## Entry Points
+- 
+
+## Module Map
+- Module:
+  - Path:
+  - Role:
+  - Confidence:
+
+## Monorepo Metadata
+- Is monorepo:
+- Tooling:
+- Workspace roots:
+
+## Dependency Overview
+- Core dependency flows:
+- High-centrality modules:
+- Tight coupling areas:
+
+## Key Observations
+- 
+
+## Uncertainty
+- 

package/.prodify/artifacts/persona-removal-audit.md

@@ -0,0 +1,106 @@
+# Persona Removal Audit
+
+Date: 2026-03-29
+Task: `81-remove-persona-language`
+
+## Files Reviewed
+- `./.prodify/tasks/01-understand.md`
+- `./.prodify/tasks/02-diagnose.md`
+- `./.prodify/tasks/03-architecture.md`
+- `./.prodify/tasks/04-plan.md`
+- `./.prodify/tasks/05-refactor.md`
+- `./.prodify/tasks/06-validate.md`
+
+## Exact Persona Or Role Phrases Found
+
+### `01-understand.md`
+- `## Identity & Mandate`
+- `Role: @Repository-Explorer`
+- `Problem: Context rot and attention dilution in large codebases.`
+- `## Data Contract`
+
+### `02-diagnose.md`
+- `## Identity & Mandate`
+- `Role: @Security-Auditor`
+- `Problem: Work slop and rapid unstructured additions destroying integrity.`
+- `## Data Contract`
+
+### `03-architecture.md`
+- `## Identity & Mandate`
+- `Role: @Principal-Architect`
+- `Problem: Lack of structural intent in evolved legacy systems.`
+- `## Data Contract`
+
+### `04-plan.md`
+- `## Identity & Mandate`
+- `Role: @DevOps-Planner`
+- `Problem: Big Bang refactors that break the CI pipeline.`
+- `## Data Contract`
+
+### `05-refactor.md`
+- `## Identity & Mandate`
+- `Role: @Implementation-Specialist`
+- `Problem: Scope creep and unrelated cleanup in pull requests.`
+- `## Data Contract`
+
+### `06-validate.md`
+- `## Identity & Mandate`
+- `Role: @Quality-Gatekeeper`
+- `Problem: Refactoring drift and hidden regressions.`
+- `## Data Contract`
+
+## Exact Replacements Required
+
+Apply this structural replacement pattern to every non-compliant task:
+
+- Replace `## Identity & Mandate` with:
+  - `## Goal`
+  - `## Scope`
+- Replace `## Data Contract` with:
+  - `## Inputs`
+- Keep `## Execution Instructions`
+- Keep `## Output Specification`
+- Add:
+  - `## Failure Conditions`
+  - `## Definition of Done`
+
+Replacement guidance:
+
+- move the existing goal sentence into `## Goal`
+- convert the existing problem framing into execution-relevant scope language only where it adds operational value
+- remove role labels entirely
+- remove narrative identity framing entirely
+
+## Files Already Compliant
+- None of the current `01` through `06` task files are fully compliant yet.
+
+## Replacement Plan
+
+### `01-understand.md`
+- remove persona and role framing
+- replace with operational `Goal`, `Scope`, and `Inputs`
+
+### `02-diagnose.md`
+- remove persona and role framing
+- replace with operational `Goal`, `Scope`, and `Inputs`
+
+### `03-architecture.md`
+- remove persona and role framing
+- replace with operational `Goal`, `Scope`, and `Inputs`
+
+### `04-plan.md`
+- remove persona and role framing
+- replace with operational `Goal`, `Scope`, and `Inputs`
+
+### `05-refactor.md`
+- remove persona and role framing
+- replace with operational `Goal`, `Scope`, and `Inputs`
+
+### `06-validate.md`
+- remove persona and role framing
+- replace with operational `Goal`, `Scope`, and `Inputs`
+
+## Result
+- All persona, role, and identity-framing language has been identified.
+- A file-by-file removal plan exists.
+- No ambiguity remains about what wording must be removed.

package/.prodify/artifacts/planning-alignment-report.md

@@ -0,0 +1,189 @@
+# Planning Alignment Report
+
+Date: 2026-03-28
+Task: `41-map-phases-to-plan`
+
+## Scope
+
+This report aligns the repo-level planning tasks with the actual Prodify runtime execution system.
+
+Inputs reviewed:
+
+- `./.agent/tasks/41-map-phases-to-plan.md`
+- `./.agent/tasks/*.md`
+- `./AGENTS.md`
+- `./.prodify/artifacts/`
+- `./planning.md` (missing)
+
+## Current Planning Model
+
+The current planning model is split across two layers:
+
+1. Repo-level roadmap tasks in `./.agent/tasks/`
+2. Runtime execution rules and runtime task files in `./.prodify/`
+
+The roadmap tasks are grouped by task bands (`11-13`, `21-23`, `31-33`, `41-42`, `51-52`, `61-62`, `71-72`) and form a linear next-task chain. The runtime system is currently defined as a fixed six-task execution pipeline in `./AGENTS.md`.
+
+## Phase-To-Task Mapping
+
+| Phase Band | Planning Intent | Repo-Level Tasks | Runtime Surface Affected | Current Output |
+| --- | --- | --- | --- | --- |
+| 10 | Normalize task contracts | `11`, `12`, `13` | `./.prodify/tasks/`, `./.prodify/templates/` | audits and validation spec |
+| 20 | Define execution state and dispatch | `21`, `22`, `23` | `run_state.json`, dispatcher behavior, artifact validation | design docs |
+| 30 | Define refactor loop control | `31`, `32`, `33` | step selection, Task `05`/`06` loop, completed-step tracking | design docs |
+| 40 | Align planning to execution and decide next actions | `41`, `42` | planning source, next-step resolution | alignment and resolver design |
+| 50 | Add operator-facing command surface | `51`, `52` | CLI/status interface | not started |
+| 60 | Improve run reporting | `61`, `62` | task log and summary output | not started |
+| 70 | Validate on a real repo | `71`, `72` | end-to-end runtime behavior | not started |
+
+## Execution Model Mapping
+
+The actual runtime system is still centered on this execution pipeline from `./AGENTS.md`:
+
+`01-understand -> 02-diagnose -> 03-architecture -> 04-plan -> 05-refactor -> 06-validate`
+
+Primary runtime artifacts currently expected by that system:
+
+- `orientation_map.md`
+- `diagnostic_report.md`
+- `architecture_spec.md`
+- `refactor_plan.md`
+- `implementation_summary.md`
+- `validation_report.md`
+- `run_state.json`
+- `task_log.json`
+
+The repo-level planning phases are therefore not runtime phases themselves. They are implementation phases for building or tightening the runtime system.
+
+## Mismatches
+
+### 1. Missing Planning Source
+
+Task `41-map-phases-to-plan` declares `planning.md` as a required input, but `./planning.md` does not exist.
+
+Impact:
+
+- there is no single canonical planning document to align against
+- the effective planning model is being inferred from task files and design artifacts instead
+
+### 2. Ambiguous `.agent` Root
+
+The repo-level task brief now points at `.prodify/...` for runtime assets, while the repo-level workflow framework still lives under `./.agent/`.
+
+Impact:
+
+- the repo still has two different hidden roots with different responsibilities
+- operators need to distinguish meta-workflow files from runtime files clearly
+
+### 3. Roadmap Tasks And Runtime Tasks Are Not Explicitly Linked
+
+The repo-level roadmap defines implementation tasks through `72-validate-improvements`, but `./AGENTS.md` only documents the runtime execution pipeline `01` through `06`.
+
+Impact:
+
+- the plan does not explicitly state that Tasks `11-72` are framework-building tasks and Tasks `01-06` are the runtime tasks the framework will eventually execute
+- future work can blur design-time and run-time responsibilities
+
+### 4. Runtime Contract Lags Behind New Design Artifacts
+
+Tasks `21-33` produced design documents for run-state logic, task dispatch, artifact validation, step selection, loop control, and completed-step tracking. Those behaviors are not yet reflected in `./AGENTS.md`.
+
+Impact:
+
+- the active runtime contract remains underspecified relative to the newer design set
+- later implementation tasks will have to choose between the old runtime contract and the newer design docs unless the planning model names the source of truth
+
+### 5. Loop Semantics Conflict Across Sources
+
+`./AGENTS.md` currently says:
+
+- FAIL -> next step MUST execute
+- PASS -> STOP
+
+But the newer loop and state designs define:
+
+- PASS -> select the next remaining step or stop if none remain
+- FAIL -> retry or repair the same selected step before continuing
+
+Impact:
+
+- next-step resolution is currently ambiguous
+- Task `42-add-next-step-resolver` cannot be implemented cleanly until one loop model is declared canonical
+
+### 6. Artifact Location Assumptions Differ By Layer
+
+The repo-level task brief for Task `41` writes to `.prodify/artifacts/planning-alignment-report.md`, and the actual execution/design artifacts for this initiative now also live under `./.prodify/artifacts/`.
+
+Impact:
+
+- runtime artifact placement is now consistent, but the plan should still distinguish framework artifacts from meta-workflow artifacts
+
+## Exact Recommendations
+
+### Recommendation 1
+
+Create `./planning.md` as the canonical roadmap index for this initiative.
+
+It should define:
+
+- the purpose of the repo-level task bands
+- the intended phase order
+- the distinction between framework-building tasks and runtime execution tasks
+- which artifact tree each phase writes to
+
+### Recommendation 2
+
+Document the two-layer model explicitly in `./planning.md`:
+
+- `./.agent/` = repo-level workflow, review, verification, and meta-task tracking
+- `./.prodify/` = runtime task system, templates, runtime artifacts, and runtime state
+
+This removes the current ambiguity around generic `.agent/...` references.
+
+### Recommendation 3
+
+Add an explicit mapping section in `./planning.md` from roadmap task bands to runtime concerns:
+
+- `10` = task/header/template contract hardening
+- `20` = run-state, dispatch, and artifact validation
+- `30` = refactor-loop control
+- `40` = planning and next-step resolution
+- `50` = CLI/status surface
+- `60` = reporting
+- `70` = end-to-end validation
+
+### Recommendation 4
+
+Before or during Task `42-add-next-step-resolver`, choose and document one canonical loop model.
+
+Preferred choice:
+
+- PASS advances to the next remaining step or completes the run
+- FAIL retries or blocks on the same selected step
+
+That choice matches the newer design artifacts and supports deterministic completed-step tracking.
+
+### Recommendation 5
+
+Treat `./AGENTS.md` as the current runtime enforcement document, but do not treat it as complete until its loop/state semantics are reconciled with the design artifacts from Tasks `21-33`.
+
+### Recommendation 6
+
+Adopt an explicit artifact-placement rule in the planning document:
+
+- repo-level workflow artifacts stay under `./.agent/tasks/<task-name>/`
+- runtime system design and execution artifacts stay under `./.prodify/artifacts/`
+
+## Recommended Source-Of-Truth Model
+
+Until the plan is formalized, the least ambiguous source-of-truth stack is:
+
+1. `./.agent/tasks/*.md` for roadmap order and meta-task intent
+2. `./AGENTS.md` for currently enforced runtime rules
+3. `./.prodify/artifacts/*-design.md` for planned runtime evolution
+
+This is workable, but it is not fully aligned. A root `planning.md` should consolidate the model before more downstream planning tasks depend on it.
+
+## Conclusion
+
+The planning and execution model are only partially aligned today. The roadmap order is clear, but the canonical planning document is missing, the `.agent` root is ambiguous across two layers, and the runtime loop semantics conflict between `AGENTS.md` and the newer design artifacts. These gaps should be resolved before implementing next-step resolution and operator-facing execution controls.

package/.prodify/artifacts/refactor-plan-template-hardening.md

@@ -0,0 +1,83 @@
+# Refactor Plan Template Hardening
+
+Date: 2026-03-29
+Task: `83-harden-refactor-plan-template`
+
+## Problems In Current Template
+
+The current template is too loose for deterministic parsing because:
+
+- the step heading is placeholder-style rather than a fixed repeated structure
+- no per-step status field exists
+- the template does not strongly distinguish one step block from the next
+- step IDs are not normalized into an execution-friendly repeated pattern
+
+## Exact Revised Template Structure
+
+Use this fixed repeated step structure:
+
+```md
+# Refactor Plan
+
+## Summary
+- Total phases:
+- Total steps:
+- Estimated complexity:
+
+## Phase Breakdown
+- Phase:
+  - Goal:
+  - Notes:
+
+## Steps
+
+### Step: <ID>
+- Status: pending
+- Description:
+- Files:
+- Risk:
+- Expected outcome:
+- Validation command:
+
+### Step: <ID>
+- Status: pending
+- Description:
+- Files:
+- Risk:
+- Expected outcome:
+- Validation command:
+
+## Notes
+- 
+```
+
+## Parsing Benefits
+
+This structure improves parsing because:
+
+- every step starts with the exact `### Step:` marker
+- every step includes the same required fields in the same order
+- `Status` gives the runtime an explicit place for step-state tracking
+- automatic selection can key off stable step IDs instead of freeform headings
+
+## Compatibility Notes For Task 04
+
+Task `04-plan` should:
+
+- emit one repeated step block per planned step
+- assign a stable step ID to every step
+- default every new step to `Status: pending`
+- keep `Files`, `Risk`, `Expected outcome`, and `Validation command` populated for every step
+
+## Compatibility Notes For Task 05
+
+Task `05-refactor` should:
+
+- resolve the selected step from the fixed `### Step: <ID>` heading
+- require exactly one step block to be active per execution attempt
+- treat missing or malformed repeated fields as a stop condition
+
+## Result
+- A stricter step format is defined.
+- The format supports automatic step resolution and completed-step tracking.
+- The template remains human-readable and markdown-based.

package/.prodify/artifacts/refactor-validate-loop-design.md

@@ -0,0 +1,231 @@
+# Refactor Validate Loop Design
+
+Date: 2026-03-28
+Scope: `./.prodify/`
+
+## Purpose
+Define the iterative execution loop that runs one refactor step through Task `05-refactor`, immediately validates it with Task `06-validate`, and decides whether to continue, retry, pause, or stop.
+
+This loop is responsible for:
+- executing exactly one selected refactor step at a time
+- enforcing immediate validation after each Task `05-refactor`
+- deciding loop continuation from validation outcome and remaining-step state
+
+This loop is not responsible for:
+- selecting a step without consulting the step-selection layer
+- skipping validation
+- advancing workflow state without successful artifact validation
+
+## Loop Flow
+
+### Entry Conditions
+The loop may start only when:
+- `next_task` is `05-refactor`
+- workflow state is runnable (`ready` or a retryable `failed` state)
+- a valid step-selection result exists
+
+If no valid step-selection result exists:
+- do not enter the loop
+- stop in blocked or failed state depending on the cause
+
+### Loop Sequence
+1. Resolve the active step using the step-selection layer.
+2. Dispatch and execute Task `05-refactor` for exactly one step.
+3. Validate the Task 05 output artifact and update state to require Task `06-validate`.
+4. Dispatch and execute Task `06-validate` for the same selected step.
+5. Interpret the validation result.
+6. Choose one of:
+   - continue to the next step
+   - retry the same step
+   - pause/block for repair
+   - stop as complete
+
+## Decision Rules
+
+### Rule 1 - Task 05 Must Be Followed Immediately By Task 06
+After a successful Task `05-refactor` execution:
+- set the loop to validation mode immediately
+- do not select or execute another refactor step until Task `06-validate` finishes
+
+### Rule 2 - Validation PASS
+If Task `06-validate` passes:
+- mark the selected step as completed
+- ask the step-selection layer for the next step
+- if another valid step exists:
+  - continue the loop with `05-refactor`
+- if no valid steps remain:
+  - stop the loop as complete
+
+### Rule 3 - Validation FAIL
+If Task `06-validate` fails with a decisive negative result:
+- do not mark the step as completed
+- keep the same `selected_refactor_step`
+- move the loop into retry-or-repair decision mode
+
+Default behavior:
+- retry the same step only after the failure is understood and corrected
+- do not advance to a later step automatically
+
+### Rule 4 - Validation Inconclusive
+If Task `06-validate` cannot reach a trustworthy pass/fail result, treat the outcome as `inconclusive`.
+
+Examples:
+- missing validation inputs
+- incomplete validation artifact
+- ambiguous or partial validation output
+- execution interruption during validation
+
+Behavior:
+- do not mark the step completed
+- do not select the next step
+- pause the loop in a blocked state
+- require validation repair or rerun before continuing
+
+### Rule 5 - No Remaining Steps
+If the step-selection layer returns `no_steps_remaining` after a successful validation pass:
+- stop the loop
+- signal workflow completion
+
+### Rule 6 - Unpopulated Or Malformed Plan
+If the step-selection layer returns:
+- `plan_unpopulated`
+- `malformed_plan`
+- `invalid_state`
+
+Behavior:
+- do not run Task `05-refactor`
+- stop the loop immediately
+- mark the workflow blocked or failed according to the selection result
+
+## Retry Behavior
+
+### Retry Same Step
+Retry the same selected step only when:
+- Task `06-validate` produced a FAIL result
+- the selected step still exists in `refactor_plan.md`
+- the system has not switched into a terminal stop condition
+
+Retry rules:
+- keep `selected_refactor_step` unchanged
+- keep `completed_step_ids` unchanged
+- set `next_task` back to `05-refactor`
+- require the next cycle to target the same step
+
+### Do Not Skip Ahead After Failure
+The loop must not automatically choose the next remaining step after a failed validation result.
+
+Reason:
+- skipping ahead would hide regressions and violate the one-step-at-a-time repair discipline
+
+## Pause And Block Behavior
+
+### Pause Conditions
+Pause the loop when:
+- validation result is inconclusive
+- required artifacts are missing
+- the refactor plan is unpopulated or malformed
+- the selected step cannot be resolved
+- state contradictions are detected
+
+### Blocked Outcome
+When paused for a structural or recoverable issue:
+- set workflow status to `blocked`
+- leave a precise blocker note
+- require correction before resuming
+
+## Stop Behavior
+
+### Stop As Complete
+Stop the loop as complete only when:
+- the current step has passed validation
+- no remaining valid steps exist
+
+### Stop As Failed
+Stop the loop as failed when:
+- validation fails and no safe retry can proceed
+- state contradictions prevent deterministic continuation
+- selection or validation returns an unrecoverable invalid-state result
+
+### Stop Without Entering The Loop
+Do not start the loop if:
+- there is no selectable step
+- `refactor_plan.md` is still template-only
+- Task 05 cannot be dispatched safely
+
+## Fail-Safe Behavior For Inconclusive Validation
+
+### Inconclusive Result Handling
+Treat inconclusive validation as neither PASS nor FAIL.
+
+Required behavior:
+- do not append the step to `completed_step_ids`
+- do not select a next step
+- do not mark the workflow complete
+- do not silently downgrade to PASS
+- do not silently convert to a retry unless the missing validation condition is repaired
+
+Recommended state outcome:
+- `status: blocked`
+- `next_task: "06-validate"` or recovery-specific retry path
+- note the exact reason in workflow notes
+
+## Loop Decision Matrix
+
+| Current phase | Outcome | Next loop action | State intent |
+| --- | --- | --- | --- |
+| Step selection | `selected` | Run `05-refactor` | runnable |
+| Step selection | `plan_unpopulated` | Stop and block | blocked |
+| Step selection | `malformed_plan` | Stop and fail/block | failed or blocked |
+| Task 05 | output valid | Run `06-validate` immediately | awaiting validation |
+| Task 05 | output invalid | Retry or fail before validation | failed |
+| Task 06 | PASS | Select next remaining step or stop complete | ready or complete |
+| Task 06 | FAIL | Retry same step after correction | failed |
+| Task 06 | inconclusive | Pause for repair/rerun | blocked |
+
+## Integration Notes
+
+### Integration With Step Selection
+- The loop never invents a step ID.
+- It must always consult the step-selection layer before entering `05-refactor` for a new step.
+- After PASS, it must consult step selection again to determine whether another step remains.
+
+### Integration With Task 05
+- Task `05-refactor` must implement exactly one selected step.
+- The loop must reject any attempt to batch multiple steps in one iteration.
+
+### Integration With Task 06
+- Task `06-validate` must run immediately after each successful Task `05-refactor`.
+- Validation governs whether the loop continues, retries, pauses, or stops.
+
+### Integration With Run-State Logic
+- The run-state layer updates:
+  - `selected_refactor_step`
+  - `completed_step_ids`
+  - `next_task`
+  - `status`
+- The loop design defines when those updates should happen, not the low-level write mechanics.
+
+### Integration With Dispatcher
+- The dispatcher controls task dispatch sequencing.
+- The loop design controls the high-level decision of whether the dispatcher should schedule `05-refactor`, `06-validate`, or stop.
+
+## Retry/Stop Behavior Summary
+- PASS:
+  - complete current step
+  - continue if more valid steps remain
+  - otherwise stop complete
+- FAIL:
+  - keep same step active
+  - retry only after correction
+  - do not advance to a new step
+- inconclusive:
+  - pause/block
+  - require validation repair or rerun
+- invalid plan/state:
+  - stop before or during loop
+  - require repair before any further iteration
+
+## Implementation Notes
+- Prefer explicit state transitions over implicit loop assumptions.
+- Keep refactor and validation tightly paired; do not allow a second refactor before validating the first.
+- Treat inconclusive validation as a safety stop, not a soft pass.

package/.prodify/artifacts/refactor_plan.md

@@ -0,0 +1,21 @@
+# Refactor Plan
+
+## Summary
+- Total phases:
+- Estimated complexity:
+
+## Phase Breakdown
+- Phase:
+  - Goal:
+  - Notes:
+
+## Steps
+### Step ID:
+- Description:
+- Files:
+- Risk:
+- Expected outcome:
+- Validation command:
+
+## Notes
+- 

package/.prodify/artifacts/refactor_plan.strict-example.md

@@ -0,0 +1,31 @@
+# Refactor Plan
+
+## Summary
+- Total phases: 0
+- Estimated complexity:
+
+## Phase Breakdown
+- Phase:
+  - Goal:
+  - Notes:
+
+## Steps
+
+### Step: R01
+- Status: pending
+- Description:
+- Files:
+- Risk: low
+- Expected outcome:
+- Validation command:
+
+### Step: R02
+- Status: pending
+- Description:
+- Files:
+- Risk: med
+- Expected outcome:
+- Validation command:
+
+## Notes
+-