Delivery status and roadmap

The roadmap prioritizes investment; it is not a release-date or compatibility promise. A deliverability decision combines source, automated tests, runbooks, and Commercial GA evidence.

Capabilities with an implemented loop

• modular-monolith and Contracts boundaries, source generators, and architecture tests;
• primary SqlSugar, EF Core parity, Dapper reads, and unified persistence metadata;
• authentication, unified authorization, tenancy, audit, risk, idempotency, rate limiting, and observability;
• CAP/RabbitMQ, FusionCache/Redis, object storage, and background jobs;
• Workflow, Notifications, Files, Webhooks, Catalog, PlatformBilling, Tickets, Chat, Search, Reporting, and related modules;
• templates, code generation, seed export, and Workflow Migrator;
• Consumer Contract and Commercial GA gates.

“Implemented loop” means code and primary gates exist. It does not mean every customer topology has completed capacity and failure rehearsal.

Evidence each deployment still needs

Investment directions

1. Deepen supporting modules: give Gdpr, MasterData, AIManage, DocumentStructure, and industry/legal extensions end-to-end scenarios and dedicated runbooks where usage warrants them.
2. Productize deployment: after real adoption, ship supported Kubernetes/AWS Terraform modules, upgrade matrices, and recovery automation.
3. Extend realtime delivery: a general Notification hub, SSE, or managed SignalR needs a separate contract and multi-replica evidence; only Chat SignalR is treated as shipped today.
4. Migrate business domains: Cases and business Billing belong under src/Modules and must remain distinct from PlatformBilling and Licensing.
5. Govern compatibility: stabilize public package surfaces, migrations, and template profiles with an executable deprecation window.

GA decision

Green unit or integration tests are not GA. A release candidate must generate packages, templates, SBOM, and provenance from one commit, pass an isolated external consumer, and receive an owned risk and rollback decision. See the Commercial GA gate.

Status vocabulary

An interface, injectable Null, or local demo is not verification. Every item names an observable outcome it changes.

Current completion gaps

• Files: malware scan, upload-session expiry, repeated-finalize idempotency, and server hash trust when object metadata is absent;
• Quota: wired default policy, hard-quota concurrency, durable UsageId uniqueness, and reserve/settle;
• Notifications: channel Attempt/Receipt, recoverable retry, stable idempotency key, and operator replay;
• Identity/Security: Delegation provider parity, key rotation, and multi-replica failure rehearsal;
• Outbound HTTP/Webhooks: timeout, retry, circuit, signature, replay, and dead-letter evidence;
• Database Operations: restore, migration rollback, provider parity, and long-running-operation runbooks;
• Realtime: notification Hub/SSE beyond Chat needs a separate contract and multi-replica evidence.

Detailed owner, acceptance, and slices belong in Architecture Hub. This page supplies cross-theme priority without duplicating the execution backlog.

Prioritization model

Address data disclosure, financial loss, irrecoverable corruption, cross-tenant access, and false GA claims first. Adoption-blocking business loops follow, then efficiency and experience.

priority = severity × exposure × probability
         + delivery-blocking value
         + evidence-gap penalty
         - implementation confidence

The score structures discussion rather than replacing architecture judgment. A low-probability irreversible tenant leak may still rank first.

Roadmap item template

### Files finalize hardening
Outcome: untrusted uploads cannot become available silently
Current gap: no malware scan or session-expiry enforcement
Acceptance: provider parity + replay/idempotency + ops runbook
Owner: Files / Security
Evidence: tests, threat model, recovery drill, consumer scenario

Also state non-goals, dependencies, compatibility, migration, signals, failure policy, and rollback. A wish without owner or acceptance evidence does not enter near-term planning.

Delivery slicing

Use end-to-end tracer bullets: public contract, application use case, real adapter, failure semantics, tests, observability, and documentation close in one slice. Do not create every interface first and defer implementation and operations.

Each slice answers customer outcome, failure behavior, tenant-safety proof, disable/rollback path, and verified providers.

Version-planning verification

The roadmap does not promise dates. A candidate absorbs only accepted slices. Incomplete items remain in the knowledge base and do not enter the changelog by weakening gates.

# Inspect gaps and gates before release planning.
npm run verify:docs-depth
dotnet test tests/BitzOrcas.Framework.ConsumerContract.Tests --configuration Release
git status --short

# Check whether plans became release facts.
git diff --name-status vPREVIOUS..HEAD
rg -n "planned|待交付|not yet" src/content/docs
rg -n "SKIP|FAIL" artifacts/ga artifacts/consumer

Removal and review

Move capability from plan to changelog only when source, tests, manual, and operations evidence agree. If canceled, record reason and alternative. If another control removes risk, retain the decision basis.

After each GA, review delayed work, misclassification, manual evidence, and customer feedback. Convert recurring uncertainty into automated gates. Roadmap quality is reduced unknown risk, not item count.

Review checklist

• Does the item state an outcome rather than a solution slogan?
• Can source or runtime evidence reproduce the gap?
• Are owner, dependency, non-goal, and acceptance explicit?
• Are security, compatibility, migration, signals, and rollback covered?
• Are boundaries with the knowledge base, module manual, and changelog clear?
• Does it avoid date promises and “interface equals done” inference?