Design local command history and explanation surfaces

[codeforester]

Summary

Design the next observability layer after basectl logs: local command history, last-error explanation, and report surfaces.

The product vision draft listed possible future commands such as basectl history, basectl explain last-error, and basectl report. basectl logs exists today, but the broader observability intent is not yet tracked.

Scope

This issue is design-first. Decide whether Base should add one or more commands such as:

basectl history
basectl explain last-error
basectl report

The design should define what metadata is recorded, where it lives, retention behavior, privacy boundaries, and how the output differs from raw logs.

Design Questions

1. Is basectl logs enough, or does Base need a structured command history index?
2. What metadata should be recorded: command, project/workspace, start/end time, exit code, manifest version, external tools, log path?
3. Should explain last-error summarize existing logs or require structured failure records?
4. What does report include, and is it meant for humans, support, CI, or bug reports?
5. How should sensitive arguments and paths be redacted?
6. How does this interact with basectl clean retention?

Non-Goals

• No hosted telemetry.
• No automatic upload of local logs or reports.
• No implementation until the command shape and data model are reviewed.

Acceptance Criteria

• A design doc or existing doc section defines the observability model beyond raw logs.
• The design explicitly keeps data local by default.
• Follow-up implementation issues are split only if the commands should ship separately.

Source Design Intent

Curated from the local product vision draft during #392.