mirror of
https://github.com/azaion/gps-denied-onboard.git
synced 2026-06-23 06:21:14 +00:00
Oleksandr Bezdieniezhnykh
1f634c2604
ci/woodpecker/push/02-build-push Pipeline failed
- Modified the autodev state to reflect the current testing phase and details of the new `jetson-e2e` tests. - Enhanced the "How to Test" documentation to provide clearer instructions on the demo replay validation process, including video and tlog alignment steps. - Updated architectural documentation to include the new demo replay operator flow and its dependencies. - Documented the removal of deprecated auto-sync features and clarified the operator-facing UI for replay validation. - Added new entries in the dependencies table for upcoming tasks related to the demo replay flow. These changes improve clarity and usability for operators and developers working with the demo replay system.
57 lines
2.1 KiB
Markdown
57 lines
2.1 KiB
Markdown
# Usage Examples — Reference
|
|
|
|
## Example 1: Initial Research (Mode A)
|
|
|
|
```
|
|
User: Research this problem and find the best solution
|
|
```
|
|
|
|
Execution flow:
|
|
1. Context resolution: no explicit file -> project mode (INPUT_DIR=`_docs/00_problem/`, OUTPUT_DIR=`_docs/01_solution/`)
|
|
2. Guardrails: verify INPUT_DIR exists with required files
|
|
3. Mode detection: no `solution_draft*.md` -> Mode A
|
|
4. Phase 1: Assess acceptance criteria and restrictions, ask user about unclear parts
|
|
5. BLOCKING: present AC assessment, wait for user confirmation
|
|
6. Phase 2: Full 8-step research — competitors, components, state-of-the-art solutions
|
|
7. Output: `OUTPUT_DIR/solution_draft01.md`
|
|
8. (Optional) Phase 3: Tech stack consolidation -> `tech_stack.md`
|
|
9. (Optional) Phase 4: Security deep dive -> `security_analysis.md`
|
|
|
|
## Example 2: Solution Assessment (Mode B)
|
|
|
|
```
|
|
User: Assess the current solution draft
|
|
```
|
|
|
|
Execution flow:
|
|
1. Context resolution: no explicit file -> project mode
|
|
2. Guardrails: verify INPUT_DIR exists
|
|
3. Mode detection: `solution_draft03.md` found in OUTPUT_DIR -> Mode B, read it as input
|
|
4. Full 8-step research — weak points, security, performance, solutions
|
|
5. Output: `OUTPUT_DIR/solution_draft04.md` with findings table + revised draft
|
|
|
|
## Example 3: Standalone Research
|
|
|
|
```
|
|
User: /research @my_problem.md
|
|
```
|
|
|
|
Execution flow:
|
|
1. Context resolution: explicit file -> standalone mode (INPUT_FILE=`my_problem.md`, OUTPUT_DIR=`_standalone/my_problem/01_solution/`)
|
|
2. Guardrails: verify INPUT_FILE exists and is non-empty, warn about missing restrictions/AC
|
|
3. Mode detection + full research flow as in Example 1, scoped to standalone paths
|
|
4. Output: `_standalone/my_problem/01_solution/solution_draft01.md`
|
|
5. Move `my_problem.md` into `_standalone/my_problem/`
|
|
|
|
## Example 4: Force Initial Research (Override)
|
|
|
|
```
|
|
User: Research from scratch, ignore existing drafts
|
|
```
|
|
|
|
Execution flow:
|
|
1. Context resolution: no explicit file -> project mode
|
|
2. Mode detection: drafts exist, but user explicitly requested initial research -> Mode A
|
|
3. Phase 1 + Phase 2 as in Example 1
|
|
4. Output: `OUTPUT_DIR/solution_draft##.md` (incremented from highest existing)
|