Operational documentation not yet public

How to read this page

The items below do not mean Smart Kubaba is nonfunctional; they indicate that a public, repeatable, and dated production procedure is not yet complete. Close every item separately for the target release and topology.

• The pending label describes documentation and acceptance evidence, not feature availability.
• An internal runbook or one-off success is not public validation until a second person reproduces it in a clean environment.
• Closing one subtopic does not automatically close its dependencies; for example, a storage backup does not replace database and raw-SBOM recovery evidence.

Items requiring more evidence before publication

• A complete application environment-variable catalog outside the chart plus Tomcat and Docker runtime references
• Publish, resolve, and proxy commands for every format, including minimum client versions and acceptance output
• Backup and restore order plus consistency checks covering PostgreSQL, artifact storage, and raw SBOMs together
• An upgrade and rollback runbook covering application and Flyway compatibility plus the data layer
• Incident response and security-reporting flow
• Measured capacity, failover, RTO/RPO, and SLA
• Verified air-gapped operating profile

Deployment and runtime reference

Runtime options, defaults, and security implications outside the Helm-chart scope must be collected in one versioned reference. Value examples must contain no secrets and must identify which component consumes each setting.

• Environment-variable or property name, whether it is required, default, data type, placeholder example, and restart requirement
• Ports, context path, temporary and data paths, runtime identity, and writable-filesystem boundary for Tomcat, Docker, and Kubernetes models
• Secret-key name, owner, creation, rotation, and revocation flow, and missing or malformed value behavior, never the secret value itself
• Supported chart, image, and application-version combination together with clean-install evidence

Format and client reference packs

For every package format used in production, document Hosted, Proxy, and Group coverage separately and publish only results obtained with the real client.

• Format and client name and version, operating system, repository type, and authentication method
• Secret-free configuration example and publish, resolve or download, proxy-fetch, and, when applicable, metadata or search commands
• Expected exit code or output, resulting server record, checksum, and failed identity or authorization scenario
• Minimum and accepted client versions and unsupported or limited protocol behavior

Coordinated backup and recovery runbook

Treat PostgreSQL metadata, artifact objects, and raw SBOM data under the same recovery-point objective. Evidence must cover not only backup creation but restoration into an empty or isolated target and package-client verification.

• Write freeze or consistency mechanism, component backup order, and completion markers
• Ownership for encryption, access, retention, off-site copies, and backup deletion; credential values are never documented
• Restore order into an empty target, migration compatibility, missing or corrupt part behavior, and abort or restart steps
• Recovery verification through repository inventory, artifact counts, sizes and checksums, sample client downloads, scan and risk-acceptance records, and audit history
• Measured restore duration and achieved data-point loss, without turning either into an RTO or RPO commitment before approval

Upgrade and rollback runbook

Handle the application, chart, and Flyway or data layer in one change plan. Do not publish a rollback claim without showing the behavior of irreversible migrations and data written by the new release when read by the old release.

• Supported source and target version paths, preflight checks, maintenance impact, and backup or recovery prerequisite
• Image and chart digest or immutable reference, values diff, migration order, and readiness verification
• Post-upgrade smoke and acceptance set for repositories, package clients, identity, scans and policy, tasks, and audit
• Rollback trigger, decision owner, data-compatibility boundary, and recovery path when a forward fix is required

Incident response and security reporting

The public flow must separate intake of security reports, classification of operational incidents, and restricted sharing of sensitive evidence. Publish a real contact address and response target only after ownership is approved.

• Incident categories, severity or priority criteria, triage owner, and after-hours escalation path
• Preservation of logs, audit, tasks, artifacts, and SBOM evidence and decision points for token or credential rotation or revocation
• Containment, service recovery, integrity checks, approval of internal or external communication, and post-incident review
• Scope, secure communication channel, expected researcher behavior, and disclosure coordination for vulnerability reporting

Capacity, high availability, and service objectives

Do not publish assumed node counts, throughput, failover, RTO or RPO, or SLA values. Measure results for a specific release, data profile, topology, and load model, and separate technical observations from contractual commitments.

• Artifact count and size distribution, concurrent clients, cache ratio, scan and SBOM volume, and background-task load
• Bottlenecks and scaling thresholds based on CPU, memory, PostgreSQL, storage capacity and latency, and network measurements
• Expected service behavior and measured recovery for pod or node, PostgreSQL, storage, ingress, and external-dependency failures
• Test repetition count, raw-result location, known limitations, and platform or product owners approving the measurement

Restricted-network and air-gapped profile

Air-gapped operation is not validated merely because the application starts without internet access. Define image, chart, package-dependency, OSV or intelligence data, CA and identity dependencies, and the update channel together.

• Source of imported images, charts, and packages; checksum or signature verification; malware-control ownership; and transfer medium
• OSV or intelligence snapshot creation, transport from the external environment, import, freshness visibility, and failed-update behavior
• Denied or allowed upstream model for proxy repositories, DNS or egress denial, and user-visible behavior for cache misses
• Offline CA, OIDC or LDAP choice, license or time dependencies, and clock-drift impact
• An owned, time-bound operational flow for bringing patches, security advisories, and emergency updates into the internal environment

Completion standard

An item leaves this list only after publishing repeatable steps, required roles and secret sources, success and failure outcomes, rollback or recovery behavior, and dated acceptance evidence.

Priority and dependency

Prioritize evidence gaps by production impact; interdependent items must not be considered complete in isolation.

• P0: coordinated backup and restore, upgrade and rollback, secret boundaries, and incident response
• P0: commands, minimum versions, and acceptance results for every format and client used in production
• P1: capacity, failover, RTO or RPO, and operational runbooks for the target topology
• P1: dependency, intelligence, and image-supply flow for restricted-connectivity or air-gapped profiles
• P2: public SDK or endpoint matrix, troubleshooting examples, and support or SLA material

Evidence owner and publication gate

Assign a product owner, platform owner, security reviewer, and documentation approver to each open item. Do not move content to verified until a second person reruns the commands in a clean environment and the material passes secret scanning.

Status record and versioning

Manage each gap in one tracking record with scope, status, dependencies, and evidence links. Instead of a generic complete flag, show exactly which release and topology were validated.

• Suggested states: Not started, Draft, Reproduced, Security reviewed, Approved, Published, and Superseded
• The record includes owner, reviewer, approver, target date, affected release and topology, prerequisites, and last-validation date.
• A new image, chart, migration, storage, identity, network, or client change reopens affected evidence while the old document remains preserved as Superseded.

Safe interim use

An internal runbook can be used for items that remain on this list, but it must state release, topology, owner, and date; assumptions must not be presented as production guarantees, and results must not flow automatically into public documentation.

Live demo validation — August 1, 2026

The demo showed that repository and artifact, source, scan and policy, task, audit, package-usage, outbound, storage, proxy, and identity screens exist in the running product. Screen availability does not produce per-format real-client command packs, coordinated backup and restore, upgrade and rollback, incident response, measured capacity, failover, RTO or RPO, SLA, or an air-gapped profile. None of these gaps closed through the demo review, so the Awaiting validation status is confirmed and retained.