@urielsh/prodify 0.1.0

package/.prodify/contracts-src/architecture.contract.md

@@ -0,0 +1,29 @@
+---
+schema_version: 1
+contract_version: 1.0.0
+stage: architecture
+task_id: 03-architecture
+required_artifacts:
+  - path: .prodify/artifacts/03-architecture.md
+    format: markdown
+    required_sections:
+      - Dependency Rules
+      - Policy Checks
+      - Proposed Structure
+      - Success Criteria
+      - Tradeoffs
+allowed_write_roots:
+  - .prodify/artifacts/
+forbidden_writes:
+  - src/
+  - tests/
+policy_rules:
+  - Flag mixed concerns explicitly.
+  - Keep Domain dependencies pointing inward only.
+success_criteria:
+  - The target structure is explicit.
+  - Architecture violations are listed clearly.
+---
+# Architecture Contract
+
+Use this contract to define the target structure, dependency rules, and major tradeoffs before planning.

package/.prodify/contracts-src/diagnose.contract.md

@@ -0,0 +1,29 @@
+---
+schema_version: 1
+contract_version: 1.0.0
+stage: diagnose
+task_id: 02-diagnose
+required_artifacts:
+  - path: .prodify/artifacts/02-diagnose.md
+    format: markdown
+    required_sections:
+      - Constraints
+      - Observed Issues
+      - Policy Checks
+      - Root Causes
+      - Success Criteria
+allowed_write_roots:
+  - .prodify/artifacts/
+forbidden_writes:
+  - src/
+  - tests/
+policy_rules:
+  - Diagnose from repository evidence only.
+  - Do not propose implementation changes in the diagnosis stage.
+success_criteria:
+  - Every critical issue is tied to evidence.
+  - Root causes are separated from symptoms.
+---
+# Diagnose Contract
+
+Use this contract to record observed problems, supporting evidence, and the most likely root causes.

package/.prodify/contracts-src/plan.contract.md

@@ -0,0 +1,29 @@
+---
+schema_version: 1
+contract_version: 1.0.0
+stage: plan
+task_id: 04-plan
+required_artifacts:
+  - path: .prodify/artifacts/04-plan.md
+    format: markdown
+    required_sections:
+      - Policy Checks
+      - Risks
+      - Step Breakdown
+      - Success Criteria
+      - Verification
+allowed_write_roots:
+  - .prodify/artifacts/
+forbidden_writes:
+  - src/
+  - tests/
+policy_rules:
+  - Keep the plan deterministic and minimal.
+  - Map every step back to a diagnosed issue or architecture rule.
+success_criteria:
+  - The plan enumerates executable steps.
+  - Verification is defined before refactoring starts.
+---
+# Plan Contract
+
+Use this contract to produce the smallest safe sequence of refactor steps and verification checkpoints.

package/.prodify/contracts-src/refactor.contract.md

@@ -0,0 +1,32 @@
+---
+schema_version: 1
+contract_version: 1.0.0
+stage: refactor
+task_id: 05-refactor
+required_artifacts:
+  - path: .prodify/artifacts/05-refactor.md
+    format: markdown
+    required_sections:
+      - Behavior Guardrails
+      - Changed Files
+      - Policy Checks
+      - Selected Step
+      - Success Criteria
+allowed_write_roots:
+  - .prodify/artifacts/
+  - README.md
+  - assets/
+  - src/
+  - tests/
+forbidden_writes:
+  - .prodify/contracts/
+policy_rules:
+  - Execute exactly one selected step.
+  - Keep the diff minimal and behavior-preserving unless the plan says otherwise.
+success_criteria:
+  - The selected plan step is implemented fully.
+  - Unrelated files remain untouched.
+---
+# Refactor Contract
+
+Use this contract to record the single plan step executed, the files changed, and the guardrails that preserved behavior.

package/.prodify/contracts-src/understand.contract.md

@@ -0,0 +1,29 @@
+---
+schema_version: 1
+contract_version: 1.0.0
+stage: understand
+task_id: 01-understand
+required_artifacts:
+  - path: .prodify/artifacts/01-understand.md
+    format: markdown
+    required_sections:
+      - Current State
+      - Open Questions
+      - Policy Checks
+      - Repository Summary
+      - Success Criteria
+allowed_write_roots:
+  - .prodify/artifacts/
+forbidden_writes:
+  - src/
+  - tests/
+policy_rules:
+  - Operate only on verified data.
+  - Preserve the existing behavior during understanding.
+success_criteria:
+  - The repository intent is captured clearly.
+  - Known unknowns are listed explicitly.
+---
+# Understand Contract
+
+Use this contract to describe the current repository, verified constraints, and open questions before diagnosis begins.

package/.prodify/contracts-src/validate.contract.md

@@ -0,0 +1,35 @@
+---
+schema_version: 1
+contract_version: 1.0.0
+stage: validate
+task_id: 06-validate
+required_artifacts:
+  - path: .prodify/artifacts/06-validate.md
+    format: markdown
+    required_sections:
+      - Policy Checks
+      - Regressions
+      - Success Criteria
+      - Validation Results
+  - path: .prodify/state.json
+    format: json
+    required_json_keys:
+      - preset_name
+      - preset_version
+      - runtime
+      - schema_version
+allowed_write_roots:
+  - .prodify/artifacts/
+  - .prodify/metrics/
+forbidden_writes:
+  - src/
+policy_rules:
+  - Validation must follow every refactor step.
+  - Critical regressions block forward progress.
+success_criteria:
+  - Validation records whether regressions were found.
+  - The result is strong enough to gate the next runtime transition.
+---
+# Validate Contract
+
+Use this contract to record validation evidence, regression status, and final readiness for the next state transition.

package/.prodify/metrics/README.md

@@ -0,0 +1,4 @@
+# Local Metrics
+
+Prodify writes local baseline, final, and delta score artifacts here.
+Normalized score outputs and raw tool outputs stay separate.

package/.prodify/planning.md

@@ -0,0 +1,13 @@
+# Planning
+
+## Current Milestone
+
+Describe the current milestone here.
+
+## Backlog
+
+- Add upcoming work items here.
+
+## Open Decisions
+
+- Record decisions that still need resolution.

package/.prodify/project.md

@@ -0,0 +1,15 @@
+# Project
+
+## Summary
+
+Describe the repository purpose here.
+
+## Goals
+
+- Capture project goals.
+- Record constraints and conventions.
+
+## Agent Bootstrap
+
+- The user starts by telling the agent to read `.prodify/AGENTS.md`.
+- The main Prodify flow should stay inside `.prodify/`.

package/.prodify/rules/01-global-operating-rules.md

@@ -0,0 +1,21 @@
+# Rule 01 — Global Operating Rules
+
+## Purpose
+Define the baseline behavior for every Prodify task.
+
+## Rules
+- Always follow the task sequence defined in `AGENTS.md` unless the user explicitly requests a single task.
+- Treat previous task artifacts as source of truth unless repository changes invalidate them.
+- Prefer evidence-based conclusions over assumptions.
+- Be conservative when repository intent is unclear.
+- Never widen scope silently.
+- Always state uncertainty explicitly.
+- Prefer minimal, reversible changes.
+
+## Required Behavior
+For every task execution, explicitly report:
+- current task
+- inputs used
+- output artifact produced
+- whether source code was modified
+- next recommended step

package/.prodify/rules/02-analysis-discipline.md

@@ -0,0 +1,17 @@
+# Rule 02 — Analysis Discipline
+
+## Purpose
+Keep repository analysis deterministic and high-signal.
+
+## Rules
+- During analysis tasks, do not modify code.
+- Distinguish clearly between observed facts and inferred conclusions.
+- When inferring architecture or module roles, tie conclusions to concrete repository evidence.
+- Ignore generated, vendored, cache, and build-output directories unless directly relevant.
+- Prefer shallow-wide scanning before deep local inspection.
+- For monorepos, identify workspace/package boundaries before reasoning about architecture.
+
+## Anti-Patterns to Avoid
+- Inventing structure not present in the repository
+- Treating naming conventions as proof without corroborating evidence
+- Over-indexing on one file while ignoring surrounding module context

package/.prodify/rules/03-diagnosis-severity-rules.md

@@ -0,0 +1,42 @@
+# Rule 03 — Diagnosis Severity Rules
+
+## Purpose
+Standardize issue severity so results remain actionable.
+
+## Severity Definitions
+
+### Critical
+Use only when the issue materially threatens:
+- correctness
+- operability
+- security
+- architectural integrity
+
+Examples:
+- circular dependencies in core execution paths
+- unvalidated external input at critical boundaries
+- direct mixing of core business logic with infrastructure in high-centrality modules
+
+### High
+Use when the issue significantly increases maintenance or failure risk.
+
+Examples:
+- very large files in central modules
+- core functions with missing error handling
+- obvious mixed concerns across important boundaries
+
+### Medium
+Use when the issue is harmful but not immediately destabilizing.
+
+Examples:
+- dense TODO/FIXME clusters
+- duplicated logic in non-critical paths
+- naming inconsistencies that reduce readability
+
+### Low
+Use for minor cleanliness or consistency issues.
+
+## Rules
+- Prefer under-classifying over exaggerating.
+- Every non-low issue must reference concrete files.
+- Avoid noisy reports that overwhelm the plan.

package/.prodify/rules/04-architecture-rules.md

@@ -0,0 +1,27 @@
+# Rule 04 — Architecture Rules
+
+## Purpose
+Define the architectural posture Prodify should favor.
+
+## Default Target
+When feasible, prefer **Modular Clean Architecture** with these layers:
+1. Domain
+2. Application
+3. Infrastructure
+4. Interface
+
+## Dependency Rules
+- Dependencies should point inward toward Domain.
+- Domain must not depend on Infrastructure or Interface.
+- Application may depend on Domain.
+- Infrastructure may depend on Application and Domain only when necessary for implementation.
+- Interface may depend on Application and Domain-facing contracts, not infrastructure internals directly.
+
+## Exceptions
+- If the repository is a small CLI or utility library, avoid forcing heavyweight layering.
+- Tailor the target architecture to the project type and tech stack.
+
+## Violation Patterns
+- controllers/routes calling repositories directly
+- domain logic importing framework-specific modules
+- infrastructure concerns embedded in UI or interface layer

package/.prodify/rules/05-planning-rules.md

@@ -0,0 +1,23 @@
+# Rule 05 — Planning Rules
+
+## Purpose
+Ensure refactor plans are executable by coding agents.
+
+## Rules
+- Plans must be atomic.
+- Each step must have a single clear objective.
+- Each step should leave the codebase in a buildable state.
+- Do not combine unrelated concerns in one step.
+- Order work from safest to riskiest unless dependencies require otherwise.
+- Prefer scaffolding and boundary creation before deep core rewrites.
+- Every step must define:
+  - description
+  - files affected
+  - risk
+  - expected outcome
+  - validation command or check
+
+## Risk Weights
+- low = 1
+- med = 3
+- high = 10

package/.prodify/rules/06-refactor-rules.md

@@ -0,0 +1,20 @@
+# Rule 06 — Refactor Rules
+
+## Purpose
+Control code modification behavior during implementation.
+
+## Rules
+- Only Task 05 may modify source files.
+- Execute exactly one plan step at a time unless explicitly told otherwise.
+- Modify only necessary files.
+- Preserve public behavior unless the selected step explicitly requires a contract change.
+- Follow the project's existing naming and style conventions unless the plan step is specifically about normalization.
+- Prefer surgical edits over broad rewrites.
+- Avoid opportunistic cleanup unrelated to the selected step.
+- If scope expansion becomes necessary, document why before changing additional files.
+
+## Diff Policy
+A good refactor diff is:
+- minimal
+- traceable
+- justified by the selected plan step

package/.prodify/rules/07-validation-rules.md

@@ -0,0 +1,25 @@
+# Rule 07 — Validation Rules
+
+## Purpose
+Define how Prodify judges readiness after refactoring.
+
+## Rules
+- Validation must happen after every Task 05 execution.
+- Be strict and evidence-based.
+- Re-check architecture boundaries against `architecture_spec.json`.
+- Re-check for dependency cycles where relevant.
+- Highlight regressions introduced during refactoring.
+- Do not mark PASS when meaningful high-severity issues remain unresolved in the modified scope.
+
+## Scoring Dimensions
+Score 0-100 for:
+- architecture
+- maintainability
+- reliability
+- testability
+
+## Pass Guidance
+A pass should mean:
+- no critical regressions
+- no unresolved high-severity violations in the changed scope
+- structure improved measurably relative to baseline

package/.prodify/rules/08-output-format-rules.md

@@ -0,0 +1,20 @@
+# Rule 08 — Output Format Rules
+
+## Purpose
+Keep artifacts and reports consistent across tasks.
+
+## Rules
+- Use the exact artifact names defined in `AGENTS.md`.
+- Keep markdown outputs structured, stable, and section-based.
+- Use consistent heading names across tasks.
+- Keep sections in the same order every time.
+- If confidence or uncertainty exists, include it explicitly rather than hiding it in prose.
+
+## Required Reporting Pattern
+For each task response, include:
+1. Current task
+2. Inputs
+3. Work performed
+4. Output artifact
+5. Code modified: yes/no
+6. Next step

package/.prodify/rules/09-template-usage-rules.md

@@ -0,0 +1,11 @@
+# Rule 09 — Template Usage Rules
+
+## Purpose
+Ensure every task artifact conforms to a shared markdown schema.
+
+## Rules
+- Before writing an artifact, consult the matching markdown template in `.prodify/templates/`.
+- Preserve required headings and section order from the template.
+- Prefer explicit empty sections or uncertainty notes over invented values.
+- Add optional subsections only when they improve traceability and do not confuse downstream tasks.
+- If a task cannot confidently populate a section, keep the section and mark uncertainty explicitly.

package/.prodify/rules/10-artifact-flow-and-orchestration-rules.md

@@ -0,0 +1,40 @@
+# Rule 10 — Artifact Flow and Orchestration Rules
+
+## Purpose
+Define how outputs flow automatically between Prodify tasks.
+
+## Artifact Location
+All task artifacts live in `.prodify/artifacts/`.
+
+## Handoff Rules
+- Every task must read its declared inputs from `.prodify/artifacts/`.
+- Every task must write exactly one primary output artifact declared in its frontmatter.
+- Before starting a task, verify that all required input artifacts exist.
+- After completing a task, validate the output structure against the matching template in `.prodify/templates/`.
+- If output validation fails, do not advance workflow state.
+- If an expected artifact is missing or stale, regenerate it before continuing.
+
+## Workflow State
+Use `.prodify/artifacts/run_state.json` as the source of truth for:
+- current task
+- last completed task
+- next task
+- selected refactor step
+- overall status
+
+Use `.prodify/artifacts/task_log.json` to append execution history.
+
+## Loop Rules
+- Tasks 01 through 04 are linear.
+- Task 05 executes exactly one refactor step at a time unless explicitly told otherwise.
+- Task 06 must run after every Task 05 execution.
+- If Task 06 fails and more refactor steps remain, loop back to Task 05.
+- If Task 06 passes or requested scope is complete, stop.
+
+## Reporting Rules
+Every task response must include:
+1. Current task
+2. Inputs
+3. Output artifact
+4. Code modified: yes/no
+5. Next step

package/.prodify/rules/README.md

@@ -0,0 +1,3 @@
+# Prodify Rules
+
+This directory is reserved for rule documents that refine the default workflow for the current repository.

package/.prodify/rules/example-rule.md

@@ -0,0 +1,4 @@
+# Example Rule
+
+- Keep generated output deterministic.
+- Prefer canonical edits over generated-file edits.

package/.prodify/runtime-commands.md

@@ -0,0 +1,57 @@
+# Runtime Commands
+
+Run these commands inside your coding agent after `prodify init`.
+If this machine has not been prepared for that agent yet, run `prodify setup-agent <agent>` outside the repo first.
+
+## Manual Bootstrap
+
+- First tell the agent: `Read .prodify/AGENTS.md and bootstrap Prodify for this repository.`
+- Keep the run anchored to `.prodify/AGENTS.md`, `.prodify/project.md`, `.prodify/planning.md`, `.prodify/contracts-src/`, `.prodify/contracts/`, `.prodify/skills/`, `.prodify/artifacts/`, `.prodify/metrics/`, `.prodify/tasks/`, and `.prodify/state.json`.
+
+## Commands
+
+- `$prodify-init`
+  - inspect `.prodify/`
+  - detect or resolve the active agent/runtime mode
+  - initialize `.prodify/state.json`
+  - prepare the bootstrapped state and the `understand` contract without locking the repo to one agent
+
+- `$prodify-execute`
+  - run one workflow stage
+  - write stage artifacts under `.prodify/artifacts/`
+  - validate the stage against the compiled contract JSON
+  - update runtime state after the validation result
+  - pause for validation checkpoints between stages in interactive mode
+
+- `$prodify-execute --auto`
+  - continue across stages without pausing
+  - stop only on hard failure, policy block, required approval threshold, or invalid state
+
+- `$prodify-resume`
+  - continue from `.prodify/state.json`
+  - preserve validation checkpoints
+  - fail clearly if the state is corrupt or non-resumable
+
+## Supported Runtime Profiles
+
+- Codex
+- Claude
+- Copilot
+- OpenCode
+
+## Stage Order
+
+- `understand`
+- `diagnose`
+- `architecture`
+- `plan`
+- `refactor`
+- `validate`
+
+## Contract Rules
+
+- Source contracts live under `.prodify/contracts-src/*.contract.md`.
+- Runtime execution reads only `.prodify/contracts/*.contract.json`.
+- Skill definitions live under `.prodify/skills/*.json`.
+- Stage skill routing can activate bounded skills per stage, but contracts and validators remain authoritative.
+- Stage completion is gated by compiled-contract validation, not by agent assertion alone.

package/.prodify/skills/README.md

@@ -0,0 +1,8 @@
+# Skills
+
+This directory contains the product-owned skill registry for deterministic stage execution.
+
+- `registry.json` is the manifest and source of truth for discoverable skills.
+- Each `*.skill.json` file defines one bounded skill.
+- Contracts may reference skills only through explicit `skill_routing`.
+- Skills can improve execution quality, but they never override compiled contracts or validation.

package/.prodify/skills/domain/react-frontend.skill.json

@@ -0,0 +1,34 @@
+{
+  "schema_version": "1",
+  "id": "react-frontend",
+  "name": "React Frontend",
+  "version": "1.0.0",
+  "category": "domain",
+  "description": "Provides React-specific implementation and review guidance when a React surface is detected.",
+  "intended_use": [
+    "Use in understand, architecture, refactor, and validate when the repo framework includes React."
+  ],
+  "stage_compatibility": [
+    "architecture",
+    "refactor",
+    "understand",
+    "validate"
+  ],
+  "activation_conditions": [
+    {
+      "all": [
+        {
+          "fact": "framework",
+          "includes": "react"
+        }
+      ]
+    }
+  ],
+  "execution_guidance": [
+    "Preserve component boundaries and data-flow clarity.",
+    "Keep framework-specific advice subordinate to stage contracts."
+  ],
+  "caution_guidance": [
+    "Do not assume a frontend repo unless React evidence is present."
+  ]
+}

package/.prodify/skills/domain/typescript-backend.skill.json

@@ -0,0 +1,34 @@
+{
+  "schema_version": "1",
+  "id": "typescript-backend",
+  "name": "TypeScript Backend",
+  "version": "1.0.0",
+  "category": "domain",
+  "description": "Applies TypeScript service and CLI implementation guidance when the repository is TypeScript-based.",
+  "intended_use": [
+    "Use in architecture, refactor, and validate when the repo language includes TypeScript."
+  ],
+  "stage_compatibility": [
+    "architecture",
+    "refactor",
+    "understand",
+    "validate"
+  ],
+  "activation_conditions": [
+    {
+      "all": [
+        {
+          "fact": "language",
+          "includes": "typescript"
+        }
+      ]
+    }
+  ],
+  "execution_guidance": [
+    "Prefer type-safe interfaces and explicit runtime-state normalization.",
+    "Keep generated JavaScript output aligned with TypeScript sources."
+  ],
+  "caution_guidance": [
+    "Do not rely on implicit any-style assumptions when shaping refactors."
+  ]
+}

package/.prodify/skills/quality-policy/maintainability-review.skill.json

@@ -0,0 +1,25 @@
+{
+  "schema_version": "1",
+  "id": "maintainability-review",
+  "name": "Maintainability Review",
+  "version": "1.0.0",
+  "category": "quality-policy",
+  "description": "Highlights readability, ownership, and long-term support risks without redefining success criteria.",
+  "intended_use": [
+    "Use in diagnose, architecture, and plan when maintainability concerns are relevant."
+  ],
+  "stage_compatibility": [
+    "architecture",
+    "diagnose",
+    "plan",
+    "understand"
+  ],
+  "activation_conditions": [],
+  "execution_guidance": [
+    "Call out mixed concerns and unclear ownership paths.",
+    "Prefer small, explainable structure improvements."
+  ],
+  "caution_guidance": [
+    "Do not replace contract validation with style preference."
+  ]
+}