@doist/doistbot-cli 1.0.8 → 1.0.10

package/sandbox/src/tasks/review/prompts/review-focus-prompts/quality.md

@@ -1,28 +1,20 @@
 ## Review Focus: Quality
 
-For this pass, focus only on design quality, architecture, type safety, missed reuse, duplicated logic, and consistency with established patterns.
+For this pass, focus only on quality issues introduced by the diff.
 
-Flag findings when:
+Review the changes for potential quality issues, such as:
 
-- logic lives in the wrong layer or breaks an existing abstraction boundary
-- the diff introduces redundant state, brittle APIs, or stringly-typed code
-- the change deviates from surrounding patterns or documented guidance in a way that creates ongoing maintenance cost
-- a concrete type-safety or design issue should be fixed even if the code “works”
-- the diff reinvents a helper, utility, abstraction, or repeated block that already exists nearby
-- state duplicates existing state, cached values could be derived, or observers/effects could be direct calls
-- the diff adds new parameters to a function instead of generalizing or restructuring existing ones
-- near-duplicate code blocks are copied with slight variation and should be unified with a shared abstraction
-- internal details are exposed that should be encapsulated, or existing abstraction boundaries are broken
-- raw strings are used where constants, enums (string unions), or branded types already exist in the codebase
-- the diff adds wrappers or abstractions without clear reuse value instead of using a simple, direct solution
-- ternary chains, deeply nested if/else blocks, or nested switches obscure distinct cases, duplicate branches, or make error/edge paths easy to miss
-- broad try/catch blocks, fallback/null guard/logging paths, or safe wrappers are added without a real trust boundary or documented failure mode
-- logging-and-continue patterns hide errors where explicit failures or predictable failure modes would be better
-- errors are checked against message strings instead of codes or stable identifiers
-- broad any/type-ignore casts, sleeps/timeouts, fake success returns, removed checks, or path mutation hide a real failure
-
-Only report a design-quality finding when the maintenance cost is concrete: name the abstraction boundary, existing pattern, type contract, caller impact, helper, module, or repeated changed block that makes the change costly. Do not turn a naming, formatting, or preference nit into a [P1] or [P2].
-
-Do not repeat generic correctness bugs already covered by the general pass unless the design concern is distinct.
+1. Redundant state: state that duplicates existing state, cached values that could be derived, observers/effects that could be direct calls.
+2. Parameter sprawl: adding new parameters to a function instead of generalizing or restructuring existing ones.
+3. Copy-paste with slight variation: near-duplicate code blocks that should be unified with a shared abstraction.
+4. Layering and leaky abstractions: logic that lives in the wrong layer, exposes internal details that should be encapsulated, or breaks existing abstraction boundaries.
+5. Stringly-typed code: using raw strings where constants, enums (string unions), or branded types already exist in the codebase.
+6. Simplicity/YAGNI: prefer simple, direct solutions over wrappers, abstractions, configuration, options, extensibility, or scaffolding without clear reuse value or explicit need. Prefer deletion or direct code until the second use appears.
+7. Shrinkage: flag code that preserves behavior with fewer branches, lines, moving parts, or custom helpers. Do not shrink away input validation at trust boundaries, data-loss error handling, security measures, or accessibility basics.
+8. Nested conditionals: ternary chains, deeply nested if/else blocks, or nested switches should be simplified when they obscure distinct cases, duplicate branches, or make error/edge paths easy to miss.
+9. Over-defensive code: broad try/catch blocks, fallback/null guard/logging paths, or safe wrappers that are not tied to a real trust boundary or documented failure mode.
+10. Fail-fast: favor explicit failures over logging-and-continue patterns that hide errors. Prefer predictable failure modes over silent degradation.
+11. Error classification: ensure errors are checked against codes or stable identifiers, never error message strings.
+12. Band-aid code: broad any/type-ignore casts, sleeps/timeouts, fake success returns, removed checks, or path mutation that hides a real failure.
 
 If the diff does not introduce any findings for this focus, return an empty comments array.

package/sandbox/src/tasks/review/prompts/review-focus-prompts/reuse.md

@@ -0,0 +1,13 @@
+## Review Focus: Reuse
+
+For this pass, focus only on reuse issues introduced by the diff.
+
+Review the changes for potential reuse issues, such as:
+
+1. Search for existing capabilities that could replace newly written code: standard library APIs, native platform features, already-installed dependencies, and existing utilities/helpers. Search for relevant names and behavior, then go beyond string matches by inspecting adjacent files, utility files and directories, and shared modules.
+2. Flag any new function that duplicates existing functionality. Suggest the existing function, API, or feature to use instead.
+3. Flag any inline logic that could use an existing capability — hand-rolled standard-library behavior, string manipulation, manual path handling, custom environment checks, ad-hoc type guards, native platform features, and similar patterns are common candidates.
+4. Flag new dependencies when the standard library, runtime/platform, or an already-installed dependency provides the same capability or behavior.
+5. Flag duplicate modules, thin pass-through wrappers, and manual registries when they duplicate an existing source of truth or local pattern. Prefer deleting, consolidating, or reusing the existing path.
+
+If the diff does not introduce any findings for this focus, return an empty comments array.

package/sandbox/src/tasks/review/prompts/review-focus-prompts/security.md

@@ -0,0 +1,18 @@
+## Review Focus: Security
+
+For this pass, focus only on security issues introduced by the diff.
+
+Review the changes for potential security issues, such as:
+
+1. Auth and permissions: changed routes, commands, jobs, or data access must preserve required authentication, authorization, tenant isolation, and ownership checks.
+2. Untrusted input: SQL or command construction must be parameterized; path, URL, shell, and HTML output must be escaped or encoded for the target context.
+3. Filesystem and process boundaries: user-controlled paths and process arguments must not allow traversal, arbitrary file access, command injection, or unsafe environment changes.
+4. Server-side fetches: server requests to user-controlled URLs must block localhost, private/link-local IP ranges, cloud metadata endpoints, and internal hostnames, including after DNS resolution and redirects.
+5. Redirects and navigation: user-controlled destinations must be same-origin relative paths or explicitly allowlisted origins.
+6. Secrets: new logging, errors, telemetry, files, or API responses must not expose tokens, keys, credentials, cookies, or sensitive identifiers.
+7. Serialization and parsing: avoid unsafe deserialization, dynamic code execution, prototype pollution, XML external entities, YAML custom object construction, and parser modes that load external resources.
+8. Dependencies: newly added dependencies that touch input parsing, networking, auth, crypto, secrets, or code execution need an explicit security reason.
+
+Only flag issues with a concrete exploit path or trust-boundary failure introduced by the reviewed changes.
+
+If the diff does not introduce any findings for this focus, return an empty comments array.

package/sandbox/src/tasks/review/prompts/review-focus-prompts/tests.md

@@ -2,27 +2,17 @@
 
 For this pass, focus only on test quality and test-design issues introduced by the diff.
 
-Flag findings when:
-
-- the new tests are disproportionately complex for the behavior being covered
-- the tests rely on unnecessary mocking or deep implementation knowledge
-- the change duplicates existing coverage instead of extending nearby tests
-- the highest-value, practically testable scenario introduced by the diff is still untested
-- the tests are brittle in a way that will create avoidable maintenance cost
-
-Only report a missing-test finding when all of the following are true:
-
-- you can name the specific behavior or regression path introduced by this PR
-- the behavior is important enough that a regression would create real user, data, integration, or maintenance risk
-- there is an existing, practical test path nearby: same module, adjacent tests, established fixture, or test harness already used for similar behavior
-- the requested test would be reasonably scoped and would not require setting up a new test framework, major harness, large fixture system, or unrelated infrastructure first
-
-Do not ask for tests solely because code changed. Avoid missing-test findings for CI scripts, one-off developer tooling, thin wrappers, mechanical config changes, or helper utilities unless the diff introduces meaningful branching, parsing, persistence, security-sensitive behavior, or another high-risk path with an existing practical test seam.
-
-If a change is worth testing but the module is not currently testable without significant setup work, do not file a blocking test finding. You may mention the testability gap only when it is the core design issue introduced by the diff.
-
-Do not ask for broad "more coverage" or tests for behavior that is already covered by adjacent tests.
-
-Do not report production-code issues here unless they are directly tied to a test-quality problem.
+Review the changes for potential testing issues, such as:
+
+1. High-signal suite: favor a smaller test suite over exhaustive coverage. Treat tests as carrying maintenance cost. Each test should protect important behavior, a realistic failure mode, or a stable shared contract.
+2. Low-value coverage: flag tests added only to cover implementation trivia. Examples include trivial getters/wrappers/constants, exact internal formatting, incidental telemetry/log details or events, timer internals, framework wiring with no behavior of its own, synthetic edge cases with no realistic breakage story, or behavior already covered by a higher-value test.
+3. Test bloat: redundant cases, copy-paste matrices, excessive or repeated setup that should use or extract a fixture/helper, gratuitous snapshots, or unparameterized variations that increase maintenance cost without clear regression signal. Suggest consolidation or deletion in these cases.
+4. Missing coverage: important behavior that can break without a test failing. Only ask for new tests when you can name the public/user-visible contract, security/privacy boundary, data-loss risk, serialization/wire contract, state transition, permission check, concurrency issue, or prior regression being protected.
+5. Weak assertions: tests that do not check observable behavior or invariants.
+6. Implementation-coupled tests: tests that assert private details, internal calls, or branch structure instead of behavior. Logs are worth testing only when logging itself is required behavior.
+7. Over-mocking: mocks that erase the behavior under test, hide integration behavior, or only prove mocks were called/configured. Prefer real fixtures or recorded external-service interactions when local practice supports them.
+8. Flaky patterns: time, random data, network calls, ordering, concurrency, or shared state that is not controlled by fixtures, clocks, cleanup, or deterministic assertions.
+
+Do not ask for tests just because code changed. Only flag a missing test when you can name the important behavior or failure mode that could break. Only flag test removal/simplification when the remaining suite still protects the important intended behavior.
 
 If the diff does not introduce any findings for this focus, return an empty comments array.