# Assertive Solving Mode

Use this standard for local/dev Runtime, workflow, testing, service recovery,
proof-channel, and scaffolding work where the package or chunk selects
`assertive_solving`.

## Rule

Solve local, well-scoped prerequisites instead of converting them into vague
carry-forward debt.

Assertive solving is not permission to cross authority boundaries. It is a
decision rule for local feasible blockers: research them, implement the narrow
prerequisite, validate it, then resume the original chunk.

## Modes

`assertive_solving`:

- default for local/dev Runtime hardening, proof-channel, testing, validation,
  service recovery, workflow observability, and scaffolding packages.
- fixes missing local prerequisites when they are well-scoped, compatible with
  current architecture, safe, and required for the active outcome.
- may insert a prerequisite chunk when the prerequisite needs separate durable
  lifecycle evidence.
- requires proof matching the claim before success is reported.

`conservative`:

- required for lifecycle authority changes, approval/close/commit authority,
  dispatcher authority, security/auth/secret handling, destructive data risk,
  production-like availability risk, broad framework choice, filesystem
  taxonomy migration, or ambiguous product decisions.
- stops for operator, requirements, or architecture review before expanding
  scope.

## Decision Rules

Implement the prerequisite now when all of these are true:

- the blocker is local to the repo or local/dev runtime.
- the fix is well-scoped and testable.
- the fix is compatible with current architecture and standards.
- the active chunk cannot honestly meet acceptance criteria without it.
- the work does not cross a conservative-mode boundary.

Create and solve a prerequisite chunk when:

- the prerequisite is local and feasible but deserves its own lifecycle
  evidence.
- the active prompt already permits splitting or package orchestration.
- solving it first reduces repeated proof/validation failure.

Create or update a CFD only when:

- the remaining work is broad, unsafe, authority-sensitive, product/security
  dependent, or genuinely belongs to a later independent package.
- the current chunk remains complete without it.
- the registry entry states why the fix is not done now, the owner surface, the
  next action, and the revisit trigger.

Do not create a CFD for:

- a missing test harness that is local, narrow, and needed for proof.
- a local wrapper/tool gap that can be safely implemented.
- shell drift when a narrow typed Runtime/Node migration is feasible.
- validation/proof failure that can be fixed inside the active scope.

## Proof Rules

- User-visible live behavior requires browser proof.
- Service reliability claims require service/supervisor evidence plus UI or
  operator-surface proof when the claim is user-facing.
- Testing-channel reliability claims require bounded report evidence and
  cleanup evidence.
- Runtime/backend truth must remain Runtime/backend-owned.
- Socket.IO remains invalidation metadata only.
- Frontend may display local connection state but must not infer Runtime,
  workflow, service, approval, or dispatcher truth.

## Stop Conditions

Stop rather than assertively solving when the fix would:

- change lifecycle, approval, close/commit, dispatcher, or permission authority.
- require unsafe credentials or secret exposure.
- risk destructive database or filesystem changes.
- require production-like restart/availability decisions.
- require broad service-manager, event-sourcing, frontend framework, backend
  framework, or filesystem taxonomy redesign.
- hide real failures behind warnings or downgrade meaningful errors.

## Review Checklist

Developer and QA must verify:

- local feasible blockers were solved or explicitly justified as conservative
  stops.
- CFDs are precise and explain why the fix was not done now.
- proof matches the claim.
- prerequisite chunks, when created, are resumed back into the original package.
- no authority boundary was weakened.