ahmido
c86b399b43
Some checks failed
Main Confidence / confidence (push) Failing after 53s
## Summary This PR delivers three related improvements: ### 1. Finding Ownership Semantics (Spec 219) - Add responsibility/accountability labels to findings and finding exceptions - `owner_user_id` = accountable party (governance owner) - `assignee_user_id` = responsible party (technical implementer) - Expose Assign/Reassign actions in FindingResource with audit logging - Add ownership columns and filters to finding list - Propagate owner from finding to exception on creation - Tests: ownership semantics, assignment audit, workflow actions ### 2. Constitution v2.7.0 — LEAN-001 Pre-Production Lean Doctrine - New principle forbidding legacy aliases, migration shims, dual-write logic, and compatibility fixtures in a pre-production codebase - AI-agent 4-question verification gate before adding any compatibility path - Review rule: compatibility shims without answering the gate questions = merge blocker - Exit condition: LEAN-001 expires at first production deployment - Spec template: added default "Compatibility posture" block - Agent instructions: added "Pre-production compatibility check" section ### 3. Backup Set Operation Type Unification - Unified `backup_set.add_policies` and `backup_set.remove_policies` into single canonical `backup_set.update` - Removed all legacy aliases, constants, and test fixtures - Added lifecycle coverage for `backup_set.update` in config - Updated all 14+ test files referencing legacy types ### Spec Artifacts - `specs/219-finding-ownership-semantics/` — full spec, plan, tasks, research, data model, contracts, checklist ### Tests - All affected tests pass (OperationCatalog, backup set, finding workflow, ownership semantics) Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #256
35 lines
1.3 KiB
Markdown
35 lines
1.3 KiB
Markdown
# Specification Quality Checklist: Finding Ownership Semantics Clarification
|
|
|
|
**Purpose**: Validate specification completeness and quality before proceeding to planning
|
|
**Created**: 2026-04-20
|
|
**Feature**: [spec.md](../spec.md)
|
|
|
|
## Content Quality
|
|
|
|
- [x] No implementation details (languages, frameworks, APIs)
|
|
- [x] Focused on user value and business needs
|
|
- [x] Written for non-technical stakeholders
|
|
- [x] All mandatory sections completed
|
|
|
|
## Requirement Completeness
|
|
|
|
- [x] No [NEEDS CLARIFICATION] markers remain
|
|
- [x] Requirements are testable and unambiguous
|
|
- [x] Success criteria are measurable
|
|
- [x] Success criteria are technology-agnostic (no implementation details)
|
|
- [x] All acceptance scenarios are defined
|
|
- [x] Edge cases are identified
|
|
- [x] Scope is clearly bounded
|
|
- [x] Dependencies and assumptions identified
|
|
|
|
## Feature Readiness
|
|
|
|
- [x] All functional requirements have clear acceptance criteria
|
|
- [x] User scenarios cover primary flows
|
|
- [x] Feature meets measurable outcomes defined in Success Criteria
|
|
- [x] No implementation details leak into specification
|
|
|
|
## Notes
|
|
|
|
- Validated against the existing findings domain contract: finding owner versus finding assignee versus exception owner.
|
|
- Scope remains intentionally narrow: no new queue model, capability split, persistence, or ownership framework was introduced. |