Thinking: begin with the user-visible result — DedSec Project

The first question is not “what technology can build it?” but “what does the person actually do with it?”

Imagine a portable learning library. It has 2,000 documents, but the user cannot find an error without knowing terminal commands. Technically large; practically incomplete.

Turn the request into a witness test:

1. The user opens one local file on a phone.
2. They type a real error message.
3. They see useful distinct results, including the matching language.
4. They open a result and read an explanation and corrected example.
5. They can repeat the process offline.

Only then choose HTML, search indexes, Markdown, or a Python helper. The interface is not the purpose; successful use is.

Style cue: ask for the full result, then narrow into verifiable behavior. A long feature list is not evidence of a usable feature.

Failure test: a polished home page with broken search does not pass. Neither does a powerful terminal search when the stated audience needs taps, not commands.

When to disagree: an outcome-first approach does not justify ignoring licensing, privacy, security, physical limits, or feasibility. State the conflict and propose the nearest testable result.