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 |
||
|---|---|---|
| .. | ||
| memory | ||
| scripts/bash | ||
| templates | ||
| plan.md | ||
| README.md | ||
| research_t186.md | ||
| spec.md | ||
| tasks.md | ||
.specify/ (Tooling)
This folder contains SpecKit tooling (templates, scripts, constitution, etc.).
Important
- Do not create new feature specs in
.specify/spec.md,.specify/plan.md,.specify/tasks.md. - Active feature specs live under
specs/<NNN>-<slug>/:spec.mdplan.mdtasks.mdchecklists/requirements.md
- Runtime-changing or test-affecting work MUST carry actual test-purpose classification (
Unit,Feature,Heavy-Governance,Browser), affected lanes, fixture/default cost risks, heavy-family changes, escalation decisions, and minimal validation commands through the activespec.md,plan.md, andtasks.md. - Review-oriented checklists MUST surface nativity, shared-family boundaries, state-layer ownership, exception spread, proof depth, and close-out targeting before merge.
.specify/is the operational workflow.docs/ui/operator-ux-surface-standards.mdremains a rule/reference document, not a second checklist or review process.
Author Entry Point
Use the active feature's spec.md, plan.md, and tasks.md in that order.
- Fill the spec's UI / Surface Guardrail Impact section once. If there is no operator-facing surface change, write a concise
N/Aand do not invent extra prose downstream. - Turn that classification into plan-level handling modes, repository-signal treatment, required proof depth, and the named active feature PR close-out entry.
- Carry the same terms into tasks so implementation, review, definition-of-done, exception documentation, and smoke coverage all point at the same guardrail decision.
Review Entry Point
Use the active feature's spec.md, plan.md, and tasks.md together with the generated checklist based on .specify/templates/checklist-template.md.
- Confirm the spec names the guardrail impact once: native/custom classification, shared-family relevance, state-layer ownership, exception need, and any low-impact
N/Apath. - Confirm the plan turns that into handling modes, repository-signal treatment, required test or smoke depth, and the named active feature PR close-out entry.
- Apply the checklist and end with both one review outcome class (
blocker,strong-warning,documentation-required-exception, oracceptable-special-case) and one workflow outcome (keep,split,document-in-feature,follow-up-spec, orreject-or-split). - If a guarded surface or exception remains in scope, ensure the active feature PR close-out entry records the final note rather than leaving the decision in scattered review comments.
Low-Impact Rule
- Docs-only or template-only work may answer
N/Aornone. - Do not force fake surface, lane, or exception prose when no operator-facing change or runtime impact exists.
- Use the low-impact path to stay fast, not to hide a real guarded surface change.
Escalation Rule
- Use
blockerwhen fake-native drift, hidden host drift, unresolved state ownership, or missing exception boundaries remain. - Use
strong-warningwhen the change can proceed only after the active workflow records the guardrail risk explicitly. - Use
documentation-required-exceptionwhen default rules are intentionally relaxed and the bounded exception record is the remaining requirement. - Use
acceptable-special-caseonly when the change already fits the declared guardrail contract. - Use
document-in-featurefor contained cost or drift that belongs in the active feature. - Use
follow-up-speconly for recurring pain or structural lane or family changes. - Use
reject-or-splitwhen hidden test cost or wrong-lane scope is still unresolved.
Close-Out Rule
- The named close-out target for guarded work is the active feature PR close-out entry
Guardrail / Exception / Smoke Coverage. - That entry records the low-impact or representative scenario used, the outcome class, handling mode, workflow outcome, required tests or manual smoke, any exception boundary, duplicate-prompt notes, and any deferred automation.
- If the change is genuinely low-impact, record a concise
N/Anote rather than fabricating guardrail spread.
The files .specify/spec.md, .specify/plan.md, .specify/tasks.md may exist as legacy references only.