Skip to content

CLI: error diagnostics chain (grounded error codes to structured errors) #54

Description

@mobileskyfi

Question

What are the top 3-5 real error codes users actually hit, and what diagnostics/hints should each carry?

This is a placeholder for adapting the very established tikoci/centrs scheme for aligning errors, help text, hints, and diagnostics. Do not invent a new quickchr-only pattern without checking centrs first.

This is not a CI issue. CI may expose failure modes, but the design work is the error/help/diagnostic contract.

Hypothesis

A handful of failure modes dominate: boot, REST-not-ready, port collision, auth, acceleration, and missing host dependencies. Confirm by inducing them, not by assuming.

Repro plan

Induce the top error codes locally -> test/lab/errors/REPORT.md. Then design a structured { code, message, hint, diagnostics } error shape that maps cleanly onto user-facing help and remediation. After that, file a P4 follow-up for centralizing the error-message/logging surface if it is still needed.

Done-when

test/lab/errors/REPORT.md documents the induced codes; a structured-error design is agreed and aligned with the centrs-style scheme; any message/logging centralization is filed as a follow-up Task.

Feeds wizard remediation and doctor: the induced codes are the keys those issues map "why / try-this" text onto.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3research / investigation — needs grounding firstarea:cliCLI commands and UXresearchproduces a repro / REPORT.md / grounding doc

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions