Self-Healing & Feature Requests
How Viventium uses explicit local AI workflows for diagnosis, feature intake, bug reports, approval gates, and QA evidence.
The Short Version
Viventium is built to help improve and repair itself, but not by secretly changing code because a chat message sounded like a bug report.
Self-healing, feature requests, and bug reports are explicit local workflows. They gather context, write artifacts, create review gates, and use isolated workspaces before implementation.
That is the difference between a flashy "AI can fix itself" claim and a product workflow you can actually trust.
The Three Workflows
| Workflow | What it does | Safety boundary |
|---|---|---|
| Self-healing | Diagnoses the local system from docs, code, logs, and state, then writes an RCA and proposed fix. | Defaults to diagnose-only. Code changes require explicit apply mode and an isolated worktree. |
| Feature request | Turns a request into success criteria, non-goals, impacted surfaces, QA acceptance, and an approved spec. | Implementation waits for approval. The approved spec becomes feature-request.md. |
| Bug report | Captures what happened, reproduction steps, expected vs. actual behavior, RCA, proposed fix, and regression coverage. | Implementation waits for approval and runs in an isolated bugfix worktree. |
What This Means For Users
The user-facing value is not just "there is an AI worker somewhere."
It means:
- problems can be diagnosed with the same source docs and code the product is built from
- bug reports can become reproducible cases instead of vague tickets
- feature ideas can become scoped specs before anyone starts coding
- fixes can require tests and QA evidence before they are considered ready
- local artifacts stay private unless intentionally redacted or promoted
This is part of Viventium's support and reliability story: the system has a structured way to learn from issues without turning every complaint into a risky live patch.
Commands
The local CLI exposes the workflow surface:
bin/viventium workflows status --json
bin/viventium heal start
bin/viventium feature-request start --request "Describe the feature..."
bin/viventium report-bug start --what-happened "Describe the bug..." --steps-to-reproduce "Steps..."
bin/viventium workflows approve
bin/viventium workflows open-artifactsThese workflows run through GlassHive host workers when that local worker surface is enabled and healthy. If GlassHive host workers are disabled or unavailable, the workflow should fail loudly or enter an explicitly documented degraded mode.
Where Artifacts Live
Workflow artifacts are local by default:
~/Library/Application Support/Viventium/state/workflows/runs/<run-id>/Those artifacts can include intake notes, RCA drafts, proposed fixes, QA plans, and approval records. They are private local evidence until a user intentionally redacts or promotes them.
The Approval Gates
Self-healing
Self-healing starts with diagnosis:
- inspect the relevant source, docs, logs, and state
- write the RCA
- stress-test the RCA and alternative explanations
- write a proposed fix
- run tests and QA only after the fix path is approved
The default mode does not mutate code. Apply mode is explicit and bounded to an isolated heal/<slug>-<run-id> worktree.
Feature requests
Feature request intake blocks implementation until the request is clear enough to build responsibly.
The workflow should capture:
- success criteria
- non-goals
- impacted surfaces
- edge cases
- expected user experience
- QA acceptance
Only after approval does implementation start in an isolated feature/<slug>-<run-id> worktree.
Bug reports
Bug reports need more than "something broke."
The workflow captures the reproduction path, expected result, actual result, evidence, root cause, proposed fix, and regression coverage. Implementation starts only after approval, in an isolated bugfix/<slug>-<run-id> worktree.
What It Does Not Do
These workflows are deliberately not triggered by prompt-text keyword matching.
Viventium should not scan a normal chat and decide that "please fix this" means it can launch a code-changing workflow. The operator starts the workflow intentionally, reviews the artifacts, and approves the next step.
Keep Reading
- Core Services - The full product service map
- Projects, Workers & GlassHive - The worker runtime behind workflow execution
- Troubleshooting - Recovery steps when workflows or local services are unhealthy
- Prompt Workbench - The review surface for prompt changes and evals