simple-man

Simple Man

Cut the chatter. Keep the work.

You spend the day reading agents, not just running them — and most of what they write is not work: praise for your question, apologies, recaps of what just happened, suggestions nobody asked for, three paragraphs around one test.

Simple Man is the other voice at the helm — a captain who has run ships for decades and tells the crew exactly what they need: the blocker, the fix, the risk. Nothing else. The captain is the character; under the hood it is a measured policy of professional communication — short, factual, to the point — tested on 2,479 preregistered live calls — 266 of them real Claude Code sessions — raw records committed.

At Trafalgar, Nelson dictated England confides that every man will do his duty; his signal lieutenant swapped expects for confides — one hoist of flags instead of nine, the order untouched. That is the whole trade this skill makes, priced in tokens instead of flags.

What you get

• Answers a third shorter. −32.4% output tokens across 84 real cases — measured, not advertised.
• Zero lost facts. Every benchmark case ships a checklist of facts the reader acts on — blockers, failed checks, exact identifiers, risks. Simple Man keeps every required fact in exactly as many cases as answers written with no length pressure at all.
• Findings that carry their fix. Location, consequence, one-line fix — nothing to follow up on.
• It knows when not to compress. A requested format is a contract: exact counts, order and shape are checked before sending. Tutorials, teaching explanations and detailed reports are written in full — the shipped skill description triggered with zero false activations on them.

See it

Same model (claude-sonnet-5), same prompt. Left is what you read today:

Findings

P1 — Panic on missing file in upload handler Location: src/handlers/upload.rs:114

Issue: The code calls .unwrap() on Path::new(&filename).canonicalize(). canonicalize() returns an Err when the target file does not exist (or is otherwise inaccessible), and the unwrap() will panic in that case.

Impact: A missing file (e.g., client references a filename that was never uploaded, was deleted, or contains a path that doesn't resolve) crashes the request-handling thread. Depending on the async runtime/executor configuration, this can:

• Terminate only the single request (best case, if caught by a panic boundary), or
• Poison shared state / take down the worker if no panic isolation is in place.

Either way, it's an unhandled-error-as-crash pattern that should never be reachable from untrusted/external input.

Suggested fix: Replace .unwrap() with proper error propagation, e.g.:

let canonical = Path::new(&filename)
    .canonicalize()
    .map_err(|e| AppError::BadRequest(
        format!("invalid file path: {e}")
    ))?;

Return a 400/404 to the client instead of panicking. Add a test case covering a non-existent filename.

P2 — New PgPool created per request instead of reusing shared pool Location: src/db/pool.rs:29

Issue: A new PgPool is instantiated on every request rather than reusing a single, shared pool constructed once at startup.

Impact: Each PgPool::new(...) (or equivalent) opens its own set of connections to Postgres. Under load this:

• Rapidly exhausts available Postgres connections (hits max_connections on the DB server), causing connection errors for concurrent requests.
• Adds significant per-request latency from repeated connection/handshake overhead.
• Defeats the purpose of connection pooling entirely, since pools are not meant to be short-lived.

This is a correctness/scalability issue that will manifest as request failures and degraded throughput as concurrency increases, and could also affect other services sharing the same Postgres instance.

Suggested fix: Construct the PgPool once (e.g., in application startup / main.rs or a lazily-initialized static/OnceCell), then inject or pass a reference/clone (pools are typically Arc-backed and cheaply cloneable) into request handlers via app state (e.g., web::Data<PgPool> in Actix, State<PgPool> in Axum, etc.). Verify no other call sites have the same per-request instantiation pattern.

P1 — src/handlers/upload.rs:114: Path::new(&filename).canonicalize().unwrap() panics if the file doesn't exist, crashing the request thread. Fix: replace .unwrap() with proper error handling (e.g. .map_err(...)? returning a 4xx/5xx response) instead of panicking.

P2 — src/db/pool.rs:29: creates a new PgPool per request instead of reusing a shared pool, exhausting DB connections under load. Fix: construct the PgPool once at startup (e.g. in app state) and pass a reference/handle into each request instead of instantiating per-request.

Subject: inventory-sync — Status Update

Hi [Manager],

Quick update on inventory-sync:

• Kafka consumer rewrite is deployed to canary.
• Performance: canary pods show p99 latency at 340ms, well within our 500ms SLO.
• Issue: readiness probe on pod inventory-sync-7f9d8 is failing with connection refused on port 9090.
• Rollout status: paused before proceeding to the remaining 90% of pods, pending investigation of the probe failure.

Will update once we've root-caused the connection issue and are ready to resume the rollout.

Thanks, [Your name]

Status: inventory-sync

• Kafka consumer rewrite deployed to canary.
• Canary p99 latency: 340ms (within 500ms SLO).
• Blocker: readiness probe failing on pod inventory-sync-7f9d8 — connection refused on port 9090.
• Rollout to remaining 90% paused pending fix.

Diagnosis

Root cause: A context deadline budget mismatch — the 200ms timeout attached to the context in CreateOrderHandler is smaller than the actual latency required by the downstream work performed inside pricing.Calculate.

Specifically:

• CreateOrderHandler creates a context with a 200ms deadline (likely via context.WithTimeout(ctx, 200*time.Millisecond)) and passes that same context through the entire c