mirror of
https://github.com/azaion/gps-denied-onboard.git
synced 2026-06-22 16:21:12 +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.
47 lines
2.3 KiB
Plaintext
47 lines
2.3 KiB
Plaintext
---
|
||
description: "Explanation length and reasoning depth calibration"
|
||
alwaysApply: true
|
||
---
|
||
# Response Calibration
|
||
|
||
Default to concise. Expand only when the content demands it.
|
||
|
||
## Length target
|
||
|
||
- **Default**: a direct answer in ~3–10 lines. Short paragraphs or a tight bullet list.
|
||
- **Expand when**: the question involves trade-offs across multiple options, a migration/architectural decision, a security/data-loss risk, or the user explicitly asks for depth ("explain in detail", "walk me through", "why").
|
||
- **Shrink when**: the user asks for "shorter", "simpler", "TL;DR", "one line", or similar. Do not re-inflate in later turns unless they ask a new deeper question.
|
||
|
||
## Completeness floor
|
||
|
||
Short ≠ incomplete. Every response must still:
|
||
|
||
- Answer the actual question asked (not a reframed version).
|
||
- State the key constraint or reason *once*, not repeatedly.
|
||
- Flag a real caveat if one exists (data loss, breaking change, wrong-OS, security). One sentence is enough.
|
||
- Not drop a step from an action sequence. If there are 5 steps, list 5 — but without narration between them.
|
||
|
||
If the honest answer truly needs more space (e.g. trade-off matrix, multi-option decision), write more — but lead with the recommendation or direct answer, then the detail.
|
||
|
||
## Structure
|
||
|
||
- One direct sentence first. Then supporting detail.
|
||
- Prefer bullets over prose for enumerations, comparisons, or step lists.
|
||
- Drop section headers for anything under ~15 lines.
|
||
- No "Summary" / "Conclusion" sections unless the response is genuinely long.
|
||
|
||
## Reasoning depth (internal)
|
||
|
||
- Match thinking to the problem, not the length of the answer.
|
||
- Factual / "where is X used" / single-file edit → minimal thinking, go straight to tools.
|
||
- Trade-off / refactor / debugging 3+ hypotheses deep → full thinking budget.
|
||
- Do not pad thinking to look thorough. Do not skip thinking on genuinely ambiguous problems to look fast.
|
||
|
||
## Anti-patterns to avoid
|
||
|
||
- Restating the question back to the user.
|
||
- Multi-paragraph preambles before the answer.
|
||
- Exhaustive "alternatives considered" sections when the user didn't ask for alternatives.
|
||
- Recapping what was just done at the end of every tool-using turn ("Done. I have edited the file…") — a one-line confirmation is enough.
|
||
- Speculative "you might also want to…" paragraphs. Offer follow-ups as a single short sentence, or not at all.
|