Scope: medium Risk: low Spec: aligned Type: feature
Summary: Implements priority-based SLA target configuration (response/resolution time targets per priority tier) with a rules engine to auto-compute SLA due dates on ticket create/update, plus API endpoints and management UI.
Suggestion: Build in order: (1) SLAPolicy model (priority→response_hours, resolve_hours, business_hours flag) + Alembic migration, (2) SLA policy CRUD in crud/sla_policy.py, (3) API router at /api/v1/sla-policies (admin-only), (4) Extend services/sla.py with a compute_sla_due_dates(ticket_priority) function using configured targets, (5) Wire SLA computation into ticket create/update CRUD, (6) Frontend SLA policy management page (list + inline-edit targets per priority), (7) Tests: SLA policy CRUD, rules engine, and integration with ticket creation.
Rationale: SCOPE=medium: ~10-14 new/modified files — new model+migration, CRUD, API router, enhanced SLA service, frontend page, tests. Not small because it needs a new DB table and integration point in ticket CRUD; not large because no architectural changes. RISK=low: additive only — the Ticket model's sla_response_due/sla_resolve_due columns already exist, the sla.py service is standalone breach-checking, and the auto-compute hook in ticket CRUD is a one-liner that degrades gracefully if no policy is configured. SPEC=aligned: directly implements Phase 1.5 'SLA Management Enhancements' from ROADMAP.md — 'SLA policy configuration - Response time targets by priority, Resolution time targets, SLA rules engine'.

Action: Review each blocking factor above. Remove blocked:needs-decision label to route back to triage.

## ⏸ Needs Decision **Blocking factors:** - **Didn't meet auto-approve criteria** — scope=medium, risk=low, spec=aligned --- **Scope:** medium **Risk:** low **Spec:** aligned **Type:** feature **Summary:** Implements priority-based SLA target configuration (response/resolution time targets per priority tier) with a rules engine to auto-compute SLA due dates on ticket create/update, plus API endpoints and management UI. **Suggestion:** Build in order: (1) SLAPolicy model (priority→response_hours, resolve_hours, business_hours flag) + Alembic migration, (2) SLA policy CRUD in crud/sla_policy.py, (3) API router at /api/v1/sla-policies (admin-only), (4) Extend services/sla.py with a compute_sla_due_dates(ticket_priority) function using configured targets, (5) Wire SLA computation into ticket create/update CRUD, (6) Frontend SLA policy management page (list + inline-edit targets per priority), (7) Tests: SLA policy CRUD, rules engine, and integration with ticket creation. **Rationale:** SCOPE=medium: ~10-14 new/modified files — new model+migration, CRUD, API router, enhanced SLA service, frontend page, tests. Not small because it needs a new DB table and integration point in ticket CRUD; not large because no architectural changes. RISK=low: additive only — the Ticket model's sla_response_due/sla_resolve_due columns already exist, the sla.py service is standalone breach-checking, and the auto-compute hook in ticket CRUD is a one-liner that degrades gracefully if no policy is configured. SPEC=aligned: directly implements Phase 1.5 'SLA Management Enhancements' from ROADMAP.md — 'SLA policy configuration - Response time targets by priority, Resolution time targets, SLA rules engine'. **Action:** Review each blocking factor above. Remove `blocked:needs-decision` label to route back to triage.

Mark commented

2026-05-28 07:51:11 +00:00

Author

Owner

⏸ Needs Decision

What needs to be decided?

Should the spec be adjusted or is this still worth doing? If yes, remove the blocked:needs-decision label and the triage will approve it.

Blocking factors:

Spec misaligned — doesn't align with project direction

Scope: small Risk: low Spec: misaligned Type: other
Summary: This issue is a decomposition artifact — it represents the Priority section header (🟡 MEDIUM) from parent issue #10's body, not an actionable implementation task.
Suggestion: Close as not actionable. This is a metadata section that got split into its own sub-issue during decomposition. The actual priority-related implementation work (response time targets by priority, priority-based SLA assignment) is already scoped under Phase 4 (SLA Policy Configuration, #35) and Phase 5 (SLA Rules Engine, #36). If there IS intended priority-specific implementation beyond those phases, it needs a proper spec body describing what's required.
Rationale: The 12 Phase issues (#32-#43) map 1:1 to sections of parent issue #10's body — Overview, Current State, Required Implementation, then the 5 implementation buckets, then the 4 trailing metadata sections (Acceptance Criteria, Related Documents, Priority, Effort Estimate). Issue #42's body is just '🟡 MEDIUM', which is the priority label from the parent, not a spec. Phases 4 and 5 already own the priority-based SLA policy configuration and rules engine work.

To unblock: Remove the blocked:needs-decision label. The triage will apply the appropriate outcome based on your choice above.

## ⏸ Needs Decision **What needs to be decided?** - **Should the spec be adjusted or is this still worth doing?** If yes, remove the `blocked:needs-decision` label and the triage will approve it. **Blocking factors:** - **Spec misaligned** — doesn't align with project direction --- **Scope:** small **Risk:** low **Spec:** misaligned **Type:** other **Summary:** This issue is a decomposition artifact — it represents the Priority section header (🟡 MEDIUM) from parent issue #10's body, not an actionable implementation task. **Suggestion:** Close as not actionable. This is a metadata section that got split into its own sub-issue during decomposition. The actual priority-related implementation work (response time targets by priority, priority-based SLA assignment) is already scoped under Phase 4 (SLA Policy Configuration, #35) and Phase 5 (SLA Rules Engine, #36). If there IS intended priority-specific implementation beyond those phases, it needs a proper spec body describing what's required. **Rationale:** The 12 Phase issues (#32-#43) map 1:1 to sections of parent issue #10's body — Overview, Current State, Required Implementation, then the 5 implementation buckets, then the 4 trailing metadata sections (Acceptance Criteria, Related Documents, Priority, Effort Estimate). Issue #42's body is just '🟡 MEDIUM', which is the priority label from the parent, not a spec. Phases 4 and 5 already own the priority-based SLA policy configuration and rules engine work. **To unblock:** Remove the `blocked:needs-decision` label. The triage will apply the appropriate outcome based on your choice above.

Mark

2026-07-27 16:47:01 +00:00