Example Workflows
Example workflow documentation is organized as separate pages so each workflow can describe its own maturity, inputs, authentication behavior, outputs, and validation path without becoming the template for every other workflow.
Use the workflow documentation pattern when adding a new example page. The pattern is intentionally status-first: a page must say whether it describes complete user-facing behavior, provisioning-only behavior, smoke-test-only behavior, or roadmap intent.
Use Configuration And Secrets for product authority. Example helper inputs must remain visibly repository-only and command-scoped; they cannot become runtime configuration or credential fallbacks.
Current And Expected Pages
| Workflow page | Status | Context |
|---|---|---|
| Workflow documentation pattern | Complete documentation pattern | Provides the reusable structure for future example workflow pages. |
| Configured Datastore creation | Configured provisioning example | Submits one predeclared Datastore configuration ID to the protected Trusted-runtime administration route. |
| CLI validation examples | Validation examples | Exercises stable CLI protocol envelopes against an already-authorized Session without loading configuration or credentials from environment. |
| C ABI HDSS workflow | Linked-C Client-bootstrap example | Builds a C caller that selects the immutable Client bootstrap and invokes authenticated stable protocol operations without endpoint or credential fallback. |
| HDSS CLI workflow | User-facing CLI workflow | Documents the daemon/session-backed CLI path for HDSS domain and study setup, governed file ingest, dataset materialization, semantic batch annotation, inspection, and validation. |
| Importing a REDCap project | Offline and live import guide | Imports reviewed exports or acquires live API roles with a fresh token through an authorized Session. |
Page Rules
- Keep each workflow on its own page.
- Link every workflow page to the relevant backlog item, issue, example crate, README, or smoke test.
- Describe command-line usage only for commands that exist.
- If a crate, command, daemon route, or binding is scaffolded but incomplete, label the documented behavior as planned or partial.
- Treat live-service smoke tests as validation evidence, not as ordinary user-facing workflow commands.