User feedback after a transitionJiraIssue call returned a bare
{"success": true} that I trusted blindly: the rule should require
explicit verification and stop-and-ask on any ambiguous response.
Two targeted clarifications:
- .cursor/rules/tracker.mdc - Tracker Availability Gate now lists
the full set of failure modes (non-2xx, timeout, empty body,
opaque success) and bans automatic retries. Adds an explicit
read-back requirement when the response is minimal, and adds
"abort" to the user-choice menu.
- .cursor/skills/implement/SKILL.md - Step 5 (In Progress) and
Step 12 (In Testing) now spell out the STOP-and-ASK rule inline
instead of just pointing at tracker.mdc. Adds the read-back
verification step for opaque responses.
Co-authored-by: Cursor <cursoragent@cursor.com>
Root cause: I ran the full unit suite at the end of every autodev
batch despite implement/SKILL.md already saying that is forbidden
(lines 33, 136, 145, 372). The skill's existing rules were buried
mid-document; coderule.mdc's general "run full suite when done"
overrode them in practice because each batch felt like a "done"
point.
Two targeted clarifications:
- .cursor/rules/coderule.mdc: add an Iterative-Skill Exception
bullet stating that when an iterative loop skill (autodev /
implement batch loop, refactor batch loop) is active, the
skill governs full-suite cadence and "done with changes"
means done with the implementation phase, not done with one
batch.
- .cursor/skills/implement/SKILL.md: hoist the per-batch / per-
task / Step-16 cadence rule into a top-of-file "READ FIRST,
EVERY BATCH" banner with an explicit anti-pattern check ("if
you catch yourself about to run pytest tests/ at end of batch,
STOP").
Co-authored-by: Cursor <cursoragent@cursor.com>
Transitioned the autodev state to phase 21, reflecting the completion of Step 5 and the drafting of Step 6 epics. Revised the architecture documentation to clarify the roles of the Tile Manager and its components, ensuring accurate representation of the system's operational flow. Updated glossary entries for Flight State and Operator to incorporate recent changes and enhance clarity on component interactions and responsibilities.
Enhanced the SKILL.md file to enforce conciseness rules for the state file, specifying acceptable content and file size limits. Updated the autodev state to reflect the transition to the planning phase, including changes to the current step and sub-step details. Revised acceptance criteria to clarify validation requirements and external dependencies, ensuring alignment with the latest research findings. Added a new overlay for Mode B revisions to track changes and decisions made during the assessment process.
Updated various documentation files to clarify the handling of splittable artifacts, allowing for folder equivalents of key markdown files when they exceed size limits. Adjusted references in multiple sections to reflect this new structure, ensuring consistency across the research methodology. Enhanced clarity on the saving actions and artifact organization, particularly for `01_source_registry.md`, `02_fact_cards.md`, and `06_component_fit_matrix.md`. This change aims to improve usability and maintainability of the research documentation.
Updated the meta-rule document to emphasize strict adherence to skill instructions, prohibiting unnecessary investigations or external checks. Revised acceptance criteria and restrictions to correct communication protocol details for ArduPilot and iNav, ensuring clarity on external-positioning interfaces. Adjusted autodev state to reflect ongoing research phase and updated sub-step details for improved tracking.
acceptance_criteria.md and restrictions.md were carrying internal
component selections (DINOv2/SuperPoint/FAISS/ESKF), library pins
(pymavlink/MAVSDK), autopilot parameter values (GPS1_TYPE=14,
EK3_SRC1_*, VISO_QUAL_MIN), and v1/v1.1 phasing tied to specific
ArduPilot PR numbers. Per IEEE 830 / Atlassian / GitScrum,
acceptance criteria must be design-independent — outcomes only,
not implementation. Cleaned both files (-35% combined size) while
preserving every testable threshold and contract bullet.
Output-schema label renamed: vo_extrapolated -> visual_propagated.
FC scope broadened from ArduPilot-only to ArduPilot + iNav (both
via standard MAVLink external-positioning interfaces).
Encoded the lesson into the two skills that write/refine AC:
- problem/SKILL.md (initial AC production)
- research/steps/01_mode-a-initial-research.md (Phase 1 AC
& Restrictions Assessment)
Autodev state reset to greenfield Step 2 (Research) for the
post-restart greenfield run; cycle 1, in-progress at sub-step
ac-restrictions-assessment.
Co-authored-by: Cursor <cursoragent@cursor.com>
- Modified the Docker Compose configuration to include an input root for replay tests and added an environment variable for enabling SITL.
- Enhanced documentation for various testing processes, including the addition of a Runtime Completeness Decomposition Gate and clarifications on internal module testing requirements.
- Updated the implementation completeness report to reflect the current state and added new test cases for performance and resilience scenarios.
Co-authored-by: Cursor <cursoragent@cursor.com>
- Refined task decomposition steps to ensure implementation tasks are atomic and complexity does not exceed 5 points.
- Enhanced the product implementation process with a completeness gate to verify task outcomes against architecture promises before proceeding to testing.
- Updated dependencies table to reflect new tasks and their relationships, ensuring all test tasks are linked to product remediation tasks.
- Adjusted workflow documentation to clarify entry points for task decomposition and implementation contexts.
Co-authored-by: Cursor <cursoragent@cursor.com>
Oleksandr Bezdieniezhnykh