seniorify/ work
awaiting defense · 5 opensmoke/test#1
live audit · martin brianmanager view →
task
smoke/test#1smoke test plan
submitted bymartin · 45m ago
plan
smoke test plan
status
awaiting defense
conventions in scope
  • Use @acme/http for outbound calls; never axios or fetch directly.
  • Retries must use @acme/retry with idempotency-key header.
  • Logger: @acme/log only. No console.log in committed code.

findings

5
5 warn5 open
  • convention·f_1
    No mention of @acme/http for outbound calls
    The plan doesn't reference the internal HTTP client at all. If any outbound calls are made, using raw fetch or axios would violate the team convention and bypass any centralized auth, timeout, or retry wiring baked into @acme/http.
    why x and not y
    Why @acme/http and not fetch directly? fetch is simpler to reach for, but @acme/http centralizes auth headers, base URL config, and hooks into @acme/retry — doing it by hand duplicates that logic and creates drift.
  • convention·f_2
    No observability registration mentioned
    The plan makes no mention of registering with @acme/observability. Any new endpoint that skips this won't appear in traces, making it invisible during incidents and impossible to correlate with upstream calls.
    why x and not y
    Why @acme/observability and not ad-hoc logging? Structured traces propagate context across service boundaries; logs alone can't reconstruct a distributed call chain.
  • compliance·f_3
    PII logging risk not addressed
    The plan says nothing about what gets logged or how request bodies are handled. If any request body contains user data, logging it would violate the team's PII compliance rule and potentially regulatory requirements.
    why x and not y
    Why scrub/omit request bodies and not log everything for debuggability? Full logging aids debugging but creates a compliance liability if PII is present; selective field logging gives observability without exposure.
  • convention·f_4
    Retry strategy not specified
    There is no mention of @acme/retry or idempotency-key headers for any operations in the plan. Without this, transient failures won't be handled consistently and duplicate writes become a risk on retried calls.
    why x and not y
    Why @acme/retry with idempotency-keys and not manual try/catch retries? Manual retries are simpler but lack idempotency guarantees, meaning a retried non-idempotent call can cause duplicate side effects.
  • simplicity·f_5
    Plan is too vague to audit meaningfully
    The plan body is just 'smoke test plan' with no described steps, components touched, or scope. It's impossible to assess edge cases, ownership, or compliance posture from this level of detail, so real risks may be hidden.
    why x and not y
    Why a structured plan with explicit steps and not a high-level label? A label communicates intent but not tradeoffs — explicit steps expose assumptions early, when they're cheapest to correct.
5 open · cannot sign