db73cf5a39
Includes the current working directory changes. Historical commits and release binaries are excluded to limit Gitea storage. Source base: d7515973fbfd6dd2001fa156c483455b8081c7cb
32 lines
3.1 KiB
Markdown
32 lines
3.1 KiB
Markdown
# Research
|
|
|
|
For /FD-research or targeted investigation in another stage. Apply the core scope, language, authorization, and protocol workflow rules.
|
|
|
|
## Locate the task
|
|
|
|
Accept an idea, symptom, requirement, file reference, or existing task. If no goal can be inferred, ask which problem to investigate. Search relevant entry points instead of reading the entire project.
|
|
|
|
## Investigate
|
|
|
|
1. Read relevant task records, documents, and conventions. Trace entry points, calls, data flow, dependencies, and constraints.
|
|
2. Search for reusable modules, standard-library capabilities, installed dependencies, and suitable established solutions.
|
|
3. For defects, record the expected/actual behavior, trigger, and a reproducible case when feasible. Separate observed symptoms from candidate causes; use relevant logs/call paths to support or disprove the cause, and retain uncertainty when reproduction or evidence is unavailable. Existing diagnostics may run if they do not edit business code/configuration; check authorization before real-service or data-changing operations.
|
|
4. Separate facts, inference, preferences, assumptions, and unknowns. Attach file/symbol locations, real command results, or sources.
|
|
5. Check whether goals, scope, acceptance behavior, and consequential tradeoffs are clear. Investigate facts yourself; use [grill.md](grill.md) for unresolved intent or choices.
|
|
|
|
## Resolve a potentially invalidating assumption
|
|
|
|
When an uncertain API, platform capability, file format, or packaging constraint could invalidate the approach, propose or perform a bounded isolated experiment within existing authorization. State the one question, representative input/environment, observable success/failure, and stopping condition. Use available resources or an explicitly approved disposable environment; do not change business code, project dependencies/configuration, user data, or real services to investigate. Seek approval for scope/capability expansion.
|
|
|
|
Record what the experiment actually establishes and its limits. Experimental code is not automatically production code, a new dependency choice, or proof for other environments. Do not require an experiment for ordinary settled work.
|
|
|
|
Recommendations and tradeoffs are allowed to help the user decide; they are not implementation approval.
|
|
|
|
## Output and stop
|
|
|
|
In Chinese, summarize current behavior and evidence, goals/scope, reuse, observable acceptance scenarios, decisions, and remaining unknowns with impact.
|
|
|
|
Stop when the facts needed for planning are supported and intent is sufficiently clear. Preserve unknowns and propose validation instead of inventing business rules.
|
|
|
|
For complex work follow [task-record.md](task-record.md). Maintain records only when permissions allow; otherwise retain conclusions in the conversation. End with the next planning step rather than automatically implementing. When findings point to a definite next stage (interface design, planning, implementation, review), name the matching FD command in the closing suggestion; if the user agrees in this same session, continue by that stage reference directly — including its protocol stage and approval rules — instead of requiring manual command input.
|