This commit is contained in:
DevRunbook release export
@@ -0,0 +1,159 @@
|
||||
# 03 — Information architecture
|
||||
|
||||
## Primary navigation
|
||||
|
||||
1. **Command Center** — intent entry, recommendations, recent repositories and runs.
|
||||
2. **Library** — search and filter all accessible playbooks.
|
||||
3. **Repositories** — manual and connected repository profiles.
|
||||
4. **Composer** — active drafts and generated previews.
|
||||
5. **Prompt Lab** — authoring, linting, version comparison and evaluations.
|
||||
6. **Run History** — generated tasks and artifacts.
|
||||
7. **Settings** — profile, integrations, storage, retention and administration.
|
||||
|
||||
On narrow screens, Command Center, Library, Repositories and History remain first-level. Composer appears contextually when a draft exists. Prompt Lab is separated as an advanced section.
|
||||
|
||||
## Route map
|
||||
|
||||
```text
|
||||
/
|
||||
/library
|
||||
/library/[playbookSlug]
|
||||
/library/[playbookSlug]/versions/[version]
|
||||
/collections
|
||||
/repositories
|
||||
/repositories/new
|
||||
/repositories/[repositoryId]
|
||||
/repositories/[repositoryId]/profile
|
||||
/repositories/[repositoryId]/snapshots/[snapshotId]
|
||||
/composer/new
|
||||
/composer/[draftId]
|
||||
/runs
|
||||
/runs/[runId]
|
||||
/lab
|
||||
/lab/playbooks/new
|
||||
/lab/playbooks/[playbookId]
|
||||
/lab/playbooks/[playbookId]/versions/[version]
|
||||
/lab/evaluations
|
||||
/settings/profile
|
||||
/settings/integrations
|
||||
/settings/integrations/gitea/[integrationId]
|
||||
/settings/security
|
||||
/settings/storage
|
||||
/settings/audit
|
||||
/admin/jobs
|
||||
/admin/health
|
||||
```
|
||||
|
||||
## Command Center hierarchy
|
||||
|
||||
### Hero task entry
|
||||
|
||||
A command-style field asks: **“What should Codex do?”**
|
||||
|
||||
It can search and recommend but must not silently invent an executable prompt. Results display:
|
||||
|
||||
- best matching playbook;
|
||||
- why it matches;
|
||||
- required missing information;
|
||||
- compatible repositories;
|
||||
- risk and default autonomy.
|
||||
|
||||
### Operational panels
|
||||
|
||||
- Continue draft
|
||||
- Recommended for selected repository
|
||||
- Recently generated
|
||||
- Repository findings
|
||||
- Recently updated validated playbooks
|
||||
- Integration health only when action is required
|
||||
|
||||
## Library information model
|
||||
|
||||
### Filter groups
|
||||
|
||||
- Task category
|
||||
- Playbook type: Quick Prompt, Guided Playbook, Run Pack
|
||||
- Work mode: Inspect, Plan, Guided, Execute, Recovery
|
||||
- Autonomy support
|
||||
- Risk tier
|
||||
- Stack
|
||||
- Lifecycle
|
||||
- Quality status
|
||||
- Source: Built-in, Private, Imported
|
||||
|
||||
### Result card content
|
||||
|
||||
- title and one-line outcome;
|
||||
- category icon;
|
||||
- playbook type;
|
||||
- risk tier;
|
||||
- supported autonomy range;
|
||||
- top stack tags;
|
||||
- lifecycle/quality badge;
|
||||
- version and update date;
|
||||
- favorite control;
|
||||
- “Compose” primary action.
|
||||
|
||||
Do not fill cards with the full prompt. The card exists to make a decision.
|
||||
|
||||
## Playbook detail hierarchy
|
||||
|
||||
1. Outcome and recommended use
|
||||
2. Compose action
|
||||
3. Risk, autonomy, type and quality summary
|
||||
4. What it does
|
||||
5. When to use / when not to use
|
||||
6. Inputs and repository requirements
|
||||
7. Workflow preview
|
||||
8. Guardrails and protected behavior
|
||||
9. Validation and done-when contract
|
||||
10. Compatibility and limitations
|
||||
11. Example rendered output
|
||||
12. Version history and evidence
|
||||
|
||||
## Repository workspace hierarchy
|
||||
|
||||
- identity and source;
|
||||
- stack summary;
|
||||
- readiness/health findings;
|
||||
- command registry;
|
||||
- protected paths and policies;
|
||||
- latest snapshot evidence;
|
||||
- recommended playbooks;
|
||||
- recent runs;
|
||||
- profile edit and refresh actions.
|
||||
|
||||
Health findings are not an unexplained numeric score. Each finding needs severity, evidence, rationale and a corresponding playbook or documentation link.
|
||||
|
||||
## Composer information architecture
|
||||
|
||||
Desktop uses three coordinated regions:
|
||||
|
||||
- **Configuration rail:** task inputs, profile, scope, autonomy and policies.
|
||||
- **Preview canvas:** rendered task with collapsible block outline.
|
||||
- **Inspector:** linter findings, provenance, compatibility and export readiness.
|
||||
|
||||
Mobile uses a step flow with persistent preview and issues tabs.
|
||||
|
||||
Recommended steps:
|
||||
|
||||
1. Task
|
||||
2. Repository
|
||||
3. Scope
|
||||
4. Autonomy
|
||||
5. Validation
|
||||
6. Review and export
|
||||
|
||||
## Run detail hierarchy
|
||||
|
||||
- run title and generation timestamp;
|
||||
- exact playbook version and digest;
|
||||
- repository-profile snapshot;
|
||||
- normalized inputs;
|
||||
- rendered prompt;
|
||||
- exported artifacts;
|
||||
- lint result;
|
||||
- user notes and feedback;
|
||||
- provenance and audit metadata.
|
||||
|
||||
Historical runs are read-only. “Create variation” starts a new draft referencing the historical run.
|
||||
Reference in New Issue
Block a user