MPHarness AI IDE Rules

# MPHarness AI IDE Rules

## CRITICAL DIRECTIVE (DO NOT IGNORE)
You are operating within an **MPHarness** project. Context drift is strictly forbidden. 
With **EVERY SINGLE PROMPT** you receive, you MUST mentally verify that you are adhering to the rules defined in CONSTITUTION.md and AGENTS.md. 

## 1. Zero Assumptions
Never assume requirements, architecture, or next steps. If SPECIFICATION.md is empty, incomplete, or if you are missing information, STOP and ask the user. 

## 2. No Massive Commits to main
- You are strictly forbidden from committing directly to the main or master branch for active development.
- You MUST create semantic branches (e.g., feat/, bugfix/).
- Commits MUST be atomic and component-level (e.g. one for DB, one for UI). Do not wait until the end of the session to commit everything. Commit early, before running heavy tests.

## 3. Strict Startup Sequence (No coding without a plan)
Before writing a single line of code in a new session or project:
1. You MUST read the current state of the project.
2. You MUST present a **Startup Report and Execution Plan (Phases/Fases)** to the user.
3. You MUST wait for the user's explicit approval before proceeding.

## 4. Living Documentation
You must keep `TASKS.md`, `TRACKING.md`, and `SPECIFICATION.md` updated in real-time as you progress. This is not optional.

## 5. Security & Zero Secrets
- NEVER commit secrets, API keys, private tokens, passwords, or `.env` files.
- The repository enforces mechanical pre-commit scanning with Gitleaks. If you stage any credentials, the hook will abort the commit.

## 6. Automatic Tool Selector (SpecKit vs OpenSpec)
- **New Feature from scratch?** -> Route to GitHub Spec Kit (`/speckit.specify` -> `/speckit.plan` -> `/speckit.tasks`).
- **Modifying / Refactoring existing logic?** -> Route to OpenSpec (`openspec propose` delta).
- **Committing / Security / Branching?** -> Governed by MPHarness (Gitleaks, Pre-commit, OWASP).
- **Zero Double-Bookkeeping:** Micro-tasks live in the active tool's files; root `TASKS.md` records macro phase milestones. NEVER duplicate checklists across files.

## 7. Dependency Audits & Selective Pinning
- When running `harness audit` or updating dependencies, ALWAYS present an Upgrade Proposal Report (Package, Current, Target, Reason, Affected Files).
- You MUST ask for user approval and pinning decisions BEFORE modifying packages.
- Always run tests on affected modules before committing. Discard any updates the user rejects/pins.

**If you fail to follow these rules, the built-in mechanical Git hooks (branch protection & Gitleaks) will block your commits.**