Conflict resolution rules

When /review says "add detail" and /security says "hide it", precedent rules decide.

The problem

Three phases analyze the same code independently. They produce conflicting recommendations. /review wants more detailed error messages to help debugging. /security wants less information in errors to prevent data leakage. /qa wants errors to be testable and deterministic. Without a resolution framework, the agent has to guess which recommendation wins.

The 10 conflict precedents

nanostack ships with 10 built-in precedent rules covering the most common tensions between review, QA, and security:

ID       Tension                              Resolution
──────────────────────────────────────────────────────────────────────────
CP-001   Review: add logging  vs               Log to structured logger,
         Security: limit exposure               never to stdout. Redact PII.

CP-002   Review: detailed errors  vs           Generic message to user,
         Security: hide internals               full detail in server logs.

CP-003   QA: deterministic output  vs          Seed randomness in test,
         Security: rotate secrets               real rotation in production.

CP-004   Review: DRY / shared code  vs         Shared logic OK. Shared
         Security: isolate auth paths           auth logic must stay isolated.

CP-005   Review: simplify conditionals  vs     Keep explicit checks for
         Security: explicit permission checks   permissions. Readability yields.

CP-006   QA: mock external services  vs        Mock in unit tests. Real
         Security: test real integrations        calls in integration tests.

CP-007   Review: inline helpers  vs            Keep validation functions
         QA: testable units                     as separate, testable units.

CP-008   Review: remove dead code  vs          Remove dead code. Archive
         Security: preserve audit trail          in git history, not in source.

CP-009   QA: fast tests  vs                    Security tests can be slow.
         Security: thorough scanning             Run them in CI, not pre-commit.

CP-010   Review: fewer dependencies  vs        Fewer is better. But use
         Security: vetted libraries only         vetted libraries over DIY crypto.

Default precedence

When a conflict is not covered by a specific precedent rule, the default precedence order applies:

security > review > qa

Security wins by default because security failures are harder to detect and more expensive to fix after deployment. Review outranks QA because structural code quality prevents a larger class of bugs than test coverage alone.

This order is a default, not a law. Override it per project if your domain has different priorities.

How /ship resolves conflicts

When /ship reads the three phase artifacts, it:

  • Extracts all recommendations from review, QA, and security artifacts.
  • Groups recommendations that touch the same file or function.
  • Checks each group against the 10 precedent rules.
  • For groups with no matching precedent, applies the default precedence order.
  • Produces a final list with the winning recommendation and a note explaining why the other was deferred.
# Example /ship output for a conflict:

## Resolved conflict: src/api/errors.ts

- /review recommended: "Add request ID and stack trace to error response"
- /security recommended: "Return generic error message, log details server-side"
- Resolution: CP-002 — Generic message to user, full detail in server logs.
- Action: Modify error handler to return { error: "Internal error", requestId }
  and log the full stack trace to the structured logger.

Create your own precedent

Add precedent rules to reference/conflict-precedents.md in your skill directory. Use the same format the built-in precedents follow:

## CP-011: Performance vs. Security

**Tension:** /review says "cache the auth token for faster lookups"
vs. /security says "validate the token on every request."

**Resolution:** Validate on every request. Cache the validation
result for up to 60 seconds with a signed cache key. Never cache
the raw token.

**Precedence:** security > review

Custom precedents are checked before the default precedence order. If your rule matches the conflict, it wins. If no custom rule matches, the default order applies.

Number your custom precedents starting from CP-011 to avoid colliding with the built-in rules. There is no upper limit on how many precedents you can define.

Previous← ConductorNextDomain examples →