⚙️ One Command. Full Migration.

Turn No-Code Evidence into
Production Pro-Code

NoCode2ProCode Genesis reads migration_inputs/, classifies packages, websites, videos, BRDs, screenshots, schemas, APIs, and local runtime evidence, then builds a canonical app spec, generates code, runs repair + QA readiness checks, prepares handoff, and saves verified learning.

📦
migration_inputs/
🎥
Source Evidence
🤖
Genesis Runtime
📋
Canonical App Spec
⚛️
Generated App
QA + Readiness
🗄️
Delivery
Verified Memory
🚀
Approved Release
📥
Input Intake
📦
PowerApps Extractor
🌐
Website Extractor
📄
Document Extractor
🧭
Source Truth
🧠
BRD Intelligence
🧪
Quality Gates
🧬
Memory Curator
Why Genesis Exists

Your Low-Code App Works Today…
But It Still Needs Real Engineering

Genesis is built for the moment when exports, screenshots, docs, and runtime clues need to become an owned production codebase.

🔒

Scattered Source Evidence

Your real app knowledge is split across exports, BRDs, screenshots, videos, APIs, schemas, and human memory instead of one reliable engineering source.

📈

No Trusted Migration Contract

Without source-truth resolution and a canonical app spec, rebuilds drift, assumptions pile up, and teams lose confidence in what should actually be built.

🧪

No Delivery Pipeline

Most conversions stop at mockups. They do not include structured QA, repair reports, replay evidence, approval checkpoints, readiness artifacts, or reusable migration memory.

🧩

No Repeatable Migration Runtime

You need more than generated code. You need a runtime that can orchestrate extractors, builders, QA, security, delivery readiness, and learning in one controlled flow.

Genesis Flow

Genesis Reads, Resolves,
and Rebuilds

📥
Input
PowerApps package or source files
Website, video, or screenshots
BRD, notes, and mockups
XML, JSON, YAML, API configs
SQL, CSV, Excel, schema files
Local runtime browser evidence
🧠
Intelligence
Classifies every source
Builds swarm execution plan
Extracts AST, BRD, screenshot hints
Resolves source truth
Builds migration BRD and IR
Freezes canonical app spec
Plans design, QA, readiness, memory
📤
Output
Frontend scaffold
Backend services
Database + integration contracts
Tests + security reports
Replay dashboard
Delivery-ready handoff
Verified memory packets
Agent System

Multi-Agent Migration Engine

Genesis coordinates extractor, planner, builder, validation, readiness, and memory agents across one migration runtime. The current local pipeline adds BRD intelligence, screenshot analysis, local HTML capture, repair reporting, QA gates, and a production readiness scorecard.

Core Runtime
Genesis
Orchestrator
routes extractors, builders, QA, readiness, memory
Pipeline Runtime

From Inputs to
Validated Handoff

1
Step 01
Load migration_inputs and Start Session

Genesis validates inputs, starts the runtime session, routes models, retrieves prior verified memory, and records the migration manifest.

migration_inputs/runtime_session.jsonprovider routingmemory context
2
Step 02
Discover Sources and Extract Evidence

Extractor agents gather platform AST, website AST, BRD requirements, screenshot hints, local runtime capture, API hints, database clues, and source baseline artifacts.

platform_ast.jsonwebsite_ast.jsondocument_intent.jsonruntime_evidence.json
3
Step 03
Resolve Source Truth and Build Planning IR

Genesis compares evidence, scores confidence, builds the migration BRD, ULC-IR, design IR, and freezes the canonical app specification.

source_truth_report.jsonconfidence_scores.jsoncanonical_app_spec.json
4
Step 04
Generate Design System and App Scaffold

Builder agents generate frontend, backend, database, tests, docs, delivery-readiness files, and design-system outputs from the canonical contract.

frontend/backend/tests/deploy/docs/
5
Step 05
Run Repair, QA, Replay, Approval, and Learning

The runtime executes preflight repair, code quality gates, JSON validation, route checks, Python syntax checks, security scanning, replay dashboard creation, final approval, readiness scoring, and verified memory writeback.

repair_loop_report.jsontest_report.jsonsecurity_review.jsonproduction_readiness_scorecard.json
Source Truth Resolver

Runtime Evidence Meets
Source Truth

Genesis cross-checks exports, docs, website clues, browser evidence, APIs, and database hints before anything becomes canonical.

Evidence SignalSupporting ArtifactConfidenceCanonical Decision
PowerApps export shows request statusesplatform_ast.json● HighWorkflow enum contract
Local runtime capture reads page title, buttons, forms, inputs, and linksruntime_evidence.json● HighUI actions + capture evidence
Website reference suggests dashboard layoutwebsite_ast.json● MediumDesign strategy guidance
BRD notes say manager approval is requireddocument_intent.json● MediumHuman review assumption
OpenAPI spec defines notification contractapi_ast.json● HighIntegration contract
Schema export defines attachment relationshipsdb_ast.json● MediumDB model + storage flow
Canonical App Spec

Every Migration Freezes Into a
Canonical App Spec

canonical_app_spec.json
Generated Output Factory

Production Code,
Not Just Prototype

Genesis produces the migration workspace, QA reports, repair evidence, readiness artifacts, and learning outputs needed to keep improving the next run.

⚛️

Frontend App

Generated from the canonical spec with routes, forms, dashboards, and component structure ready for repair and polish.

Backend API

Generated service scaffold with APIs, validation, integration contracts, auth boundaries, and observability hooks.

🗄️

Database Schema

Database models, migrations, relationship hints, and data-contract outputs derived from source evidence.

🔐

Security Review

Local secret-pattern scanning, security review JSON, compliance notes, and approval-sensitive migration signals.

🧪

QA + Repair Reports

Required-file checks, JSON validation, route checks, Python syntax checks, repair logs, and test reports.

⚙️

Readiness Pack

Deployment scaffolding, CI-ready structure, approval files, and production readiness scorecard for local handoff.

📚

Architecture Docs

README, architecture docs, migration reports, and traceability artifacts packaged with the run.

🐳

Verified Memory

Verified memory packets, reusable migration patterns, and learning reports captured after approval.

QA + Repair Loop

Built-In QA
Before Delivery

Genesis now runs local repair preflight, required-file checks, JSON validation, route consistency, Python syntax checks, optional Ruff checks, backend health smoke checks, secret scanning, and readiness scoring before approval.

🔬Scaffold Check
🔌JSON + Routes
🖥️Backend Smoke
👁️Secret Scan
🔄Repair Preflight
📋Readiness Score
workspace://genesis/replay-dashboard
stage.run 'discover_sources'32ms
agent.assign 'source_truth_agent'18ms
spec.freeze 'canonical_app_spec.json'12ms
repair.run 'preflight_repair_loop'8ms
qa.run 'run_quality_gates'14ms
scorecard.write 'production_readiness_scorecard.json'9ms
replay.build → genesis_replay_dashboard.html45ms
Migration replay, QA, repair, approval, and readiness artifacts ready1.24s total
Existing Capabilities

Built For Real
Genesis Workloads

01

Internal Tool Modernization

Accept PowerApps, website, document, and mixed evidence migrations and route them through one consistent runtime.

02

Legacy Workflow Rebuild

Build migration BRDs, ULC-IR, design IR, and canonical specs before generation so teams stop rebuilding from guesswork.

03

Demo to Blueprint

Use local runtime capture, replay dashboards, and source-truth scoring to make migrations explainable.

04

Package Logic Extraction

Generate frontend, backend, database, tests, docs, and delivery-readiness scaffolds from one migration contract.

05

Enterprise QA-Ready Apps

Run repair preflight, quality gates, security review, readiness scoring, and approval reporting before handoff.

06

Automation System Upgrade

Save verified migration patterns and memory packets so future migrations improve instead of starting cold.

Before vs After

Before Ad-Hoc Migration
vs After Genesis Runtime

⚠️

Before

Evidence scattered across too many sources
No source-truth contract or confidence scoring
No repair loop, replay, or approval trace
No canonical app spec for teams to trust
Generators run without a planning runtime
No verified memory for the next migration

After

One migrate command drives the full framework
Canonical app spec freezes the migration contract
Frontend, backend, DB, tests, and docs arrive together
Replay and approval artifacts explain every decision
Repair, QA, security, and readiness outputs are prepared with the run
Verified learning is saved for future migrations
User Manual

Everything needed to understand and use Genesis

This integrated manual explains what the framework is, why TrustEngines built it, how to install it locally, how the pipeline works, what each agent does, which commands are available, what files get produced, and how to review the outputs safely.

What Genesis is

One migration framework, one controlled runtime

NoCode2ProCode Genesis by TrustEngines is an input-first migration framework that turns low-code packages, websites, videos, documents, screenshots, schemas, and local runtime evidence into reviewable pro-code workspaces.

Understands your current system

Reads packages, URLs, docs, screenshots, videos, APIs, and schemas as migration evidence.

Builds a source-truth blueprint

Resolves conflicts, scores confidence, and creates a canonical app spec before generation.

Generates a reviewable workspace

Creates scaffold outputs, QA reports, repair logs, replay files, approval artifacts, readiness scorecards, and verified memory packets.

Main command: nocode2procode migrate — reads migration_inputs/, extracts BRD requirements, screenshot hints, source evidence, and local runtime capture, resolves source truth, builds BRD + IR + canonical spec, generates the workspace, runs repair + QA, and records replay + approval + readiness + learning outputs.
Why use Genesis

A migration framework, not just a generator

Genesis is meant to help teams understand existing apps before rebuilding them, then generate reviewable outputs with QA and delivery structure.

Understands the current system

Reads packages, docs, websites, screenshots, videos, APIs, configs, and schemas as evidence.

Builds one migration truth

Resolves conflicting sources, scores confidence, and freezes a canonical app spec before generation.

Ships a full migration workspace

Creates planning artifacts, scaffold outputs, QA reports, repair reports, replay files, approval files, readiness scorecards, and verified memory packets.

Genesis follows a controlled path: extract → understand → plan migration → canonical spec → generate → repair → QA → replay → readiness handoff.
Prerequisites + setup

Install once, then run migrations from the repo root

This setup is based on the current Genesis repo contracts and is trimmed for local end-to-end work only. It installs the framework, website/UI test stack, local quality tools, and PowerApps support, while intentionally skipping deployment tooling.

Required runtime

  • Python 3.11+
  • Git
  • Node.js 20+
  • PowerShell on Windows
  • Permission to read the Genesis project

Manual integrations after install

  • UI/UX Pro Max skill
  • 21st.dev Magic MCP
  • Figma MCP
  • Firecrawl MCP
  • Context7 MCP
  • E2B MCP
  • PostgreSQL MCP in read-only mode
This block is for a local Genesis run. It sets up Python, Playwright, visual QA helpers, contract generators, local scanners, and Power Platform CLI support so you can work on website + low-code migrations on your machine without touching deployment infrastructure.
Local-only install block
$ErrorActionPreference = "Stop"
Set-ExecutionPolicy -Scope Process Bypass -Force

# ---- CHANGE ONLY IF YOUR REPO PATH IS DIFFERENT ----
$Repo = "C:\Users\Vishwas\Desktop\AI\1.Python Work Space\NoCode2ProCode-Genesis"
$ClaudeHome = "$env:USERPROFILE\.claude"

function Require-Cmd($Name, $HelpText) {
  if (-not (Get-Command $Name -ErrorAction SilentlyContinue)) {
    throw "Missing required command: $Name. Please install $HelpText first, then run this block again."
  }
}

Require-Cmd python "Python 3.11+"
Require-Cmd git "Git"
Require-Cmd node "Node.js 20+"
Require-Cmd npm "Node.js 20+"

Set-Location $Repo

Write-Host "`n=== 1) Genesis Python runtime ===" -ForegroundColor Cyan
if (-not (Test-Path ".\.venv")) { python -m venv .venv }
& .\.venv\Scripts\Activate.ps1
python -m pip install --upgrade pip
pip install -e ".[dev]" semgrep schemathesis locust testcontainers

Write-Host "`n=== 2) Claude slash commands + Genesis skill ===" -ForegroundColor Cyan
& .\scripts\install_genesis.ps1 -ClaudeHome $ClaudeHome -InstallSkill

Write-Host "`n=== 3) Local website / UI / animation / E2E stack ===" -ForegroundColor Cyan
if (-not (Test-Path ".\package.json")) { npm init -y | Out-Null }
npm install -D @playwright/test @axe-core/playwright pixelmatch pngjs motion lighthouse
npx playwright install chromium

Write-Host "`n=== 4) Spec + contract generators ===" -ForegroundColor Cyan
npm install -g @openapitools/openapi-generator-cli @asyncapi/generator

Write-Host "`n=== 5) Local quality + security tools (no deploy tools) ===" -ForegroundColor Cyan
pip install --upgrade semgrep
if (Get-Command winget -ErrorAction SilentlyContinue) {
  winget install --id Gitleaks.Gitleaks -e --accept-package-agreements --accept-source-agreements
  winget install --id Anchore.Syft -e --accept-package-agreements --accept-source-agreements
  winget install --id Anchore.Grype -e --accept-package-agreements --accept-source-agreements
  winget install --id AquaSecurity.Trivy -e --accept-package-agreements --accept-source-agreements
  winget install --id Google.OSV-Scanner -e --accept-package-agreements --accept-source-agreements
} else {
  Write-Host "winget not found -> manually install: Gitleaks, Syft, Grype, Trivy, OSV-Scanner" -ForegroundColor Yellow
}

Write-Host "`n=== 6) PowerApps / low-code extractor support ===" -ForegroundColor Cyan
if (-not (Get-Command pac -ErrorAction SilentlyContinue)) {
  $DotnetInstall = Join-Path $env:TEMP "dotnet-install.ps1"
  Invoke-WebRequest https://dot.net/v1/dotnet-install.ps1 -OutFile $DotnetInstall
  & powershell -ExecutionPolicy Bypass -File $DotnetInstall -Channel 10.0
  $env:PATH += ";$env:USERPROFILE\.dotnet;$env:USERPROFILE\.dotnet\tools"
  dotnet tool install --global Microsoft.PowerApps.CLI.Tool
}

Write-Host "`n=== 7) Contract testing support ===" -ForegroundColor Cyan
if (-not (Get-Command pact -ErrorAction SilentlyContinue)) {
  Invoke-WebRequest -UseBasicParsing https://raw.githubusercontent.com/pact-foundation/pact-cli/main/install.ps1 | Invoke-Expression
}

Write-Host "`n=== 8) Seed Genesis input folder + verify CLI ===" -ForegroundColor Cyan
if (-not (Test-Path ".\migration_inputs")) {
  New-Item -ItemType Directory -Path ".\migration_inputs" | Out-Null
}
if ((Test-Path ".\migration_inputs\migration_request.example.yaml") -and -not (Test-Path ".\migration_inputs\migration_request.yaml")) {
  Copy-Item ".\migration_inputs\migration_request.example.yaml" ".\migration_inputs\migration_request.yaml" -Force
}

nocode2procode validate
nocode2procode plan
nocode2procode install-plan

Write-Host "`n=== 9) MANUAL CLAUDE-CODE INTEGRATIONS STILL NEEDED ===" -ForegroundColor Yellow
Write-Host "UI/UX Pro Max      -> install/configure as a Claude skill in the active environment"
Write-Host "21st.dev Magic     -> add/configure the Magic MCP in Claude Code"
Write-Host "Figma MCP          -> connect if you want design/Figma extraction"
Write-Host "Firecrawl MCP      -> connect if you want deep website crawling"
Write-Host "Context7 MCP       -> connect for docs/runtime research in the pipeline"
Write-Host "E2B MCP            -> connect for sandboxed generate/repair stages"
Write-Host "Postgres MCP (RO)  -> connect only if reading live DB schema/data"
Write-Host ""

Write-Host "Local-only Genesis E2E stack is ready. Deployment tools were intentionally skipped." -ForegroundColor Green
Write-Host "Next step: put files into migration_inputs and run: nocode2procode migrate" -ForegroundColor Green
After the block finishes, the next real workflow is: put source files in migration_inputs/, copy migration_request.example.yaml to migration_request.yaml if needed, then run nocode2procode migrate.
The block does not deploy anything. It also does not auto-configure account-bound integrations like UI/UX Pro Max, 21st.dev Magic, Figma MCP, Firecrawl MCP, Context7 MCP, E2B MCP, or PostgreSQL MCP. Those still need manual approval and setup in your active Claude environment.
Input folder

Put every migration source into migration_inputs/

The framework is input-first. It starts from whatever evidence you have, then extracts and normalizes that evidence before planning the build.

Primary input location
C:\Users\Vishwas\Desktop\AI\1.Python Work Space\NoCode2ProCode-Genesis\migration_inputs

Low-code package

Power Platform solution zips, .msapp, and Src/*.pa.yaml sources.

Website reference

URLs, local/file HTML pages, navigation hints, screenshots, layouts, and public web evidence.

Business documents

BRDs, notes, PDFs, DOCX files, PPTX decks, functional requirements, acceptance criteria, and mockup references.

Runtime evidence

Videos, screenshots, browser evidence plans, local HTML capture, visible workflows, and runtime UI clues.

Data + schema

SQL, CSV, Excel, table designs, and relationship hints.

API + config

XML, JSON, YAML, OpenAPI, integration contracts, and environment clues.

Also copy migration_request.example.yaml to migration_request.yaml and fill in app name, domain, migration goal, target stack, and special notes.
One-command flow

The command that drives the whole framework

Most users only need one command to kick off the end-to-end migration runtime. Everything else exists to inspect, refine, or review a run.

Primary runtime command
nocode2procode migrate

Reads all files from migration_inputs/, classifies sources, extracts BRD requirements, screenshot hints, website/runtime evidence, resolves source truth, builds BRD + IR + canonical spec, plans agents + runtime + memory, generates scaffold outputs, runs repair + QA + readiness checks, creates replay and approval outputs, and saves verified learning.

1. Validate inputs + session
2. Discover sources
3. Extract AST + evidence
4. Resolve source truth
5. Build BRD + IR + canonical spec
6. Generate scaffold
7. Repair + QA + readiness
8. Replay + approval + memory
Pipeline

How the system works stage by stage

Genesis does not jump straight from input to code. Extraction is only the front half; the rest of the system plans, validates, and documents the migration.

Stage 01

Validate inputs + start session

Loads the input folder, validates framework configuration, starts the runtime session, and prepares model/provider routing.

Outputs: input_intake_manifest.json, runtime_session.json
Stage 02

Discover sources + swarm plan

Builds the source baseline and the structured execution plan for the migration runtime.

Outputs: source_baseline.json, agent_execution_plan.json
Stage 03

Extract native AST

Normalizes platform, website, document, API, DB, screenshot, and runtime evidence into structured artifacts.

Outputs: platform_ast.json, website_ast.json, document_intent.json, brd_mockup_inventory.json
Stage 04

Runtime evidence + browser plan

Plans browser evidence and captures local/file/localhost HTML metadata such as title, links, forms, buttons, and inputs when available.

Outputs: browser_runtime_plan.json, runtime_capture_contract.json, runtime_evidence.json
Stage 05

Resolve source truth

Compares package evidence, website signals, docs, APIs, DB clues, and runtime hints before generation.

Outputs: source_truth_report.json, source_conflict_report.json
Stage 06

Build migration BRD + IR

Turns extracted evidence into the migration brief, ULC-IR, design IR, and canonical app plan.

Outputs: canonical_app_spec.json, design_ir/, ulc_ir/
Stage 07

Generate app scaffold

Runs deterministic scaffold generation for frontend, backend, tests, docs, and local delivery-readiness structure.

Outputs: frontend/, backend/, tests/, deploy/
Stage 08

Repair + QA + readiness

Runs repair preflight, JSON validation, route checks, syntax checks, optional Ruff checks, backend health smoke, secret scan, and scorecard generation.

Outputs: repair_loop_report.json, test_report.json, security_review.json, production_readiness_scorecard.json
Stage 09

Replay + approval + learning

Creates replay files, approval artifacts, local handoff reports, and verified memory writeback packets.

Outputs: genesis_replay_dashboard.html, approval.json, verified_memory_packet.json
After extraction, Genesis does this next: normalize artifacts → build source_baseline.json → resolve source truth → build planning IR → build canonical_app_spec.json → generate scaffold → run repair + QA + readiness checks → build replay and approval outputs.
Agent system

What each agent does and why it matters

The framework uses two major families of agents: extractor/planning agents and build/delivery agents. Each has a clear responsibility and a known output surface.

Input agents

These agents read the incoming evidence and turn it into structured baseline artifacts before planning begins.

Source intake

solution_intake_agent

Classifies migration inputs, identifies source types, and starts the baseline for the run.

Reads: input folder contents
Produces: input_intake_manifest.json, source_baseline.json
Why it matters: stops the runtime from guessing what kind of migration it is.
Platform extractor

powerapps_extractor_agent

Extracts Power Platform and Power Apps exports into normalized AST artifacts.

Reads: PowerApps packages, source files
Produces: platform_ast.json
Why it matters: recovers screen, formula, and connector structure for migration.
Website extractor

website_extractor_agent

Normalizes website URLs, local HTML pages, screenshots, and supporting web evidence into website AST artifacts.

Reads: URLs, file/local HTML, screenshots, web hints
Produces: website_ast.json
Why it matters: preserves page layout and navigation clues that packages do not contain.
Document extractor

document_extractor_agent

Pulls migration intent, BRD expectations, requirements, acceptance criteria, roles, workflows, and mockup references from business docs.

Reads: BRDs, notes, PDFs, DOCX, PPTX
Produces: document_intent.json, brd_design_intent.json, brd_mockup_inventory.json
Why it matters: captures business goals that pure UI evidence cannot explain.

Planning agents

These agents turn extracted evidence into the planning system that the generators can trust.

Runtime capture

runtime_evidence_agent

Captures local/file/localhost HTML evidence and plans deeper browser/runtime capture for walkthrough flows.

Reads: runtime videos, screenshots, local HTML, browser signals
Produces: runtime_evidence.json, browser_runtime_plan.json
Why it matters: fills the gap when source packages are incomplete.
Swarm coordinator

swarm_coordinator_agent

Builds the structured execution plan for extractor, planner, generator, repair, QA, and readiness waves.

Reads: source inventory + route signals
Produces: agent_execution_plan.json, swarm_topology.json
Why it matters: keeps the runtime organized instead of ad hoc.
Source truth resolver

source_truth_agent

Resolves conflicts across export, runtime, API, DB, website, and design evidence before generation.

Reads: all extracted evidence
Produces: source_truth_report.json, confidence_scores.json
Why it matters: prevents incorrect code generation from conflicting inputs.
Migration planner

migration_brd_agent

Turns extracted evidence into the migration brief, IR, and canonical app spec before code generation.

Reads: source truth outputs
Produces: canonical_app_spec.json, ulc_ir/
Why it matters: creates the one contract all builders should follow.
Verified memory curator

memory_curator_agent

Retrieves relevant prior migration patterns before planning and saves trustworthy memory after approval.

Reads: memory store + migration context
Produces: memory_retrieval_plan.json, verified_memory_packet.json
Why it matters: lets the framework improve without saving weak assumptions.

Build agents

These agents turn the canonical spec into product structure, design direction, and code scaffolding.

Design director

ui_ux_pro_max

Defines the product experience before component and code generation.

Reads: canonical spec + design strategy rules
Produces: DESIGN.md, design_tokens.json
Why it matters: gives the generators a consistent visual contract.
Frontend builder

frontend_agent

Generates the frontend scaffold, routes, screens, and UI structure for the migration.

Reads: canonical app spec + design system
Produces: frontend/
Why it matters: creates the user-facing shape of the rebuilt application.
Backend builder

backend_agent

Generates API services, backend structure, validation, auth, and integration contract scaffolding.

Reads: canonical app spec + data/integration hints
Produces: backend/, integration_contracts/
Why it matters: gives the generated app an operational backend structure.

Validation + delivery agents

These agents review, repair, package, and document the migration workspace before handoff.

Test repair

test_repair_agent

Runs repair preflight, tracks failures, writes patch logs, and supports scaffold quality gates.

Reads: generated app scaffold
Produces: tests/, repair_loop_report.json, test_report.json
Why it matters: moves the output closer to something reviewable and runnable.
Security reviewer

security_agent

Handles local secret scanning, security review, compliance notes, risk reporting, and approval readiness outputs.

Reads: scaffold outputs + runtime context
Produces: security_review.json, security_review_report.md, compliance_report.md
Why it matters: keeps migrations from shipping without basic governance signals.
Deploy builder

deploy_agent

Prepares local delivery-readiness artifacts, CI structure, Docker scaffolding, and handoff packaging without deploying infrastructure.

Reads: generated app + delivery settings
Produces: deploy/, .github/, production_readiness_scorecard.json
Why it matters: makes the migration handoff practical instead of theoretical.
Documentation writer

documentation_agent

Writes README, architecture docs, handoff guides, and migration documentation for the workspace.

Reads: planning artifacts + scaffold outputs
Produces: docs/, README.md, ARCHITECTURE.md
Why it matters: helps the generated project remain understandable after the run.
Commands

CLI commands and what they are for

Use the main migrate command most of the time. The rest are useful for inspection, setup, validation, and reviewing a current workspace.

CommandWhen to use itWhat it gives you
nocode2procode validateBefore running the framework or after config edits.Checks that the YAML/config files are internally consistent.
nocode2procode planWhen you want to see the ordered pipeline stages.A stage plan view for the migration entrypoint.
nocode2procode install-planWhen you need to know tool expectations and install modes.Install guidance based on framework policy.
nocode2procode check-tool <stage> <tool>When checking stage-specific tool permissions.Whether that tool is allowed in that stage.
nocode2procode route <signal>When exploring routing signals like website URLs or PowerApps exports.How a signal maps to tools, stages, and prompts.
nocode2procode init-workspace "App Name"When you want a prepared workspace before a run.A migration workspace and default folder structure.
nocode2procode estimate "App Name"When you need a dry-run effort placeholder.A lightweight estimate output.
nocode2procode visual-lock <screen_id>When you want a starter visual lock spec.A basic visual_lock_spec.json.
nocode2procode design-strategyWhen defining Magic mode, UI/UX direction, and motion.Design strategy outputs and decisions.
nocode2procode design-qualityWhen reviewing design quality signals.A starter design quality report.
nocode2procode stack-resolve "<prompt>"When deciding stack and delivery mode from the migration goal.Stack resolution guidance.
nocode2procode discoverWhen you want intake, discovery, extraction, and runtime planning only.Baseline evidence artifacts and discovery outputs.
nocode2procode plan-runWhen you want planning without generation.Source truth, IR validation, canonical spec, and visual contract setup.
nocode2procode generateWhen you want deterministic scaffold generation only.Generated structure under the migration workspace.
nocode2procode qaWhen you want local quality gates without a full migration rerun.Code quality, test, security, repair, and readiness-oriented outputs.
nocode2procode replayWhen you want the replay dashboard and traceability outputs.Replay artifacts for the current workspace.
nocode2procode migrateThe main end-to-end runtime command.Discovery, planning, generation, repair, QA, security, replay, approval, readiness, and learning artifacts.
nocode2procode genesis-migrateWhen you use the compatibility alias.Same behavior as nocode2procode migrate.
nocode2procode sessionsWhen you want to list known runtime sessions.A list of migration sessions and current states.
nocode2procode status "C:\path\to\workspace"When you want to inspect one workspace state.Runtime session, last completed stage, and approval status.
Claude Code command surfaces also exist for /nocode2procode-discover, /nocode2procode-plan, /nocode2procode-generate, /nocode2procode-qa, /nocode2procode-replay, and /nocode2procode-migrate.
Outputs

What the runtime creates in a migration workspace

Genesis writes both planning artifacts and generated project structure. Review these outputs to understand what the runtime believed, what it generated, and what still needs human attention.

input_intake_manifest.json · runtime_session.json · session_events.jsonl

Session + intake

Shows the run identity, intake inventory, and session state for the migration.

source_baseline.json · platform_ast.json · website_ast.json · document_intent.json · brd_mockup_inventory.json

Evidence layer

Holds the extracted source evidence that the planning runtime depends on.

browser_runtime_plan.json · runtime_capture_contract.json · runtime_evidence.json

Runtime capture

Explains how runtime/browser evidence should be captured and records local/file HTML evidence when available.

source_truth_report.json · source_conflict_report.json · canonical_app_spec.json

Planning truth

Shows what the system trusted, what conflicted, and what contract the builders followed.

frontend/ · backend/ · tests/ · deploy/ · docs/

Generated scaffold

Contains the production-oriented structure for UI, services, validation, tests, local delivery readiness, and documentation.

generated_file_manifest.json · checkpoint_manifest.json · repair_loop_report.json

Traceability + repair

Keeps track of what was generated, which stages completed, and what repair preflight changed or checked.

genesis_replay_dashboard.html · approval.json · production_readiness_scorecard.json

Replay + approval + readiness

Provides review visibility into the migration, records approval state, and summarizes local production readiness.

memory_retrieval_plan.json · memory_context.json · verified_memory_packet.json

Memory

Shows what prior learning was reused and what verified learning is now ready to save.

genesis_apps/

Workspace location

All generated migration workspaces are written under genesis_apps/.

Recommended workflow

The simplest way to use Genesis well

This is the cleanest path for most users, especially if you are running Genesis for the first time.

1. Put sources in migration_inputs/
2. Copy migration_request.yaml
3. Run nocode2procode migrate
4. Open the workspace in genesis_apps/
5. Review source truth + canonical spec
6. Review replay + approval outputs

Files to review first

  • source_truth_report.json
  • canonical_app_spec.json
  • runtime_session.json
  • agent_execution_plan.json
  • runtime_evidence.json
  • test_report.json
  • production_readiness_scorecard.json
  • genesis_replay_dashboard.html

Best use cases right now

  • PowerApps and mixed low-code migrations
  • Website + BRD rebuilds
  • Schema + API guided migrations
  • Mixed-evidence discovery and planning runs
  • Teams that need replay, reports, and controlled review
Review + safety

When Genesis continues automatically and when it should pause

The framework is meant to move forward on its own when the signals are clear, and stop when the decision has hidden risk or needs approval.

Genesis should usually continue

  • Input classification and extraction
  • Planning artifact generation
  • Canonical spec creation
  • Scaffold generation
  • Repair, QA, readiness, replay, and manifest outputs

Genesis should stop for approval

  • Low-confidence mappings
  • Source conflicts that change behavior
  • Missing or privileged credentials
  • Protected or licensed media
  • Deploying infrastructure or using production data
Production-quality areas still planned for deeper implementation include authenticated remote browser capture, Firecrawl integration, full Power Fx parsing, deeper semantic code repair, full compiler/build execution for every generated stack, and stronger vector-backed prior-memory matching.
FAQ + troubleshooting

Common questions and practical answers

This section is here so users can get unstuck quickly without reading the whole framework source.

Can Genesis migrate any app perfectly from any input?
No. Genesis supports a wide range of inputs, but the honest goal is high-coverage migration with source truth, confidence scoring, replay, and controlled review. Some deep runtime features are still planned.
What if I only have screenshots, a video, or a BRD?
You can still use Genesis. Put those files in migration_inputs/. The extractor and planning agents will treat them as evidence and build the planning side of the migration from what is available.
Where do I put my files?
Put them in migration_inputs/ inside the project root. That folder is the main intake surface for the runtime.
What command should I start with?
Start with nocode2procode migrate. That is the full end-to-end runtime path and the best default entrypoint.
Where do the results go?
Genesis writes migration workspaces under genesis_apps/, including scaffold outputs, manifests, replay files, and memory packets.
What if the command is not found?
Activate the project virtual environment first, then run the install block again. The common path is: create .venv, activate it, and run pip install -e ".[dev]".
What if extraction is partial?
That is expected in some migrations. Review source_truth_report.json, runtime_evidence.json, and canonical_app_spec.json to see what the system trusted and what still needs review.
What makes Genesis different from a plain prompt workflow?
It is structured around source truth, canonical spec generation, stage checkpoints, replay outputs, approval surfaces, and verified memory. It is trying to be a controlled migration factory, not only a code prompt.
Run Genesis

Drop Files into migration_inputs.
Run nocode2procode migrate.

Genesis reads the input folder, extracts and resolves evidence, generates the migration workspace, runs repair + QA + readiness checks, prepares local handoff, and stores verified learning for the next run.