[TRACKER] Priority and dependency order for autonomous implementation

[jusso-dev]

Purpose

Single source of truth for implementation order across Kelpie backlog. Agents and maintainers use priority, milestone, and execution labels together:

• priority:p0: foundation, integrity, or critical operational workflow
• priority:p1: high-value analyst/product capability
• priority:p2: secondary/advanced capability
• execution:ready: no unresolved hard dependency blocks starting
• execution:blocked: do not start until dependencies below are closed

Milestones:

• Release 1 - Investigation foundation
• Release 2 - Analyst experience
• Release 3 - Organisational maturity

Overnight execution rules

1. Work only open issues carrying execution:ready.
2. Prefer P0 before P1; use P2 only when no higher-priority ready work is unclaimed.
3. Before starting, verify every hard dependency is closed and no active PR already claims the issue.
4. Use one issue per branch/PR. Link with Closes #<issue>.
5. Do not merge, deploy, mutate live data, rotate credentials, or execute provider response actions unattended.
6. Preserve unrelated work. Rebase onto current main before final validation.
7. Schema-changing PRs may be developed in parallel, but merge/rebase them serially. Regenerate migration order after earlier schema PRs land.
8. Run issue-proportionate unit, integration, type, lint, migration, tenant-isolation, and security tests. Report unavailable gates honestly.
9. Never weaken organisation isolation, approval, idempotency, redaction, TLP/PAP, or audit requirements to make a test pass.
10. When all hard dependencies close, replace execution:blocked with execution:ready before starting.

Tonight: ordered ready queue

P0 roots — claim first

1. Make Tawny a first-class inbound case source #50 — Tawny source provenance/idempotency contract
2. Restrict threat intelligence to IPs, URLs, file hashes, and domains #51 — strict TI indicator contract and migration
3. Harden evidence uploads with integrity, quarantine, and chain of custody #44 — evidence integrity/custody foundation
4. Add case relationships and duplicate investigation detection #43 — case relationship foundation
5. [P0] Build team queues, watchers, hand-offs, escalation policies and workload views #54 — team queue/ownership foundation

These can be investigated in parallel, but schema migrations must be rebased and merged serially.

Independent P1 lanes — use when P0 roots are already claimed

• Add an organisation audit explorer with export and retention controls #45 — append-only audit explorer
• Add ATT&CK technique mapping and investigation coverage #48 — ATT&CK mapping catalogue
• Expand the common-scenario playbook catalogue and publish a copyable LLM.txt agent prompt #52 — playbook catalogue and LLM.txt
• [P1] Add an automation and response-action run console with retry lineage #67 — automation/run observability console

Verification lane

• Add live case activity and analyst presence #49 — verify shipped realtime/presence behavior against remaining acceptance criteria; implement only confirmed gaps

Hard dependency graph

Release 1 — Investigation foundation

Issue	Hard start dependencies	Notes
#50 Tawny source	none	First source-provenance contract
#51 TI types	none	Finish before normalized migration assumptions
#43 Case relationships	none	Case-level relationship foundation
#44 Evidence custody	none	Binary evidence integrity foundation
#54 Team queues	none	Ownership/acknowledgement foundation
#55 Normalized investigation model	#50, #51	Provider/source and TI contracts must settle first
#56 Alert correlation/move/merge/split	#43, #55	Requires case relationships and first-class alerts
#57 Closure governance	#44, #54, #55	Requires evidence, ownership/approval, alerts/entities

Release 2 — Analyst experience

Issue	Hard start dependencies	Notes
#45 Audit explorer	none	Later features must emit compatible events
#48 ATT&CK mapping	none	Catalogue/mapping foundation
#49 Realtime/presence	none	Verification-first because much collaboration work is shipped
#52 Playbook catalogue/LLM.txt	none	Integrate ATT&CK coverage after #48
#67 Automation run console	none	Integrate organisation audit events after #45
#42 Inbound mailbox	#44, #55	Attachments/evidence plus normalized source records
#58 Investigation narrative	#55	Links blocks to alerts/entities/evidence
#59 Asset/identity context	#55	Requires canonical entity identifiers
#60 Integration health/sync	#50, #55	Requires source ownership and normalized provider records
#46 Saved/team views	#54, #59	Queue ownership and risk/context filters
#53 MCP onboarding	#52	Copies canonical agent prompt/catalogue guidance
#47 Controlled reports	#44, #48, #58	Compartment hardening follows with #61; do not block core report engine on Release 3

Release 3 — Organisational maturity

Issue	Hard start dependencies	Notes
#61 Sensitive compartments	#44, #45, #55, #58	Must cover evidence, audit, entities, narrative
#64 Post-incident review	#57, #58	Closure policy plus durable findings/decisions
#65 Investigation graph	#43, #48, #55, #61	Relationships, ATT&CK, normalized entities, access redaction
#62 Governed analyst console	#44, #55, #60, #61, #67	Evidence, entities, connectors, access, run observability
#63 Stakeholder portal	#44, #47, #61	Safe evidence, redacted reports, compartments
#66 Improvement register	#52, #61, #64	Playbooks, access controls, review outputs

Completion integrations that are not start gates

These links should be completed before affected feature sets are considered fully integrated, but they need not prevent safe foundation work:

• Expand the common-scenario playbook catalogue and publish a copyable LLM.txt agent prompt #52 uses Add ATT&CK technique mapping and investigation coverage #48 for ATT&CK coverage analysis.
• [P1] Add an automation and response-action run console with retry lineage #67 emits/searches Add an organisation audit explorer with export and retention controls #45 organisation audit events.
• Add live case activity and analyst presence #49 must apply [P1] Add field-level sensitivity, need-to-know access and case compartments #61 compartment authorization once compartments ship.
• Add reusable case report templates and controlled exports #47 adds [P1] Add field-level sensitivity, need-to-know access and case compartments #61 redaction/compartment enforcement and [P1] Add post-incident review, lessons learned and reusable knowledge workflows #64 post-incident variants when available.
• [P1] Add integration health, credential lifecycle and bidirectional source synchronisation #60 supplies health/sync diagnostics for Add secure inbound mailbox intake for creating cases #42, Make Tawny a first-class inbound case source #50, TI feeds, and later connectors.

Label promotion checklist

When considering a blocked issue:

• Every hard dependency above is closed.
• Dependency migrations are present on current main.
• No replacement or overlapping issue/PR exists.
• Acceptance criteria still match current code and product decisions.
• Remove execution:blocked.
• Add execution:ready.
• Claim issue before implementation.

Deliberate product boundaries

Do not expand these tickets into a visual SOAR canvas, arbitrary shell/Python/JavaScript execution, full SIEM/data lake, endpoint agent, vulnerability platform, generic ITSM, autonomous destructive response, or unrestricted AI tools.