title	Mythic Vibe CLI — Best-in-Class Production Roadmap
repo	hrabanazviking/Viking-Code-Mythic-Engineering-CLI-Vibe-Coding
method_source	hrabanazviking/Mythic-Engineering
created	2026-04-24
status	planning
format	Markdown data file
purpose	Turn Mythic Vibe CLI into a real, working, best-in-class vibe coding CLI using Mythic Engineering as the operating method.

Mythic Vibe CLI — Best-in-Class Production Roadmap

0. Executive Intent

Mythic Vibe CLI should become the command-line operating system for disciplined AI-assisted software creation.

Its job is not merely to generate prompts, scaffold documents, or wrap AI tools. Its deeper job is to make Mythic Engineering executable:

intent -> constraints -> architecture -> plan -> build -> verify -> reflect

The CLI should guide a user from vague creative impulse into:

explicit system intent,
documented constraints,
architecture-aware planning,
safe build packets,
AI-ready context packs,
verification gates,
recoverable session memory,
durable handoffs,
and long-term project continuity.

The product should feel like a calm engineering companion: structured enough to prevent drift, flexible enough to preserve creative momentum, and serious enough for long-lived codebases.

1. Source-Reality Assessment

1.1 Current repository posture

The current repo is not a clean single-purpose runtime repository. It is a large mythic engineering monorepo containing:

active CLI product code,
active docs,
tests,
historical/runtime fragments,
research islands,
vendor/reference mirrors,
plundering guides,
architectural notes,
and mythology-heavy system design material.

The existing repo docs already define the critical rule:

Active runtime path:
- mythic_vibe_cli/

Active support paths:
- tests/
- docs/
- selected root governance records

Reference / dormant / vendor islands:
- ai/
- core/
- systems/
- sessions/
- yggdrasil/
- WYRD-Protocol-...
- mindspark_thoughtform/
- whisper/
- chatterbox/
- ollama/

1.2 Active runtime files inspected

Current active Python runtime is small and concentrated:

mythic_vibe_cli/
  __init__.py
  cli.py
  codex_bridge.py
  config.py
  mythic_data.py
  workflow.py

Current test surface:

tests/
  __init__.py
  test_cli.py
  test_config_and_bridge.py
  test_workflow.py

Current docs surface includes:

docs/
  ARCHITECTURE.md
  DATA_FLOW.md
  DOCUMENTATION_STANDARDS.md
  DOMAIN_MAP.md
  INDEX.md
  PHILOSOPHY.md
  SESSION_HANDOFF_TEMPLATE.md
  SYSTEM_VISION.md
  api.md
  hardware_profiles.md
  quickstart.md
  research/
  specs/

1.3 Current implemented capabilities

The CLI already has the seed of a real product:

init / start / imbue
checkin
status
import-md
codex-pack / evoke
codex-log
sync
method
doctor / scry
weave
prune
heal
oath
grimoire add|list
config
config set
db migrate
plunder

1.4 Current architectural strengths

The project already has several strong bones:

It knows the core Mythic Engineering loop.
It creates durable artifacts under docs/, tasks/, and mythic/.
It has a prompt bridge for ChatGPT/Codex.
It tracks status in mythic/status.json.
It has a diagnostic command.
It has config layering.
It has a method sync/import path for pulling Mythic Engineering material.
It has ritual aliases that give the tool a memorable identity.
It has explicit docs that separate active runtime from dormant islands.

1.5 Current architectural weaknesses

The current product is still an early skeleton. To become best-in-class, it needs:

a stronger internal domain model,
a stable artifact schema,
reliable migrations,
better state handling,
richer diagnostics,
real project scanning,
real command contracts,
plugin loading that actually loads plugins,
provider adapters instead of copy/paste-only bridge logic,
safer GitHub import/plunder workflows,
structured task packets,
review/audit modes,
strong verification gates,
better test coverage,
packaging/release hardening,
and a stronger separation between core domain logic and CLI output.

2. Product North Star

2.1 One-sentence definition

Mythic Vibe CLI is a method-first AI coding command line that turns creative intent into architecture-aware, verified, recoverable software work.

2.2 Product promises

The finished CLI must deliver these promises:

Promise	Meaning
Architecture before patching	The tool should ask where behavior belongs before helping change code.
Continuity before speed	Every major action leaves durable traces.
AI as force multiplier	AI assists, but the user remains sovereign and responsible.
Reality over theory	Tests, diffs, runtime behavior, and files are ground truth.
Recoverable memory	A future session can understand what happened and why.
Beginner-safe, expert-capable	Simple path for new users; deep controls for serious builders.
Method fidelity	Mythic Engineering is not decoration; it is the workflow engine.
Local-first	User data stays on disk unless explicit external integration is invoked.
Pluggable	Providers, rituals, templates, and scanners can be extended.
Auditable	Decisions, prompts, changes, and verification results can be reviewed.

3. Core Design Laws

These laws should govern every implementation decision.

Law 1 — The method is executable

The CLI must not merely describe Mythic Engineering. It must enforce, guide, record, and verify the method.

Law 2 — No hidden memory

Anything important must be written to disk in a predictable place.

Law 3 — Project state is a first-class object

status.json should evolve into a real project state model with schema versioning, migrations, phase history, open tasks, risks, decisions, and verification records.

Law 4 — AI output is never automatically trusted

The CLI may generate prompts, call providers, or ingest responses, but it must separate:

proposal -> user review -> applied change -> verification -> reflection

Law 5 — Documents are not decoration

Docs are part of the runtime method. Drift between docs and code is a diagnostic failure.

Law 6 — Every subsystem has an owner

If a feature cannot be assigned to a domain, it is not ready to be implemented.

Law 7 — The CLI should be useful without cloud AI

The offline/local path should still scaffold, scan, plan, diagnose, and preserve continuity.

Law 8 — The user owns the work

The CLI should not lock the user into one AI vendor, one editor, one platform, or one worldview of software work.

4. Target Architecture

4.1 Proposed package structure

Replace the current flat runtime package with a domain-shaped architecture:

mythic_vibe_cli/
  __init__.py
  __main__.py

  cli/
    __init__.py
    app.py
    commands/
      init.py
      status.py
      checkin.py
      doctor.py
      plan.py
      codex.py
      ai.py
      scan.py
      verify.py
      reflect.py
      config.py
      db.py
      plugin.py
      plunder.py
      ritual.py
    output.py
    errors.py

  core/
    __init__.py
    phases.py
    method.py
    project.py
    state.py
    artifacts.py
    events.py
    errors.py

  workflow/
    __init__.py
    engine.py
    transitions.py
    checkins.py
    handoff.py
    reflection.py
    rituals.py

  docs/
    __init__.py
    templates.py
    renderer.py
    drift.py
    governance.py

  context/
    __init__.py
    scanner.py
    indexer.py
    summarizer.py
    packet_builder.py
    budgets.py
    file_filters.py

  ai/
    __init__.py
    providers/
      base.py
      openai.py
      anthropic.py
      gemini.py
      openrouter.py
      local.py
      copy_paste.py
    prompts/
      roles.py
      packets.py
      schemas.py
    response_ingest.py

  verify/
    __init__.py
    commands.py
    test_runner.py
    git_diff.py
    invariant_checker.py
    doc_checker.py
    security.py

  persistence/
    __init__.py
    json_store.py
    sqlite_store.py
    migrations.py
    locks.py
    backups.py

  plugins/
    __init__.py
    registry.py
    loader.py
    api.py
    hooks.py

  plunder/
    __init__.py
    github.py
    license.py
    provenance.py
    import_plan.py

  resources/
    templates/
      project/
      docs/
      tasks/
      mythic/
    schemas/
      project_state.schema.json
      checkin.schema.json
      packet.schema.json
      decision.schema.json
      verification.schema.json

4.2 Domain ownership map

Domain	Owns	Must not own
`cli/`	Argument parsing, command dispatch, terminal output	Method logic, persistence rules, provider-specific internals
`core/`	Method concepts, phases, project model, state types	Filesystem side effects, network calls
`workflow/`	Phase transitions, check-ins, handoffs, ritual workflows	Raw CLI parsing, provider HTTP calls
`docs/`	Templates, docs drift checks, governance	AI provider calls, project scanning internals
`context/`	Project scanning, indexing, packet construction	Applying code changes
`ai/`	Provider adapters, prompt rendering, response ingest	Project state ownership
`verify/`	Tests, diffs, invariant checks, diagnostics	Planning decisions
`persistence/`	JSON/SQLite stores, migrations, locks, backups	User-facing command semantics
`plugins/`	Plugin discovery, hooks, isolation	Core method law
`plunder/`	GitHub import, license/provenance tracking	Silent code mutation

5. Canonical Artifact System

5.1 Project artifact tree

A mature initialized project should contain:

.
├── MYTHIC_ENGINEERING.md
├── SYSTEM_VISION.md
├── .mythic-vibe.json
├── docs/
│   ├── INDEX.md
│   ├── PHILOSOPHY.md
│   ├── ARCHITECTURE.md
│   ├── DOMAIN_MAP.md
│   ├── DATA_FLOW.md
│   ├── DECISIONS/
│   │   └── ADR-0001-initial-architecture.md
│   ├── INTERFACES/
│   │   └── README.md
│   ├── INVARIANTS.md
│   ├── VERIFICATION.md
│   ├── RISK_REGISTER.md
│   ├── SESSION_HANDOFF.md
│   └── DEVLOG.md
├── tasks/
│   ├── current_GOALS.md
│   ├── backlog.md
│   ├── active/
│   │   └── TASK-0001.md
│   └── completed/
├── mythic/
│   ├── status.json
│   ├── state.sqlite
│   ├── loop.md
│   ├── plan.md
│   ├── codex_prompt.md
│   ├── packets/
│   ├── responses/
│   ├── checkins/
│   ├── verification/
│   ├── reflections/
│   ├── imports/
│   └── plugins.json

5.2 State schema v1

{
  "schema_version": 1,
  "project_id": "uuid",
  "goal": "string",
  "created_at": "iso_datetime",
  "updated_at": "iso_datetime",
  "current_phase": "intent",
  "completed_phases": [],
  "active_task_id": null,
  "open_risks": [],
  "open_decisions": [],
  "last_packet_id": null,
  "last_verification_id": null,
  "history": []
}

5.3 Check-in schema

{
  "schema_version": 1,
  "checkin_id": "CHK-000001",
  "timestamp": "iso_datetime",
  "phase": "plan",
  "task_id": "TASK-0001",
  "summary": "string",
  "files_changed": [],
  "decisions": [],
  "risks": [],
  "next_phase": "build"
}

5.4 Decision schema

{
  "schema_version": 1,
  "decision_id": "ADR-0001",
  "title": "string",
  "status": "proposed|accepted|superseded|rejected",
  "context": "string",
  "decision": "string",
  "consequences": [],
  "links": []
}

5.5 Verification schema

{
  "schema_version": 1,
  "verification_id": "VER-000001",
  "timestamp": "iso_datetime",
  "task_id": "TASK-0001",
  "commands": [
    {
      "command": "pytest -q",
      "exit_code": 0,
      "summary": "passed"
    }
  ],
  "diff_reviewed": true,
  "docs_updated": true,
  "invariants_checked": [],
  "result": "pass|fail|blocked"
}

6. Multi-Stage Production Plan

Stage 0 — Repo Boundary Stabilization

stage_id: STAGE-00
name: Repo Boundary Stabilization
mythic_phase_bias: architecture
goal: Make the active product boundary undeniable.
priority: critical

Intent

Stop the repo from feeling like everything is active. The CLI cannot become best-in-class while active runtime, dormant experiments, vendor mirrors, and research islands feel equally authoritative.

Constraints

Do not delete historical material yet.
Do not import dormant runtime code into active product.
Treat dormant folders as source material until formal adapters exist.
Keep Apache-2.0 notices and provenance intact.

Build tasks

Create docs/ACTIVE_PRODUCT_BOUNDARY.md.
Create docs/DORMANT_ISLANDS.md.
Add root REPO_BOUNDARY.md.
Add warning banners to dormant island READMEs if missing.
Create docs/ADRS/ADR-0001-active-runtime-boundary.md.
Create docs/ADRS/ADR-0002-no-direct-vendor-imports.md.
Update docs/INDEX.md.
Update root README with "Active Runtime Path" above the fold.
Add mythic-vibe doctor --repo-boundary check.

Verification

python -m mythic_vibe_cli.cli doctor --path .
pytest -q

Done when

A new contributor knows exactly where real CLI code lives.
mythic_vibe_cli/, tests/, and docs/ are visibly privileged.
Dormant folders cannot accidentally become dependencies without ADR.

Stage 1 — CLI Kernel Hardening

stage_id: STAGE-01
name: CLI Kernel Hardening
mythic_phase_bias: build
goal: Make the current CLI reliable, typed, testable, and maintainable.
priority: critical

Intent

Turn cli.py from a broad command file into a maintainable command surface.

Constraints

Keep existing commands working.
Preserve ritual aliases.
Avoid breaking current README examples.
Add tests before large command refactors.

Build tasks

Target command kernel

mythic-vibe
  init
  status
  checkin
  doctor
  plan
  build
  verify
  reflect
  packet
  ai
  config
  db
  plugin
  plunder

Compatibility aliases

imbue  -> init
scry   -> doctor
evoke  -> packet create
weave  -> reflect sync
heal   -> verify repair
oath   -> policy oath

Verification

python -m mythic_vibe_cli --help
python -m mythic_vibe_cli.cli --help
pytest -q

Done when

cli.py is a thin router.
Commands are isolated and individually testable.
JSON mode exists for automation.
Existing examples still pass.

Stage 2 — Mythic Project State Engine

stage_id: STAGE-02
name: Mythic Project State Engine
mythic_phase_bias: architecture
goal: Replace loose status tracking with schema-versioned project state.
priority: critical

Intent

mythic/status.json should become a durable state contract, not just a simple progress file.

Constraints

Must migrate existing simple status.json.
Must not destroy user data.
Must support JSON first, SQLite second.
Must support offline use.

Build tasks

Data rules

state_rules:
  - state changes must be append-recorded
  - migration must preserve old history
  - invalid phase names must fail validation
  - write operations must be atomic
  - backups must exist before destructive rewrite

Verification

pytest tests/test_state.py -q
mythic-vibe state validate --path .
mythic-vibe db migrate --path .

Done when

Existing projects migrate safely.
State is validated before and after command writes.
Commands can report state as human text or JSON.

Stage 3 — Mythic Artifact Template System

stage_id: STAGE-03
name: Mythic Artifact Template System
mythic_phase_bias: plan
goal: Make project scaffolding rich, explicit, and extensible.
priority: high

Intent

The current scaffold is useful but too thin for a best-in-class workflow. It should generate actionable artifacts that match Mythic Engineering.

Constraints

Beginner mode must stay readable.
Advanced mode must be deep enough for real systems.
Templates must be versioned.
User edits must not be overwritten silently.

Build tasks

Artifact profiles

Profile	User type	Generated depth
beginner	new coder / vibe coder	simple forms, explanations, examples
standard	normal project	core docs + tasks + checks
advanced	complex codebase	ADRs, invariants, interfaces, risk register
solo	single builder	lightweight handoff, devlog focus
team	multi-person	ownership map, PR checklist, review gates
cli	CLI product	command contracts, help output tests
library	Python package	API contracts, semantic versioning notes
app	app project	data flow, user journeys, deployment docs

Verification

mythic-vibe init --goal "Test project" --profile advanced --preview
mythic-vibe init --goal "Test project" --profile advanced --path /tmp/mv-test
mythic-vibe doctor --path /tmp/mv-test
pytest -q

Done when

Templates live outside runtime logic.
Scaffolds are rich enough to guide real development.
User edits are protected.

Stage 4 — Phase Workflow Engine

stage_id: STAGE-04
name: Phase Workflow Engine
mythic_phase_bias: build
goal: Make the Mythic Engineering loop operational, not merely documented.
priority: critical

Intent

The CLI should guide the user through each phase with commands, prompts, validation, and artifacts.

Constraints

Users can move flexibly, but the tool should warn about skipped reasoning.
Must support noob-friendly explanations.
Must support advanced direct mode.

Build tasks

Phase data file pattern

mythic/checkins/
  2026-04-24T18-00-00Z-intent.md
  2026-04-24T18-15-00Z-constraints.md
  2026-04-24T18-30-00Z-architecture.md

Phase record template

# Mythic Phase Record

- Phase:
- Task:
- Timestamp:
- Operator:
- Confidence:
- Risk:

## Intent

## Constraints

## Architecture Impact

## Action Taken

## Verification

## Reflection

## Next Step

Done when

The loop is navigable as a real CLI state machine.
Each phase writes durable artifacts.
status can explain where the user is and what to do next.

Stage 5 — Context Scanner and Project Index

stage_id: STAGE-05
name: Context Scanner and Project Index
mythic_phase_bias: architecture
goal: Let the CLI understand the local project enough to build useful packets.
priority: critical

Intent

A best-in-class AI coding CLI must know what files exist, what changed, which docs matter, and which files should not be touched.

Constraints

Must respect .gitignore.
Must support include/exclude patterns.
Must avoid reading huge/vendor files by default.
Must never upload anything without explicit user action.
Must be fast on large repos.

Build tasks

Project index schema

{
  "schema_version": 1,
  "generated_at": "iso_datetime",
  "root": "path",
  "git": {
    "branch": "string",
    "dirty": true,
    "changed_files": []
  },
  "languages": {},
  "important_files": [],
  "docs": [],
  "tests": [],
  "ignored": [],
  "risks": [],
  "recommended_context": []
}

Done when

The CLI can create an accurate local project map.
Prompt packets are grounded in actual files.
Large/dormant/vendor areas are excluded by default unless requested.

Stage 6 — Best-in-Class Prompt Packet Engine

stage_id: STAGE-06
name: Best-in-Class Prompt Packet Engine
mythic_phase_bias: build
goal: Make AI packets precise, bounded, role-aware, and repeatable.
priority: critical

Intent

The current codex-pack is the right seed. It should become a general packet engine for multiple AI workflows.

Constraints

Keep copy/paste mode.
Do not require API keys.
Preserve ChatGPT Plus/Codex bridge.
Support model/provider-specific packet formats later.

Build tasks

Packet data model

{
  "packet_id": "PKT-000001",
  "created_at": "iso_datetime",
  "phase": "build",
  "role": "Forge Worker",
  "task": "string",
  "context_files": [],
  "forbidden_files": [],
  "invariants": [],
  "verification": [],
  "prompt": "string",
  "budget": {
    "limit": 12000,
    "used": 10422,
    "truncated": true
  }
}

Golden prompt format

# Mythic Engineering Task Packet

## 1. Role

## 2. Intent

## 3. Constraints

## 4. Architecture Context

## 5. Files In Scope

## 6. Files Out of Scope

## 7. Current State

## 8. Requested Change

## 9. Verification Commands

## 10. Required Output Format

## 11. Check-in Summary

Done when

Packets are reusable artifacts, not temporary text.
The same input creates reproducible packet output.
Packets can be pasted into multiple tools without losing method fidelity.

Stage 7 — AI Provider Adapter Layer

stage_id: STAGE-07
name: AI Provider Adapter Layer
mythic_phase_bias: architecture
goal: Add optional direct AI integrations without breaking local-first/copy-paste use.
priority: high

Intent

The CLI should work in three modes:

1. Offline/local artifact mode
2. Copy/paste bridge mode
3. Direct provider mode

Constraints

No provider required by default.
API keys must be explicit.
Sensitive files must not be sent accidentally.
Provider adapters must be isolated.
Every provider call must be logged as metadata, not hidden behavior.

Build tasks

Provider interface

class AIProvider:
    name: str

    def validate_config(self) -> ProviderStatus:
        ...

    def estimate(self, packet: Packet) -> Estimate:
        ...

    def run(self, packet: Packet) -> ProviderResponse:
        ...

Security rules

ai_safety_rules:
  - no network call unless command explicitly invokes provider mode
  - no hidden provider fallback
  - no automatic code application from model output
  - log provider, model, timestamp, packet id, and files included
  - redact configured secrets
  - warn if packet includes env files, keys, tokens, credentials, private notes

Done when

Copy/paste remains first-class.
Direct AI mode is optional, explicit, logged, and safe.
The provider system can grow without contaminating core workflow logic.

Stage 8 — Verification and Reality Gates

stage_id: STAGE-08
name: Verification and Reality Gates
mythic_phase_bias: verify
goal: Make reality checks central to the CLI.
priority: critical

Intent

The CLI must enforce Mythic Engineering's principle that reality outranks theory.

Constraints

Verification commands differ by project.
Tool must work even when no tests exist.
It should recommend, not fake certainty.

Build tasks

Verification levels

Level	Meaning
`none`	No checks configured. Tool warns.
`smoke`	CLI/help/import tests pass.
`unit`	Project unit tests pass.
`integration`	Cross-command workflows pass.
`release`	Full test/lint/type/package checks pass.

Done when

The CLI never treats unverified changes as complete.
Verification results become durable records.
Failing tests trigger a structured healing workflow.

Stage 9 — Doctor/Scry Deep Diagnostics

stage_id: STAGE-09
name: Doctor/Scry Deep Diagnostics
mythic_phase_bias: verify
goal: Turn doctor into a serious project health scanner.
priority: high

Intent

doctor should become one of the CLI's killer features.

Build tasks

Diagnostic item schema

{
  "severity": "warning",
  "code": "DOCS_DRIFT_001",
  "message": "docs/ARCHITECTURE.md is older than changed runtime files.",
  "evidence": [],
  "recommended_fix": "Run mythic-vibe reflect --docs"
}

Done when

doctor gives actionable engineering guidance.
scry remains the mythic alias.
Diagnostics are machine-readable.

Stage 10 — Reflection, Handoff, and Continuity Memory

stage_id: STAGE-10
name: Reflection, Handoff, and Continuity Memory
mythic_phase_bias: reflect
goal: Make session endings valuable and recoverable.
priority: high

Intent

The CLI should end every work cycle with a high-quality future-self handoff.

Build tasks

Add mythic-vibe reflect.
Add mythic-vibe handoff create.
Add mythic-vibe handoff show.
Add mythic-vibe handoff latest.
Add mythic-vibe resume.
Summarize:
- intent,
- constraints,
- decisions,
- files changed,
- tests run,
- failures,
- next steps.
Generate docs/SESSION_HANDOFF.md.
Generate timestamped handoff files.
Link handoff from status.

Handoff template

# Session Handoff

## Where the work stands

## What changed

## Decisions made

## Files touched

## Verification run

## Known risks

## Next recommended action

## Prompt packet suggestion

Done when

A future session can resume without rediscovering context.
resume tells the user what to do next.
Reflection is short enough to use but rich enough to matter.

Stage 11 — Plunder System v2

stage_id: STAGE-11
name: Lawful Plunder System v2
mythic_phase_bias: constraints
goal: Turn plundering into safe, licensed, provenance-tracked reuse.
priority: medium

Intent

The repo already includes several plundering guides and a plunder command. This should become a safe code-reuse workflow, not a raw file copy helper.

Constraints

Respect licenses.
One file per import can remain as safe default.
Track source, commit, license, and modification notes.
Never overwrite silently.

Build tasks

Provenance file

mythic/imports/plunder_manifest.json

Done when

Reuse is documented and lawful.
Plundered files are traceable.
License posture is clearer.

Stage 12 — Plugin/Grimoire System

stage_id: STAGE-12
name: Plugin/Grimoire System
mythic_phase_bias: architecture
goal: Make extensions real without destabilizing the core.
priority: medium

Intent

grimoire add|list currently stores plugin strings. It should become a real plugin system with hooks.

Constraints

Plugins must not silently override core behavior.
Plugin failures must not corrupt project state.
Hooks must be documented and versioned.

Build tasks

Done when

Plugins are discoverable.
Plugin behavior is visible.
Core method law remains protected.

Stage 13 — Packaging, Release, and Install Quality

stage_id: STAGE-13
name: Packaging, Release, and Install Quality
mythic_phase_bias: verify
goal: Make the CLI easy to install, test, and release.
priority: high

Build tasks

Done when

Fresh users can install and run quickly.
CI proves core commands.
Release artifacts are reproducible.

Stage 14 — UX Polish and Command Ergonomics

stage_id: STAGE-14
name: UX Polish and Command Ergonomics
mythic_phase_bias: reflect
goal: Make the CLI feel calm, powerful, and clear.
priority: medium

Build tasks

UX law

Every command should answer:

What happened?
Where was it written?
What should I do next?
How do I verify it?

Stage 15 — Mythic Engineering Method Integration

stage_id: STAGE-15
name: Mythic Engineering Method Integration
mythic_phase_bias: architecture
goal: Make the CLI track the canonical Mythic Engineering method deeply.
priority: high

Intent

The method source should not be a loose README sync. The CLI should treat Mythic Engineering as a versioned method corpus.

Build tasks

Done when

The CLI can tell what method version/profile it is using.
Packets include relevant method sections, not random bulk docs.
Users can pin method content for reproducibility.

7. Best-in-Class Command Surface

7.1 Final command taxonomy

mythic-vibe init
mythic-vibe status
mythic-vibe next
mythic-vibe scan
mythic-vibe phase
mythic-vibe intent
mythic-vibe constraints
mythic-vibe architecture
mythic-vibe plan
mythic-vibe build
mythic-vibe verify
mythic-vibe reflect
mythic-vibe handoff
mythic-vibe packet
mythic-vibe ai
mythic-vibe method
mythic-vibe doctor
mythic-vibe config
mythic-vibe plugin
mythic-vibe plunder
mythic-vibe db
mythic-vibe policy

7.2 Ritual aliases

imbue   -> init
scry    -> doctor
evoke   -> packet create
weave   -> reflect
heal    -> verify repair
oath    -> policy oath
grimoire -> plugin

7.3 Example golden workflow

mythic-vibe init --goal "Build a real Mythic Engineering CLI" --profile advanced

mythic-vibe scan --write-index

mythic-vibe intent capture \
  --task "Refactor CLI command router"

mythic-vibe constraints capture \
  --must-preserve "Existing README commands" \
  --must-not-touch "dormant islands"

mythic-vibe architecture map \
  --domain cli \
  --decision "Move command handlers into cli/commands"

mythic-vibe plan create \
  --task "Split cli.py into command modules"

mythic-vibe packet create \
  --role "Forge Worker" \
  --phase build \
  --task "Implement the command-module split safely" \
  --out mythic/packets/PKT-0001.md

mythic-vibe ai run --provider copy-paste --packet PKT-0001

mythic-vibe response ingest \
  --from-file mythic/responses/RESP-0001.md

mythic-vibe verify run \
  --command "pytest -q" \
  --command "python -m mythic_vibe_cli --help"

mythic-vibe reflect \
  --summary "CLI command router split into modular handlers"

mythic-vibe handoff create

8. Data Files to Add

8.1 Core schemas

mythic_vibe_cli/resources/schemas/
  project_state.schema.json
  checkin.schema.json
  decision.schema.json
  verification.schema.json
  packet.schema.json
  plugin_manifest.schema.json
  plunder_manifest.schema.json

8.2 Template files

mythic_vibe_cli/resources/templates/
  project/beginner/
  project/standard/
  project/advanced/
  docs/ARCHITECTURE.md.j2
  docs/DOMAIN_MAP.md.j2
  docs/DATA_FLOW.md.j2
  docs/INVARIANTS.md.j2
  docs/RISK_REGISTER.md.j2
  docs/VERIFICATION.md.j2
  docs/SESSION_HANDOFF.md.j2
  tasks/TASK.md.j2
  mythic/loop.md.j2
  mythic/plan.md.j2
  packets/generic.md.j2
  packets/codex.md.j2
  packets/claude.md.j2
  packets/gemini.md.j2
  packets/aider.md.j2

8.3 Governance files

docs/
  ACTIVE_PRODUCT_BOUNDARY.md
  DORMANT_ISLANDS.md
  COMMAND_CONTRACTS.md
  PROVIDER_SECURITY.md
  PLUGIN_API.md
  PACKET_FORMATS.md
  STATE_SCHEMA.md
  MIGRATIONS.md
  RELEASE_PROCESS.md

9. Testing Strategy

9.1 Test categories

Category	Purpose
Unit tests	Validate pure logic and data models.
CLI tests	Validate command parsing and outputs.
Golden file tests	Validate generated templates/packets.
Migration tests	Validate state upgrades.
Filesystem tests	Validate safe writes/backups.
Provider tests	Mock provider calls.
Plunder tests	Mock GitHub imports and license data.
Integration tests	Run full Mythic loop in temp project.

9.2 Minimum release checks

ruff check .
pytest -q
python -m mythic_vibe_cli --help
python -m mythic_vibe_cli.cli --help
mythic-vibe init --goal "Smoke test" --path /tmp/mythic-smoke --profile standard
mythic-vibe doctor --path /tmp/mythic-smoke
mythic-vibe packet create --path /tmp/mythic-smoke --phase plan --task "Smoke packet"

9.3 Golden workflow test

A full integration test should:

create temp project,
initialize advanced scaffold,
scan project,
capture intent,
create plan,
create packet,
ingest mock response,
run fake verification command,
reflect,
create handoff,
assert all artifacts exist and state is coherent.

10. Release Milestones

Milestone 0.2.0 — Stable Skeleton

release: 0.2.0
theme: "Make the current CLI reliable."
must_ship:
  - __main__.py
  - split command handlers
  - better doctor
  - state migration v1
  - template files moved out of Python literals
  - tests for all current commands

Milestone 0.3.0 — Real Mythic Workflow

release: 0.3.0
theme: "Make the full loop operational."
must_ship:
  - phase commands
  - richer check-ins
  - task records
  - phase records
  - handoff create/resume
  - verification records

Milestone 0.4.0 — Context and Packets

release: 0.4.0
theme: "Make AI context packets serious."
must_ship:
  - project scanner
  - project index
  - packet IDs
  - role-aware packets
  - multiple packet formats
  - packet history

Milestone 0.5.0 — Provider and Plugin Foundations

release: 0.5.0
theme: "Make integration extensible."
must_ship:
  - provider adapter base
  - copy-paste provider
  - optional OpenAI/OpenRouter adapter
  - plugin registry
  - plugin hooks

Milestone 0.6.0 — Plunder and Provenance

release: 0.6.0
theme: "Make lawful code reuse disciplined."
must_ship:
  - plunder inspect/plan/fetch/apply
  - provenance manifest
  - license checks
  - NOTICE helper

Milestone 0.7.0 — Deep Doctor

release: 0.7.0
theme: "Make project health visible."
must_ship:
  - diagnostic codes
  - severity
  - JSON output
  - docs drift checks
  - boundary checks
  - remediation hints

Milestone 1.0.0 — Best-in-Class Local-First Mythic Vibe CLI

release: 1.0.0
theme: "A complete local-first Mythic Engineering CLI."
must_ship:
  - stable command contracts
  - documented schemas
  - migration support
  - full loop workflow
  - scanner
  - packet engine
  - verification gates
  - handoff/resume
  - release docs
  - CI
  - package install quality

11. Codex/Claude/Roo Implementation Packet Plan

Use this sequence to build the project safely with AI assistants.

Packet 1 — Boundary Audit

role: Architect
task: "Create ACTIVE_PRODUCT_BOUNDARY.md and ADR-0001."
files_allowed:
  - docs/
  - README.md
  - ARCHITECTURE.md
  - DOMAIN_MAP.md
files_forbidden:
  - dormant runtime folders
  - vendor mirrors
verification:
  - "pytest -q"

Packet 2 — CLI Router Split

role: Forge Worker
task: "Split cli.py into command modules without changing behavior."
files_allowed:
  - mythic_vibe_cli/cli.py
  - mythic_vibe_cli/cli/
  - tests/
verification:
  - "pytest -q"
  - "python -m mythic_vibe_cli.cli --help"

Packet 3 — State Schema v1

role: Architect + Forge Worker
task: "Implement schema-versioned ProjectState and migration from current status.json."
files_allowed:
  - mythic_vibe_cli/core/
  - mythic_vibe_cli/persistence/
  - mythic_vibe_cli/resources/schemas/
  - tests/
verification:
  - "pytest tests/test_state.py -q"

Packet 4 — Template Extraction

role: Scribe + Forge Worker
task: "Move scaffold templates out of Python string literals into resources/templates."
files_allowed:
  - mythic_vibe_cli/resources/templates/
  - mythic_vibe_cli/docs/
  - mythic_vibe_cli/workflow.py
  - tests/
verification:
  - "pytest -q"

Packet 5 — Project Scanner

role: Cartographer
task: "Implement project scanner and project_index.json."
files_allowed:
  - mythic_vibe_cli/context/
  - tests/
verification:
  - "pytest tests/test_scanner.py -q"

Packet 6 — Packet Engine v2

role: Forge Worker
task: "Replace Codex-only bridge internals with general packet builder while preserving codex-pack."
files_allowed:
  - mythic_vibe_cli/context/
  - mythic_vibe_cli/ai/prompts/
  - mythic_vibe_cli/codex_bridge.py
  - tests/
verification:
  - "pytest tests/test_packet_builder.py -q"
  - "mythic-vibe codex-pack --phase plan --task 'test'"

Packet 7 — Verification Records

role: Auditor
task: "Implement verify run and persistent verification records."
files_allowed:
  - mythic_vibe_cli/verify/
  - mythic_vibe_cli/workflow/
  - tests/
verification:
  - "pytest tests/test_verify.py -q"

Packet 8 — Handoff/Resume

role: Scribe
task: "Implement handoff create/latest and resume summary."
files_allowed:
  - mythic_vibe_cli/workflow/
  - mythic_vibe_cli/docs/
  - tests/
verification:
  - "pytest tests/test_handoff.py -q"

12. Non-Negotiable Quality Bar

Before calling this project "real working best there is," the CLI must satisfy:

quality_bar:
  install:
    - installs in clean venv
    - runs on Windows PowerShell
    - runs on Linux shell
  commands:
    - every command has help
    - every writing command supports dry-run or clear preview where practical
    - every command returns meaningful exit codes
  state:
    - schema-versioned
    - migration-safe
    - backup-before-destructive-change
  docs:
    - docs updated with behavior changes
    - active product boundary clear
    - API contracts current
  ai:
    - copy-paste mode works without keys
    - provider mode explicit and logged
    - no hidden uploads
  verification:
    - test runner integrated
    - verification records persisted
    - doctor catches missing artifacts
  safety:
    - plunder tracks license/provenance
    - plugin system cannot silently corrupt core
    - dormant/vendor folders protected by diagnostics

13. Final Mythic Definition

When complete, Mythic Vibe CLI should be describable like this:

Mythic Vibe CLI is a local-first, architecture-aware AI coding command line that operationalizes Mythic Engineering. It turns creative intent into explicit constraints, domain-aware plans, AI-ready packets, verified changes, and durable continuity records. It preserves the speed of vibe coding while preventing drift, hidden coupling, lost reasoning, and context collapse.

That is the standard.

Not a prompt wrapper.

Not a scaffold toy.

Not random AI automation.

A real Mythic Engineering workbench.

FilesExpand file tree

MYTHIC_VIBE_CLI_PRODUCTION_ROADMAP.md

Latest commit

History

MYTHIC_VIBE_CLI_PRODUCTION_ROADMAP.md

File metadata and controls

Mythic Vibe CLI — Best-in-Class Production Roadmap

0. Executive Intent

1. Source-Reality Assessment

1.1 Current repository posture

1.2 Active runtime files inspected

1.3 Current implemented capabilities

1.4 Current architectural strengths

1.5 Current architectural weaknesses

2. Product North Star

2.1 One-sentence definition

2.2 Product promises

3. Core Design Laws

Law 1 — The method is executable

Law 2 — No hidden memory

Law 3 — Project state is a first-class object

Law 4 — AI output is never automatically trusted

Law 5 — Documents are not decoration

Law 6 — Every subsystem has an owner

Law 7 — The CLI should be useful without cloud AI

Law 8 — The user owns the work

4. Target Architecture

4.1 Proposed package structure

4.2 Domain ownership map

5. Canonical Artifact System

5.1 Project artifact tree

5.2 State schema v1

5.3 Check-in schema

5.4 Decision schema

5.5 Verification schema

6. Multi-Stage Production Plan

Stage 0 — Repo Boundary Stabilization

Intent

Constraints

Build tasks

Verification

Done when

Stage 1 — CLI Kernel Hardening

Intent

Constraints

Build tasks

Target command kernel

Compatibility aliases

Verification

Done when

Stage 2 — Mythic Project State Engine

Intent

Constraints

Build tasks

Data rules

Verification

Done when

Stage 3 — Mythic Artifact Template System

Intent

Constraints

Build tasks

Artifact profiles

Verification

Done when

Stage 4 — Phase Workflow Engine

Intent

Constraints

Build tasks

Phase data file pattern

Phase record template

Done when

Stage 5 — Context Scanner and Project Index

Intent

Constraints

Build tasks

Project index schema

Done when

Stage 6 — Best-in-Class Prompt Packet Engine

Intent

Constraints