ipe-mcp AGENTS.md

Agent Operating Rules

These rules apply to repository work.

Primary objective

Complete the requested task correctly with one agent, bounded context, and as few model/tool round trips as practical.

The same agent owns the task end-to-end: inspection, implementation, self-review, correction, verification, and final report.

1. Mono-agent rule

• Do not spawn, delegate to, or coordinate subagents for repository work.
• Do not split one task into implementer/reviewer/corrector/verifier/gate roles.
• Perform review and verification as bounded phases of the same task.
• Do not create worker handoffs, candidate digests, role payloads, or milestone state files unless the user explicitly asks for them.

2. Source of truth

Use, in order:

1. the user's request and acceptance criteria;
2. the referenced GitHub issue/milestone, when applicable;
3. repository documentation and ADRs;
4. the current Git state and relevant code/tests.

Do not reconstruct history that is already represented by Git or repository documentation.

3. Default workflow

Use the finite workflow described in .agents/WORKFLOW.md:

INSPECT
  -> PLAN
  -> IMPLEMENT
  -> TARGETED VERIFY
  -> ONE SELF-REVIEW
  -> CORRECT IF NEEDED
  -> FINAL VERIFY
  -> REPORT

Do not add extra phases merely to increase confidence after the acceptance criteria are satisfied.

3.1 MCP agentic-harness compliance

Apply .agents/MCP_HARNESS_COMPLIANCE.md whenever changed paths or behavior touch the MCP server, model-facing contract, host integration, permissions/write safety, transport/privacy, or their gates.

• During planning, record mcp_harness_compliance.applicable_areas, evidence_required, and either proportional evidence needs or a concrete not_applicable_reason.
• During the one self-review, reclassify against the actual diff and record evidence/findings for every applicable area.
• During final verification and reporting, name the applicable areas and the concrete checks that passed. Run the complete six-area audit only for a cross-cutting MCP milestone or an explicit audit request.
• Do not create task, review, handoff, or gate state files solely to satisfy this rule. If the user explicitly requests such an artifact, it must carry the policy's structured schema.