0eb709aaf0
- Reorganize cursor rules into logical directories (app/, docs/, features/, etc.) - Move project.mdc to app/ directory for better organization - Enhance documentation.mdc with base_context.mdc principles and markdown standards - Improve time.mdc with comprehensive time handling guidelines - Remove outdated/unused rule files (general_development, logging, progress_reports, version_control, versioning) - Establish new documentation standards emphasizing human competence and collaboration - Ensure all documentation follows markdown.mdc linting rules This restructuring improves rule discoverability and establishes consistent documentation standards across the project while maintaining the human competence first approach.
136 lines
3.8 KiB
Plaintext
136 lines
3.8 KiB
Plaintext
---
|
||
description: Use this workflow when doing **pre-implementation research, defect investigations with uncertain repros, or clarifying system architecture and behaviors**.
|
||
alwaysApply: false
|
||
---
|
||
```json
|
||
{
|
||
"coaching_level": "light",
|
||
"socratic_max_questions": 2,
|
||
"verbosity": "concise",
|
||
"timebox_minutes": null,
|
||
"format_enforcement": "strict"
|
||
}
|
||
```
|
||
|
||
# Research & Diagnostic Workflow (R&D)
|
||
|
||
## Purpose
|
||
|
||
Provide a **repeatable, evidence-first** workflow to investigate features and
|
||
defects **before coding**. Outputs are concise reports, hypotheses, and next
|
||
steps—**not** code changes.
|
||
|
||
## When to Use
|
||
|
||
- Pre-implementation research for new features
|
||
- Defect investigations (repros uncertain, user-specific failures)
|
||
- Architecture/behavior clarifications (e.g., auth flows, merges, migrations)
|
||
|
||
---
|
||
|
||
## Output Contract (strict)
|
||
|
||
1) **Objective** — 1–2 lines
|
||
2) **System Map (if helpful)** — short diagram or bullet flow (≤8 bullets)
|
||
3) **Findings (Evidence-linked)** — bullets; each with file/function refs
|
||
4) **Hypotheses & Failure Modes** — short list, each testable
|
||
5) **Corrections** — explicit deltas from earlier assumptions (if any)
|
||
6) **Diagnostics** — what to check next (logs, DB, env, repro steps)
|
||
7) **Risks & Scope** — what could break; affected components
|
||
8) **Decision/Next Steps** — what we’ll do, who’s involved, by when
|
||
9) **References** — code paths, ADRs, docs
|
||
10) **Competence & Collaboration Hooks** — brief, skimmable
|
||
|
||
> Keep total length lean. Prefer links and bullets over prose.
|
||
|
||
---
|
||
|
||
## Quickstart Template
|
||
|
||
Copy/paste and fill:
|
||
|
||
```md
|
||
# Investigation — <short title>
|
||
|
||
## Objective
|
||
<one or two lines>
|
||
|
||
## System Map
|
||
- <module> → <function> → <downstream>
|
||
- <data path> → <db table> → <api>
|
||
|
||
## Findings (Evidence)
|
||
- <claim> — evidence: `src/path/file.ts:function` (lines X–Y); log snippet/trace id
|
||
- <claim> — evidence: `...`
|
||
|
||
## Hypotheses & Failure Modes
|
||
- H1: <hypothesis>; would fail when <condition>
|
||
- H2: <hypothesis>; watch for <signal>
|
||
|
||
## Corrections
|
||
- Updated: <old statement> → <new statement with evidence>
|
||
|
||
## Diagnostics (Next Checks)
|
||
- [ ] Repro on <platform/version>
|
||
- [ ] Inspect <table/store> for <record>
|
||
- [ ] Capture <log/trace>
|
||
|
||
## Risks & Scope
|
||
- Impacted: <areas/components>; Data: <tables/keys>; Users: <segments>
|
||
|
||
## Decision / Next Steps
|
||
- Owner: <name>; By: <date> (YYYY-MM-DD)
|
||
- Action: <spike/bugfix/ADR>; Exit criteria: <binary checks>
|
||
|
||
## References
|
||
- `src/...`
|
||
- ADR: `docs/adr/xxxx-yy-zz-something.md`
|
||
- Design: `docs/...`
|
||
|
||
## Competence Hooks
|
||
- Why this works: <≤3 bullets>
|
||
- Common pitfalls: <≤3 bullets>
|
||
- Next skill: <≤1 item>
|
||
- Teach-back: "<one question>"
|
||
```
|
||
|
||
---
|
||
|
||
## Evidence Quality Bar
|
||
|
||
- **Cite the source** (file:func, line range if possible).
|
||
- **Prefer primary evidence** (code, logs) over inference.
|
||
- **Disambiguate platform** (Web/Capacitor/Electron) and **state** (migration, auth).
|
||
- **Note uncertainty** explicitly.
|
||
|
||
---
|
||
|
||
## Collaboration Hooks
|
||
|
||
- **Syncs:** 10–15m with QA/Security/Platform owners for high-risk areas.
|
||
- **ADR:** Record major decisions; link here.
|
||
- **Review:** Share repro + diagnostics checklist in PR/issue.
|
||
|
||
---
|
||
|
||
## Self-Check (model, before responding)
|
||
|
||
- [ ] Output matches the **Output Contract** sections.
|
||
- [ ] Each claim has **evidence** or **uncertainty** is flagged.
|
||
- [ ] Hypotheses are testable; diagnostics are actionable.
|
||
- [ ] Competence + collaboration hooks present (≤120 words total).
|
||
- [ ] Respect toggles; keep it concise.
|
||
|
||
---
|
||
|
||
## Optional Globs (examples)
|
||
|
||
> Uncomment `globs` in the header if you want auto-attach behavior.
|
||
|
||
- `src/platforms/**`, `src/services/**` — attach during service/feature investigations
|
||
- `docs/adr/**` — attach when editing ADRs
|
||
|
||
## Referenced Files
|
||
|
||
- Consider including templates as context: `@adr_template.md`, `@investigation_report_example.md`
|