indeliblevivi/servotab

Investigate and fix bugs, failing tests, regressions, build failures, or unexpected behavior using boundary localization, evidence, and bounded hypotheses.

Choose responsibility for substantial work before deep execution: keep one responsibility's coupled parts in a single lane, and hand a bounded or independent lane to a worker when clean context, an unknown cause, independent review, or coordinator attention materially improves the outcome.

Turn a rough feature, product interaction, or architecture idea into a concrete design. Use when meaningful decisions remain open; avoid for already-clear local edits.

Implement a settled request or current execution strategy through connected slices, feed observations into the same task record, and revise affected work when evidence changes.

Finish a development change safely by inspecting the final tree, verifying at the right scope, and performing only the requested Git or PR actions.

Assess, adapt, and apply specified discussions, feedback, findings, or references to existing project work. Preserve coverage, corrections, and selected intent; judge fit and carry adopted effects through the authorized result. Includes technical review feedback; incidental sources or understanding material without a target-work adoption question need no separate incorporation workflow.

Form and maintain execution strategy when order, effort, evidence timing or recovery materially affects the outcome, even with a settled goal. Reuse durable task records when continuity needs them; keep clear work direct.

Review a diff, commit, branch, PR, or implementation for actionable correctness and risk issues without duplicate reviewer loops or invented findings.

Use for hands-on repository work when a quiet, risk-scaled engineering method can improve design, execution strategy, implementation, material incorporation, debugging, review, delegation, workspace lifecycle, or verification. Keep clear local changes direct, preserve the complete requested outcome, and add method only where risk or uncertainty justifies it. Do not use for general technical explanations, simple file lookup, casual discussion, or non-engineering writing.

Preserve an approved specification through a complete implementation plan and execution. Use for major refactors, migrations, or multi-session work when a confirmed spec is authoritative; keep scope and order changes explicit.

Apply risk-based test-driven development to bugs, domain logic, state transitions, parsers, contracts, migrations, and behavior where a failing test sharpens the design.

Verify code or product claims after changes using fresh, risk-matched evidence. Use before saying a bug is fixed, tests pass, requirements are met, or a branch is ready.

Choose, reuse, restore, park, or clean up Git workspaces while preserving work and host ownership. Create isolation only when it resolves a real conflict; inspection does not authorize creation or deletion.