Understand availability and documentation changes¶
A capability can exist in the server implementation while its screen is unfinished or its required provider is unavailable in a particular environment. Documentation needs to keep those facts separate.
Use this page to interpret the feature guides and the local preview. It is not a live status page or a release announcement.
Current documentation state: These general pages and the linked feature guides are drafts under review. Whole-platform source reconciliation, connected environment checks and initial reader acceptance remain unfinished. The delivery decision is public general, user and business documentation at docs.<zone>, with internal engineering and operations in private GitHub. Actual hosting, publication checks and delivery verification remain unfinished.
Read each kind of evidence for what it establishes¶
| Evidence | What it helps establish | What still needs its own verification |
|---|---|---|
| Implemented server behavior | The reviewed code and configuration contain the described behavior and rules | A working screen, actual provider setup and successful operation in the intended environment |
| Intended final-screen journey | The designed entry, wording, action sequence and recovery companions | Whether the frontend has implemented and connected that experience |
| Frontend implementation | The current application contains the inspected screen or connection | Successful end-to-end behavior, current access and environment delivery |
| Environment observation | A particular result was observed in a named environment at a time | Other users, paths, later versions or all failure/recovery cases |
| Documentation verification | Sources, links, classification and selected explanations have been checked | Complete coverage, live readiness and reader comprehension |
| Reader acceptance | The identified reviewer completed the agreed understanding or task exercise | Every feature, audience or later change outside that exercise |
The newer Figma final screens lead the intended user steps. The frontend remains work in progress. A guide therefore may describe an intended action while clearly identifying a missing connection or different current label.
Do not treat a design example, sample value, successful-looking preview or source check as a deployed product result.
Begin with the selected feature's availability statement¶
The capability map leads to all documented feature families. Open the relevant overview and task guide before planning important work.
Read the stated prerequisites, current implementation differences, permissions, expected result and recovery. For example:
- Workspace entry distinguishes current membership and product assignment from an application that is disabled or not ready in the environment.
- Billing distinguishes verified payment from application and describes the current invoice-view limitation.
- Workflow execution separates implemented request behavior from the unfinished connected requester experience.
- Source Health explains why a health label or empty collection does not prove complete reporting.
A documentation map establishes discoverability for its recorded families. It does not certify that the inventory contains no remaining gaps.
Understand enabled, permitted and usable¶
A product or capability can have a default enabled setting and still require licensing, current membership, individual permissions, policy approval, configured providers or an available frontend.
The reviewed non-private HiveAI backend has default availability subject to its commercial and security controls. That statement does not establish that the assistant interface or provider infrastructure has been delivered for your workspace.
Private Cloud and its private provider/retrieval paths remain disabled. Their documentation explains the boundary; it does not supply an activation instruction or commercial promise.
Commercial coverage is evaluated against the current terms and time. Trial expiry and paid-renewal grace have different rules; a billing recovery session does not itself permit product use, and payment does not remove every kind of workspace pause.
HiveOrbit also separates preparation and activation from current operational readiness and evidence eligibility. Reporting can become unavailable when its current prerequisites change, even though an earlier setup was saved. Choosing a past reporting period does not bypass those current checks.
A visible product card is not final proof of permission. A licence is not proof that a screen exists. A healthy service observation is not proof that every action succeeds.
How to read this local preview¶
The preview uses the existing Zerohive logo, orange accent and light/dark theme. It contains detailed public drafts and clearly labelled original layout samples. Its search and navigation are for reviewing this local content.
The general guides are included through an explicit local public allowlist. That review mechanism does not establish production hosting, a completed publication pipeline or an accepted public release. The preview's version label should be read as local preview, not a deployed product version.
Internal engineering, source references and operational material remain in private GitHub documentation for authorized readers. A public role guide explains responsibilities; it does not grant access to those materials or to the underlying product role.
If you keep an exported or copied page, treat it as a snapshot of the content you obtained. It cannot automatically describe later implementation, design or environment changes.
What should change when the platform changes¶
A behavior change needs corresponding updates to the affected explanation, prerequisites, outcomes and recovery. If it changes what a user must see or do, the required design and implementation work must also remain visible.
Behavior changes also identify the required design work. The design plan and task list record what must be reopened or added. The backend-to-design mapping records the last verified screen composition and changes only when the actual Figma screens are updated and reviewed; a behavior change alone does not rewrite that evidence.
An intended screen change is separate from a completed screen update. Guides should not turn unfinished frontend behavior into the intended design merely because the implementation currently lags. Equally, a newly designed action should not be presented as already delivered.
A changed permission, commercial rule, provider condition or data-lifecycle boundary can affect several audiences. The canonical feature guide owns its detailed facts; these starting pages link those facts so they do not maintain competing copies.
Documentation acceptance must be reconsidered when the relevant sources or reader-facing meaning changes. A previous review does not automatically approve a later revision.
When your environment differs from the guide¶
Confirm the environment, workspace, account and feature. Read the known implementation differences, then identify whether the issue concerns intended design, current frontend, access, a provider or a changed source behavior.
Report the page and section, the action attempted, approximate time and observed result through the support guidance. Do not disclose credentials or protected information in a public documentation report.
Use the feature's own recovery path for uncertain work. Avoid creating duplicate business operations to test whether an undocumented difference is temporary.
The initial reviewer is @she2. Source completeness, delivery and reader walkthroughs remain open; this page records no acceptance or release date.