CyberCLI

← Engine reference · Backlog

The engine backlog.
Written down. Publicly.

Every "known limit" from the 27 engine deep docs, flattened into one view. The point: we ship the punch-list publicly so you can see exactly what's slated for v1.x vs v1.5 vs the upstream Vector roadmap. 29 items across 5 release tracks and 7 themes.

v1.1
1
Slated for the next minor release. The v1.5 federation engin…
v1.x
17
Slated for a v1.x point release. Operator-quality wins + sca…
v1.5
9
Slated for the v1.5 federation release. The Sovereign multi-…
Enterprise
1
Slated for the Enterprise tier. Compliance + sovereignty-gra…
Vector upstream
1
Slated to land when Vector ships the underlying support. Not…

v1.1

1 item

Slated for the next minor release. The v1.5 federation engine + the multi-role orchestrator are the load-bearing items here.

Multi-role orchestrator firing Knight + Marshal + Paladin per event.

Only Warden fires the digest in v1. The provider map is wired for all 5 runtime roles; the orchestrator that hands work to each is the unlock.

v1.x

17 items

Slated for a v1.x point release. Operator-quality wins + scale headroom + observability cleanups.

Dashboard slider that calls compute_recommendations and renders the promotion nudge.

compute_recommendations() Python API shipped 2026-06-07 — walks the audit log and returns promotion candidates with rationale. The remaining piece is the /trust-ladder UI surface that calls it on every dial render + an operator confirm flow that writes the new level back through the existing set_level() path.

L6 vs L5 differentiation via batched-delivery scheduler.

Today L6 dispatches identically to L5. The intended L6 semantic is 'autonomous + batched digest' which lands when the batched-delivery scheduler ships.

Unified work-queue / fan-out across multiple consumer processes.

High-event-rate installs run multiple consumers and rely on the per-connector cursor + audit idempotency_key for cross-consumer dedupe. A first-class fan-out model is the higher-throughput design.

IngestPipeline Performance

Automatic dedupe-ledger compaction on a scheduled cadence (in-CLI verb already ships).

`cybercli system dedupe-compact --max-age-days <n>` + DedupeIndex.compact() shipped 2026-06-07. The scheduler that fires this on a cadence (e.g. weekly) is the remaining half.

Vendor-shipped baseline rule packs (inactive by default).

Operator-authored rules only today. Shipping curated 'common nginx crawler noise' / 'common ssh brute prefiltering' packs the operator activates one at a time accelerates new installs past the 'tune for a week' phase.

File-watcher that calls replace_role_providers on config.toml mtime change.

DigestPipeline.replace_role_providers() API shipped 2026-06-07 — atomic, thread-safe, returns the previous map. The remaining piece is the watcher that polls config.toml mtime + calls _resolve_per_role_providers + hands the result to replace_role_providers(). Then the dashboard Save flow doesn't need to prompt for a restart.

Complete the per-connector technique mappings for the breadth catalog.

~70% of the 27 connectors have full mappings as of 2026-06-07. The remaining 30% are tagged but incomplete; completing them is the highest-ROI coverage work.

Dashboard + /architecture UI for the coverage-gap recommender.

recommend_gaps() Python API shipped 2026-06-07 — returns ranked recommendations of un-installed connectors that would close the most MITRE gaps. The remaining piece is the dashboard surface that calls it + the /architecture#mitre page that shows the recommendation under the heatmap.

LifecycleStore Performance

Triage-decision pruning rules for long-lived cases.

Long-lived cases accumulate triage_decisions joins linearly. Query latency stays under 10ms but the table grows; pruning rules keep the long tail healthy.

Config-watcher that calls swap_manifest on manifest-file mtime change.

ConnectorManifestRegistry.swap_manifest() API shipped 2026-06-07 — atomic, thread-safe, returns the previous manifest for diff logging. The remaining piece is the watcher that polls each registered manifest's source file mtime + calls swap_manifest on change. Then a bug-fix manifest update lands without restarting the binary.

Automated rotation scheduler (in-CLI rotation verb already ships).

`cybercli vault rotate --new-key-path <path>` + vault.rotate() both land 2026-06-07. An automated scheduler that triggers rotation on a cadence (e.g. quarterly) is the remaining half.

Sharded consumers for very-high-volume installs.

One consumer per substrate today. A multi-socket sharded model is the scale-out path.

Multiple destinations per channel type (two Slack workspaces, two email recipients).

Schema supports it; the dispatch loop is the gap. Wide-spread for installs that need different audiences per channel.

DeliveryDispatcher Observability

Wire CircuitBreaker into the dispatcher's per-channel dispatch loop.

CircuitBreaker API + snapshot + reset shipped 2026-06-07 (per-channel three-state breaker with cool-off + HALF_OPEN probe). The remaining piece is the dispatcher integration that consults should_dispatch() before every channel attempt and reports the outcome via record_success / record_failure. Then a Pushover or Twilio outage stops burning rate-limit quota AND surfaces honestly on the dashboard.

Plumb the per-channel schedule into the ack-tick callsites.

AckLoopConfig.per_channel_schedules + _next_fire_delay_seconds_for_channel() shipped 2026-06-07 as the API half. The remaining piece is the runtime change that tracks which channel each PendingAck was enrolled for + passes the channel hint into the lookup at tick time. Then `pushover every 10min, email every 2min` becomes a real config knob.

EmailAdapter Observability

SPF / DKIM / DMARC posture validation as a doctor check.

Doc-only checklist today. Adding the check to cybercli doctor catches misconfig before the first paged alert silently fails.

SlackAdapter Integration

Slack interactions endpoint that wires the verifier primitives.

slack_ack module ships 2026-06-07: verify_slack_signature + parse_block_kit_interaction + extract_ack_intent + SlackConfig.signing_secret. The remaining piece is a POST /api/slack/interactions endpoint on the dashboard host that runs the three primitives in order and hands the resolved signal_id to the AckLoopEngine.

v1.5

9 items

Slated for the v1.5 federation release. The Sovereign multi-tenant story is the unifying theme.

Per-tenant ladder for multi-tenant federation.

Single-instance installs share one ladder today. Sovereign federation needs per-tenant ladders so Marshal A's autonomy on isolate_agent doesn't bleed into tenant B.

Per-connector process isolation for HA installs.

Failure-isolation today is process-local. A multi-process supervisor (one process per connector kind) is needed for installs where a Wazuh poll bug must not stop M365.

Per-tenant policy records.

Multi-tenant federation needs per-tenant lane choices — Marshal A runs local while tenant B runs BYO.

Per-tenant per-role override map.

Multi-tenant installs inherit the global per-role map for every tenant today. Per-tenant override pairs with the federation engine.

Remote chain mirroring with conflict-free merge.

No built-in off-box replication today. cybercli backup snapshots the SQLite file; geographic redundancy needs a chain-aware mirror.

Cross-host replication for HA.

Single SQLite file is the source of truth today. Multi-host HA ships with v1.5 + the Sovereign federation engine.

Per-tenant manifest overlay.

Multi-tenant installs where tenant A wants a custom action template on top of a shared manifest need an overlay layer.

Direct-API substrate alongside the Vector transport substrate.

Vector is the only transport today. Direct-API connectors (Wazuh REST, M365 Graph, Unifi cloud) run their own polling. Unifying them under one substrate abstraction is the architecture win.

SlackAdapter Integration

Slack app-based OAuth for multi-channel posting.

Webhook-per-destination today. App OAuth lets one install post to many channels with one credential.

Enterprise

1 item

Slated for the Enterprise tier. Compliance + sovereignty-grade key custody.

KMS / HSM master KeyProvider backends.

Only file backend ships in v1. AWS KMS, Azure Key Vault, on-prem PKCS#11 backends slot in via the same KeyProvider interface; this is the Enterprise differentiator.

Vector upstream

1 item

Slated to land when Vector ships the underlying support. Not work CyberCLI owns directly.

Hot-reload of conf.d/ entries without a Vector restart.

Parser updates require restart today; ~2s gap on deploy. Hot-reload is a Vector upstream roadmap item.

By theme

What kind of work is on the backlog?

Scale
10
· Per-tenant ladder for multi-tenant federation.
· Unified work-queue / fan-out across multiple consumer processes.
+ 8 more
UX
7
· Dashboard slider that calls compute_recommendations and renders the promotion nudge.
· L6 vs L5 differentiation via batched-delivery scheduler.
+ 5 more
Coverage
3
· Vendor-shipped baseline rule packs (inactive by default).
· Multi-role orchestrator firing Knight + Marshal + Paladin per event.
+ 1 more
Observability
2
· Wire CircuitBreaker into the dispatcher's per-channel dispatch loop.
· SPF / DKIM / DMARC posture validation as a doctor check.
Security
2
· KMS / HSM master KeyProvider backends.
· Automated rotation scheduler (in-CLI rotation verb already ships).
Integration
3
· Multiple destinations per channel type (two Slack workspaces, two email recipients).
· Slack interactions endpoint that wires the verifier primitives.
+ 1 more
Performance
2
· Automatic dedupe-ledger compaction on a scheduled cadence (in-CLI verb already ships).
· Triage-decision pruning rules for long-lived cases.

Why a public backlog?

Every known limit. Written down. Where you can see it.

Every CyberCLI engine deep doc carries a Status section that names what's stable, what's beta, and what's not yet built. This page is the flat view across all 27 — one list, sortable by release, themed by the kind of work.

We ship this because the alternative is the industry default: vague "roadmap" sections in pitch decks, sales-eng telling buyers different stories, and a 6-month wait to discover the feature you bought for is actually 18 months out. Writing it down breaks that.

If a backlog item ships, the engine doc's Status section is rewritten and the item lands here. If a backlog item moves between releases (v1.x → v1.5), the change is in the engine doc's audit-row equivalent — the git history of this file. There is no "we'll get to it" version of this page.