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>
- Revised acceptance criteria in the acceptance_criteria.md file to clarify metrics and expectations, including updates to GPS accuracy and image processing quality.
- Enhanced restrictions documentation to reflect operational parameters and constraints for UAV flights, including camera specifications and satellite imagery usage.
- Added new research documents for acceptance criteria assessment and question decomposition to support ongoing project evaluation and decision-making.
Oleksandr Bezdieniezhnykh