VPL Build Framework — V4.0 FINAL · REV 006 — Audit Sync September 23, 2026

00 · Bootstrap Master Control

One first file. One current tree. One build-driving control surface.

BOOTSTRAP is the first file and master VPL routing layer. It restores current authority, reconciles the live framework and project trees, checks current Cursor/Claude capabilities, prepares the actual executor environments, maintains the build stage identity and routes every bounded NEXT / REVIEW cycle.

First file

VPL Build Framework/BOOTSTRAP.md → V4/BOOTSTRAP.md → V4 CONTROL + FINAL operating guidelines.

Current providers

Every full Bootstrap checks current official GPT, Cursor, Claude and other assigned-provider docs/release notes for the exact Desktop/Cloud/Code/web surfaces being assigned. Yesterday's PASS is not current evidence.

Environment first

Before material work, prove folders/files, Git identity, GDrive read/write-back, plugins/MCPs, runtime/tests, relevant Hostinger services, secrets boundary and the durable return route in the actual assigned actor.

Stage 1:1

CURRENT_STAGE is copied verbatim from the active Item row and repeated in GPT, Claude, Cursor, directives and evidence.

Bootstrap control chain

ROOT BOOTSTRAP.md
  → V4/BOOTSTRAP.md + V4 CONTROL
  → V4 FINAL + locked guidelines + complete module registry
  → preserved V3 engineering lineage (historical, not competing authority)
  → active project authority / source / state
  → BUILD_PATH_ASSESSMENT.md
  → selected peer path: 01_MANUAL / 03_LIGHT_BUILD / 02_MYSMARTROUTER
  → bounded execution + QA + independent review
  → GPT adjudication
  → VPL Build Recap Template schedule/recap (Item | Status | Next step)
  → one exact next action

`edit framework`

Loads the master tree manifest, shorthand registry, module registry, changelog and the exact owning control. Update the existing owner first. If no valid owner exists, recommend the smallest new file/module and where it belongs before creating it.

`add shorthand` / `add to shorthand`

Creates or modifies a deterministic short owner phrase with an action/target, boundary and validation rule. The canonical registry is V4 FINAL communication / shorthand registry (V3 predecessor preserved).

`list shorthand`

Reads the shorthand registry and displays the active phrase → action → target map. Shorthand is routing only; it never creates deployment, payment, destructive or permission authority.

`Build`

Runs the Build Path Assessment before implementation. It selects the smallest safe operating path for the work: Manual, Light Build, or MySmartRouter.

`Build Review`

Reassesses the active build, current evidence, failures, environment, and route before the next wave. It keeps the current path when justified and escalates only the component that needs additional execution or coordination.

Shorthand authority boundary: Build and Build Review are routing commands. They choose the smallest safe path and may escalate a bounded component, but they do not authorize deployment and do not automatically launch a third-party executor.

Refresh law: full Bootstrap on session/day/context start; bounded refresh every 30 real minutes and every 4 completed directive/result exchanges, plus project switch, CONTROL change, pre-bank/release, stale pre-production write, contradiction/repeated friction or explicit RECALIBRATE. Scheduler/executor selection follows the chosen operating path and proven capability: use no persistent automation when it adds no value; when a VPL scheduled agent is required, default to GPT Scheduled Tasks. Preserve synchronous in-run freshness checks; an hourly watchdog does not replace the 30-minute rule.

Current transition status: BOOTSTRAP is owner-directed and active as the master routing/control layer. V4 FINAL / REV 006 now governs published go-forward work and explicitly sunsets V3 operating authority while preserving its evidence. Independent Claude, DeepSeek and Gemini framework certification still requires actual reviews and closed material findings; the FINAL document status does not waive those gates or product-specific acceptance.

00A · Framework Structure Map

The file tree is a control surface, not housekeeping.

Bootstrap recursively walks the live framework and active-project trees and diffs them against V4/V4_TREE_MANIFEST_FINAL.json. The map below preserves the earlier V3/RC1 topology for lineage. Current V4 routing uses V4_TREE_MANIFEST_FINAL.json, V4_MODULE_REGISTRY_FINAL.json, V4_LOCKED_GUIDELINES.json and the FINAL operating reference. Enumerate and reconcile the current live tree before use.

Preserved V3 / RC1 framework topology — historical reference

VPL/VPL Build Framework/
├── BOOTSTRAP.md                       ← FIRST FILE
├── BOOTSTRAP.html
├── VPL_BUILD_ARCHITECTURE.md
├── Build - Create Templates/
├── 90_REFERENCE/                      ← historical / archive / scratch lineage
├── V4/
│   ├── BOOTSTRAP.md + BOOTSTRAP.html
│   ├── VPL_BUILD_FRAMEWORK_CONTROL_V4.0.md
│   ├── AGENT_REGISTRY.json
│   ├── FILE_MANIFEST.json
│   ├── START_VPL.txt
│   ├── agents/                       ← 14 migration contracts
│   ├── audit/                        ← independent review prompts
│   ├── source/                       ← inspected original snapshots
│   └── evidence/                     ← backups and readback evidence
└── V3/
    ├── BOOTSTRAP.md                   ← operative V3 master index
    ├── BOOTSTRAP.html
    ├── BOOTSTRAP_TREE_MANIFEST.md     ← exhaustive live tree baseline
    ├── SHORTHAND_COMMANDS.md          ← owner phrase → action/target registry
    ├── 01_MANUAL/
    │   ├── MANUAL_CONTROL.md
    │   └── MANUAL_CONTROL.html
    ├── 02_MYSMARTROUTER/
    │   ├── MYSMARTROUTER_CONTROL.md
    │   └── MYSMARTROUTER_CONTROL.html
    ├── directives/
    ├── evidence/
    ├── project-state/
    ├── V3_assessment/
    ├── modules/
    │   ├── Bootstrap/
    │   │   └── VPL_BOOTSTRAP_MASTER_CONTROL_V3_0
    │   ├── autonomous agent control/
    │   ├── case studies/
    │   ├── Delicate Work/             ← candidate, not active authority
    │   ├── design precise change/     ← candidate for adoption
    │   ├── evidence banking/
    │   ├── executor environment control gate/
    │   ├── executor routing/
    │   ├── github governance/
    │   ├── health monitoring/
    │   ├── hostinger/
    │   ├── I never user this before/
    │   ├── mobile operations/
    │   ├── notification/
    │   ├── project bootstrap/
    │   ├── remote access - tailscale/
    │   ├── rollback recovery/
    │   ├── secrets credentials/
    │   ├── static asset publishing/
    │   └── telegram/
    ├── VPL_BUILD_FRAMEWORK_V3_FINAL_OPERATING_MANUAL.md
    ├── VPL_BUILD_FRAMEWORK_CONTROL_V3.0.md
    ├── V3_ERRATA_CLARIFICATION_001.md
    └── VPL_BUILD_FRAMEWORK_CHANGELOG_V3.md

Authority / routing

Bootstrap, Final Manual, CONTROL, authorized errata, module registry, project controls and state determine what is current and permitted.

Source / implementation

Governed Git/GitHub carries deployable source identity. Drive governs framework/control/evidence. The two are reconciled, not conflated.

Reference / lineage

90_REFERENCE/ preserves historical packages, archived modules, scratch and superseded candidates without allowing folder presence to reactivate them.

Edit type	Primary owner	Required synchronized checks
General framework behavior	Existing owning control/module resolved through `edit framework`	Bootstrap, aliases/shorthand, tree, changelog, mirrors, evidence; registry if status changes
File/folder topology	`V4_TREE_MANIFEST_FINAL.json`	Canonical paths/IDs, links, aliases, public reference, rollback
Module activation/classification	`V4_MODULE_REGISTRY_FINAL.json`	Parent authority, independent-review requirement, invoking controls
Manual NEXT / REVIEW behavior	`01_MANUAL/MANUAL_CONTROL.md`	Stage 1:1, owner routing, return contract, screenshot process
New behavior with no owner	Bootstrap recommends smallest new owner	Folder, parent authority, scope, review requirement, manifest + changelog

01 · Deterministic Operating-Path Selection

Three peer build paths. One evidence-based routing decision.

VPL does not start with a preferred executor or workflow. Bootstrap evaluates the work and selects the smallest safe operating path. The choice can be re-evaluated when evidence changes.

01 · Manual

GPT-led, bounded human/specialist execution. Use when a native human action or specialist executor is genuinely required, but persistent orchestration would add more overhead than value. GPT still owns preparation, evidence reconciliation, QA oversight, and the next bounded action.

03 · Light Build

GPT-direct engineering. Use when GPT can directly inspect, build, test, govern Git/repository work, package, and prepare deployment for a contained application with equal or lower risk. Escalate only the component that crosses the boundary.

02 · MySmartRouter

Governed orchestration. Use when multiple specialists, services, stages, persistent routes, retries, or automated coordination create enough value to justify durable routing/state/observability overhead.

Deterministic routing: assess executable/runtime complexity, backend/state complexity, repository/CI topology, data-model complexity separately from corpus size, external integrations, deployment/rollback, GPT capability, local/specialist-tool need, orchestration value, handoff risk, and required human checkpoints. Git alone never chooses Cursor; a large data set alone never chooses MySmartRouter.

02 · Human-in-the-Loop Governance

Automate routine mechanics. Keep human judgment where it adds value.

Human-in-the-loop is a cross-cutting control across Manual, Light Build, and MySmartRouter—not a separate build path and not routine owner babysitting.

Human owns

Product intent, requirements and acceptance, early UAT, material UX/quality judgment, identity/consent, consequential production or destructive approvals, unresolved risk, and release acceptance where required.

System owns

Routine NEXT and REVIEW events, deterministic QA, retries, evidence transport, ordinary machine-executable work, source/read-back checks, and preparation that does not require human consent or judgment.

Practical best-practice pattern

Use automation for repeatable mechanics; surface uncertainty and exceptions; reserve human attention for high-impact or ambiguous decisions; preserve traceability of material human decisions; and move UAT early enough to prevent expensive drift.

NEXT and REVIEW are events, not owner chores. Peter may trigger or observe them in Manual when a native handoff is unavoidable, but the framework must not turn him into the scheduler, evidence courier, environment-discovery mechanism, or routine approval button.

01 · Core Architecture

Separate the planes. Make every handoff observable.

The enterprise value of the VPL framework is not a specific model or host. It is the separation of authority, source, automation, execution, verification, runtime and durable evidence.

Canonical VPL balanced architecture

PRODUCT OWNER + GPT LEAD ENGINEER
        ↓
BOOTSTRAP + BUILD PATH ASSESSMENT
        ↓
┌──────────────┬──────────────┬────────────────┐
│              │              │                │
MANUAL      LIGHT BUILD    MYSMARTROUTER
GPT-led     GPT-direct     orchestrated
│              │              │
└──────────────┴──────────────┴────────────────┘
        ↓
GOVERNED SOURCE + EVIDENCE
Drive control / Git source / selected tools
        ↓
DETERMINISTIC QA + INDEPENDENT REVIEW
        ↓
HUMAN-IN-THE-LOOP CHECKPOINTS WHEN MATERIAL
        ↓
RELEASE / DEPLOY / LIVE VERIFY
        ↓
EVIDENCE BANK / RECOVERY / LKG

Governance

Google Drive: framework authority, CONTROL, project state, directives, decisions, evidence, banking.

Implementation

Governed GitHub: source, branch, SHA, PR, diff, version history, cloud handoff.

Persistent Automation

GPT Scheduled Tasks: default for VPL scheduled-agent creation. Build path remains selected independently. CI/deployment and product cron retain their bounded infrastructure roles.

Execution

Executor follows the Build Path Assessment: GPT-direct when capable; Cursor, Claude, local tooling, or another specialist only for a demonstrated capability gap.

Verification

Deterministic QA + real contract tests: observable gates, negative evidence, regression.

Independent Review

Separate reviewer role/context. A different agent instance alone is not automatically independent.

Runtime

Hostinger/provider: production target. Runtime truth is evidence; it is not governance authority.

Banking

Evidence + durable state: exact source, events, tests, review, release/deploy, recovery and decisions.

V4 scheduling default: GPT Scheduled Tasks owns VPL scheduled-agent creation. On-demand roles remain on-demand. A required unavailable capability blocks the affected migration until a governed exception is resolved; it does not silently switch platforms.

03 · Executor Necessity / Fit

Git is a source plane, not an automatic reason to invoke Cursor.

choose an executor because it adds required capability or materially lowers execution risk—not because a repository exists or because a conventional vibe-coding workflow normally routes Git through Cursor.

GPT-direct first

Repository creation, branch work, bounded file publication, read-back verification, ordinary PR/repository inspection, and simple application/data separation remain GPT-direct whenever the connected capability can execute and verify them safely.

Escalate the component

Cursor, Claude, or another specialist is justified only by a demonstrated capability gap: local-only tooling, parser/compiler/runtime needs, complex infrastructure, repository operations not exposed to GPT, or another bounded requirement the direct path cannot safely satisfy.

Measure complexity correctly

Backend/runtime complexity, repository/CI topology, data-model complexity, deployment/infrastructure complexity, and local-tooling needs are evaluated separately. Corpus size by itself does not make a backend complex.

GuitarFakeBook reference lesson: Desktop Guitar Pro parsing and local parser debugging justified specialist execution. The later artist/song data-repository handoff did not inherently require Cursor. The clean 13,493-song bank survived; the failure occurred because that Drive corpus was not routed into the Git data repository. This lesson now informs Light Build admission, shorthand routing, architecture, postmortem scoring, and Bootstrap.

Mandatory Executor Fit Record

Exact component proposed for escalation
GPT/native connector capability available
Exact capability gap
Specialist value-add
Added auth/context/persistence risk
Whether only the affected component can be escalated

Executor Fit Record

For any proposed specialist handoff, record the exact capability gap, value-add, added handoff risk, and whether only the affected component should be escalated.

02 · Enterprise Laws

Rules that prevent drift, owner babysitting and false readiness.

1

Source before memory

Chats help locate context; durable current authority decides.

2

Connected ≠ usable

Prove the exact operation in the exact intended actor/environment.

3

No gate opens unprepared

Readiness is a gate, not a suggestion.

4

Freshness is mandatory

Refresh every 4 completed exchanges or 30 minutes, plus hard refresh events.

5

Exact source identity

Repo + branch + SHA + changed scope + rollback before material work.

6

No self-certification

Executor DONE/READY/tests are evidence, not independent PASS.

7

Silent routine autonomy

NEXT/REVIEW/QA/retry are system events; owner is not a routine approval button.

8

Negative evidence persists

Failures, defects, failed regressions and blocked routes are banked.

9

Bounded repair + pivot

2 same-method attempts; 3 cycles/objective failures force a materially different strategy.

10

Human attention boundary

Owner for architecture, true consent/identity, incidents and P3—not predictable machine work.

11

Evidence caps maturity

No architecture or enterprise claim outruns directly inspectable proof.

12

Preserve accepted work

Alignment and framework upgrades do not restart or rewrite known-good product source.

03 · Reusable Build Lifecycle

One governed lifecycle. Three peer operating paths.

The lifecycle is dependency-driven and gate-driven, not calendar-driven. Before implementation, Build runs the neutral Build Path Assessment; Manual, Light Build, and MySmartRouter are peers, and Build Review can re-route when evidence changes.

Light Build · GPT-Direct Engineering

Selected when GPT can safely access, build, test, govern source/Git, package, and control the contained application directly with equal or lower risk.

Open the full Light Build control

ACTIVE · INDEPENDENT LOCK REVIEW PENDING

Manual · GPT-Led

Selected when bounded human/native action or specialist execution is genuinely required, while persistent orchestration would add more overhead than value.

MySmartRouter · Orchestrated

Selected when multi-stage coordination, persistent state/routing, multiple services or specialists, retries, and observability create enough value to justify orchestration overhead.

Enterprise launch sequence

0  IMPORT FRAMEWORK / PROJECT BOOTSTRAP
1  BOOTSTRAP + AUTHORITY ALIGNMENT
2  ENGINEERING READINESS / PERMISSION PREFLIGHT
3  SOURCE FREEZE + LAST-KNOWN-GOOD
4  BOUNDED BUILD WAVE
5  DETERMINISTIC QA + REAL CONTRACT TESTS
6  INDEPENDENT REVIEW
7  GPT ADJUDICATION
8  BOUNDED REPAIR or STRATEGY PIVOT
9  RELEASE FREEZE
10 DATABASE / MIGRATION GATE if applicable
11 DEPLOY
12 LIVE HEALTH / VERSION / CONTENT VERIFY
13 EVIDENCE BANK
14 AUTO-NEXT or RELEASE

Wave 1 · Core Architecture + State

Boundaries, interfaces, durable state, configuration/source separation, correlation/event identity, unit + contract tests.

Wave 2 · Runtime + Security + Observability

Real provider/API/DB contracts, secrets, retries, fallback, telemetry, health, concurrency/idempotence, recovery.

Wave 3 · Convergence + Release

Cross-module regression, cold rehydrate, interrupted execution, rollback, independent review, release/deploy/live verification and bank.

04 · Engineering Readiness

Prove the build can execute before dispatch.

The readiness packet eliminates predictable mid-wave failures and makes environment/tool access a first-class engineering dependency.

18-field Gate Readiness Packet

objective + exact acceptance
executor / QA / reviewer / adjudicator / deployer / fallback
reviewer independence / recusal
repo / branch / base SHA / candidate SHA / changed scope / portable hash
actor-specific permissions
authenticated source route
operation-level tool/MCP proof
runtime dependencies/versions
real integration contracts
QA plan + expected outputs
review packet
collision/reserved filenames
evidence destination writability
secret-use route
rollback/stop
predictable human actions
tested fallback
PRECHECK PASS/BLOCKED

Permission Dependency Map

Every required access is resolved as actor + resource + operation + auth route + proof + timestamp + staleness + fallback + human-only approval.

Operation-level access proof

actor: Cursor Cloud Agent
resource: RocketAIStudio/mysmartrouter
operation: read/write branch
auth_route: saved Cursor/GitHub integration
proof: PROVEN
proof_timestamp: 2026-09-07T09:00:00-04:00
staleness: CURRENT
fallback: Cursor Desktop bootstrap/recovery
human_only_approval: NONE

Preparation defect rule: if a predictable permission, tool, reviewer-access or evidence-writability dependency fails after the gate has started, classify it as a PREPARATION DEFECT and feed it back into Bootstrap/readiness—not as normal owner intervention.

05 · Specialist Capability Portfolio

Specialized agents are capabilities invoked by the selected path—not the default path itself.

V4 preserves these 14 documented Cursor role contracts and migrates them individually to GPT Scheduled Tasks: Persistent Build, Bootstrap Master Control, Independent QA / Review, Independent Review Router, Release, VPL Database, Hostinger MySQL Provisioning & Maintenance, Hostinger Deploy, Evidence Banking, Recovery / Rollback, Notification / Status, Hostinger Domain Discovery & Availability, Daily AI Intelligence Ingestion, and Integration / Handoff Validator. Historical contract status was recorded September 13, 2026. GPT migration status is separately recorded in the V4 registry; no blanket runtime completion is claimed.

BUILDCURSOR CONTRACT · HISTORICAL

Persistent Build Agent

Persistent governed execution of bounded implementation work packages.

Trigger: Governed directive after PRECHECK PASS and source freeze.
Inputs: Authority set; project state; directive; frozen repo/branch/SHA; readiness packet.
Outputs: One terminal PASS/BLOCKED artifact, changed scope, tests, negative evidence, next permitted action.
Control: GPT Scheduled Tasks is the default scheduled controller. Use GPT execution when proven; invoke Cursor only for a verified specialist capability gap. GPT role migration remains pending until runtime acceptance.

BOOTSTRAPCURSOR CONTRACT · HISTORICAL

VPL Bootstrap Master Control

Maintain source-before-memory framework readiness from the canonical Bootstrap chain while preserving scheduler, tree, provider-currentness, environment-preflight and anti-drift behavior.

Trigger: Full session/day/context Bootstrap plus the governed 30-minute / 4-exchange refresh cadence, hard refresh events, source recovery, explicit recalibration or Bootstrap health query.
Inputs: Authoritative VPL/VPL Build Framework/V3/modules/Bootstrap source, BOOTSTRAP_TREE_MANIFEST.md, shorthand registry, scheduler state, project/source locator and runtime health.
Outputs: Independent BOOTSTRAP_READY, provider-currentness, tree-drift, ACTOR READINESS, SOURCE ACCESS and SCHEDULER states; execution evidence; bounded logs; next-cycle state.
Control: Bootstrap is the master control source. Scheduled invocations reload Bootstrap and fail closed on required UNVERIFIED access; BLOCKED is distinct from FAILED; scheduler execution never expands scope or release authority.

QACURSOR CONTRACT · HISTORICAL

VPL Independent QA / Review Agent

Independently review, test and validate any assigned VPL artifact with requirement provenance, evidence coverage and strict PASS discipline.

Trigger: Completed build/change, explicit QA gate, pre-release validation, agent/package review.
Inputs: Authoritative target; requirement sources; candidate identity; baseline when justified; runtime/test dependencies.
Outputs: Coverage matrix, evidence-linked findings, QA blockers, integrity result and one controlled verdict.
Control: No silent remediation or self-certification. Material blocked/failed requirements prevent unconditional PASS; mock/unit counts never replace acceptance evidence.

REVIEW ROUTERCURSOR CONTRACT · HISTORICAL

Independent Review Agent / Router

Route a frozen QA-approved candidate and its evidence to a separately governed external reviewer when an additional independent review layer is required.

Trigger: QA PASS or accepted PASS WITH MINOR FINDINGS plus a review-required gate.
Inputs: Exact frozen source/package, candidate SHA, QA evidence, acceptance criteria, reviewer registry, conflict/recusal and confidentiality metadata.
Outputs: Immutable review packet, reviewer identity and independence status, raw review, normalized verdict/findings, reproducibility/access proof and review receipt.
Control: Different agent instance alone does not prove independence. Reviewer may be Claude, OpenAI, Gemini, Grok, DeepSeek, approved human or another approved route. Router never repairs or adjudicates conflicts.

RELEASECURSOR CONTRACT · HISTORICAL

Release Agent

Converge an approved candidate into an immutable release identity, enforce final freshness/rollback/evidence gates, package exact bytes and issue bounded deploy authorization.

Trigger: QA + required independent review PASS/accepted result + governance adjudication.
Inputs: Candidate SHA, QA/review/adjudication evidence, version, changelog, release policy/manifest input, rollback/LKG references and database gate result when applicable.
Outputs: Release ID/tag/version/package, actual SHA-256 checksums, immutable release manifest/evidence and exact deploy authorization.
Control: Refuses stale evidence, candidate mismatch, unresolved material findings, incomplete rollback/database gates, checksum failure, version/tag collision or secret-bearing packages. Never deploys or repairs source.

DATABASECURSOR CONTRACT · HISTORICAL

VPL Database Agent

Govern application schema, migration and data-path work with real-contract verification, idempotence, concurrency evidence and rollback proof.

Trigger: Authorized wave includes DB/schema/data-path changes.
Inputs: Migration plan; current/target schema; approved connection route; fixtures; rollback; candidate SHA; invariants and concurrency requirements.
Outputs: Migration result, independent schema verification, data-path evidence, idempotence/concurrency evidence, rollback proof and real-contract verdict.
Control: Never exposes secrets. Fake/in-memory tests cannot certify the real DB contract they replace. Production mutation requires explicit authorization.

MYSQL OPSCURSOR CONTRACT · HISTORICAL

Hostinger MySQL Provisioning & Maintenance Agent

Provision and operationally maintain approved Hostinger MySQL resources without taking ownership of application migration/schema authority.

Trigger: Explicit approved request for database/user lifecycle, credential rotation, storage inspection, retention cleanup or space reclamation.
Inputs: Approved project/environment; Hostinger/direct-MySQL route; exact user or maintenance target; retention/backup/archive policy; secure secret references.
Outputs: Provisioning/user/maintenance receipts, storage analysis, cleanup evidence, health verification and non-secret downstream connection references.
Control: Inspect → recommend → policy/approval → backup/archive gate → execute → verify → record. No unbounded delete, FK-disable shortcut, ordinary DROP, secret logging or application schema migration.

DEPLOYCURSOR CONTRACT · HISTORICAL

Hostinger Deploy Agent

Deploy one explicitly approved file to one approved Hostinger target with exact-path mapping, immutable deployment evidence and HTTPS verification.

Trigger: Explicit deployment authorization with approved domain, exact local file and explicit destination.
Inputs: Approved domain registry entry; local file; --dest root or explicit subdirectory; secure SFTP references; overwrite authorization when required.
Outputs: Deployment manifest, payload/before archives, exact remote path, upload/verification states, public URL and Recovery-compatible evidence.
Control: --dest root always maps to public_html/<basename>; local parent folders never become remote folders. No whole-site deploy or unrelated Hostinger changes.

BANKCURSOR CONTRACT · HISTORICAL

Evidence Banking Agent

Package, validate and persist accepted and negative evidence/state without using the owner as a courier, while maintaining durable project state and correlation history.

Trigger: Terminal PASS/BLOCKED/FAIL, QA or review completion, adjudication, release/deploy/recovery/database milestone, or explicit bank request.
Inputs: Autonomous event records, raw tests, source identity, QA/reviews/decisions, release/deploy/recovery/database receipts, live proof and correlation IDs.
Outputs: Immutable bank package, checksums, banking receipt, append-only correlation events, blocker history and durable current project-state projection.
Control: Chat-only output is never banked evidence. Historical positive and negative evidence is write-once; project state advances only after durable evidence is successfully written and verified.

RECOVERYCURSOR CONTRACT · HISTORICAL

Recovery / Rollback Agent

Restore exact Hostinger file state using immutable Deploy artifacts, exact recorded remote paths and independently auditable recovery receipts.

Trigger: Failed/problematic deployment, explicit restore request, last-known-good request or controlled file rollback.
Inputs: Deploy domain registry; deployment manifest; before/ or payload/ archive; exact remote path; current remote state.
Outputs: Pre-recovery snapshot, restored/deleted target evidence, post-recovery checksum/HTTPS evidence and write-once recovery receipt.
Control: before/ reverses a deployment; payload/ recreates one. New-file reversal can delete only the exact recorded file. Database rollback is separate.

NOTIFYCURSOR CONTRACT · HISTORICAL

Notification / Status Agent

Provide low-noise human-bound exception notifications, configured milestone delivery and on-demand status with durable cursor semantics.

Trigger: Human-bound exception, configured major milestone, explicit status/health/log query.
Inputs: Durable event stream, consumer cursor, milestone policy and configured channel state.
Outputs: Timestamped status/exception message and non-secret delivery receipt; successful delivery advances only that consumer cursor.
Control: Routine NEXT/REVIEW/QA/retry/remediation stays silent. Telegram is a first-class external channel, disabled by default until explicitly enabled and securely configured.

DOMAIN DISCOVERYCURSOR CONTRACT · HISTORICAL

Hostinger Domain Discovery & Availability Agent

Generate high-quality brand/domain variants, check real availability through approved providers, score/rank candidates and prepare a registration handoff without purchasing by default.

Trigger: New product/brand naming request, preferred domain unavailable, or explicit domain watch/discovery request.
Inputs: Product/brand intent, keywords, preferred base name/TLDs, prefix/suffix rules, naming constraints and approved availability provider.
Outputs: Availability-verified candidate set, quality scores, confusion/brand screen, pricing when provider-supplied, ranked shortlist and optional registration handoff.
Control: Never infers availability from search/DNS alone and never purchases, changes DNS or deploys without separate explicit authorization.

AI INTELLIGENCECURSOR CONTRACT · HISTORICAL

VPL Daily AI Intelligence Ingestion Agent

Collect approved daily AI newsletter emails, summarize/deduplicate article intelligence into a standalone HTML recap, prepare GPT/Trello handoff, email the recap and archive only successfully ingested source messages.

Trigger: Daily 11:00 PM America/New_York schedule or explicit replay of a daily ingestion window.
Inputs: Approved Gmail source registry (Medium Daily Digest, TAAFT, The Rundown AI), daily cursor, source messages, article metadata and summarization rules.
Outputs: VPL_Daily_AI_Recap_YYYY-MM-DD.html, Trello handoff JSON, email delivery status, exact Gmail archive receipt and durable ingestion state.
Control: GPT scheduling coordinates collection, recap generation and governed handoffs. Gmail/email/archive/Trello operations require actual tool access and explicit target authorization before activation. Failed preparation or email prevents source archiving.

INTEGRATIONCURSOR CONTRACT · HISTORICAL

VPL Integration / Handoff Validator Agent

Validate the seams between agents so individually correct agents also remain contract-compatible as one end-to-end build system.

Trigger: New/changed agent contract, schema/manifest/version change, framework-wide regression run or pre-integration declaration.
Inputs: Producer/consumer schemas, manifests, sample artifacts, version/status vocabularies, identity/correlation fields and registered handoff contracts.
Outputs: Per-handoff verdicts, compatibility findings, contract snapshots and a framework-wide producer→consumer integration matrix.
Control: Validates candidate SHA continuity, required fields, enum semantics, artifact availability, version compatibility and correlation continuity. Never repairs producer/consumer agents during validation.

Logical agent pipeline

BOOTSTRAP / READINESS
        ↓
PERSISTENT BUILD
        ↓
INDEPENDENT QA / REVIEW
        ↓
INDEPENDENT REVIEW ROUTER (when required)  [GPT migration pending]
        ↓
GPT / GOVERNANCE ADJUDICATION
        ↓
RELEASE AGENT  [GPT migration pending]
        ↓
DATABASE GATE when schema/data-path changes
        ↓
HOSTINGER MYSQL OPS when infrastructure/retention work is needed
        ↓
HOSTINGER DEPLOY
        ↓
LIVE VERIFY
        ↓
EVIDENCE BANK  [GPT migration pending]
        ↓
RECOVERY if needed

CROSS-CUTTING SUPPORT
DOMAIN DISCOVERY / AVAILABILITY  [GPT migration pending]
DAILY AI INTELLIGENCE INGESTION  [GPT migration pending]
INTEGRATION / HANDOFF VALIDATOR  [GPT migration pending]

ALL MATERIAL AGENTS → durable status/events → NOTIFICATION / STATUS → GPT task results / configured authorized channel

Agent maturity: fourteen historical role contracts are preserved. The first GPT Bootstrap agent is a read-only pilot; other GPT migrations are pending. Live code, permissions, scheduled execution, evidence banking and old-schedule cutover must be verified individually.

06 · Autonomous Control

NEXT and REVIEW are events, not owner chores.

Build Review reassesses the active build, current evidence, failures, environment, and operating path before the next wave. AUTO-NEXT proceeds only when the selected path remains justified and its QA/review gates pass.

Autonomous advancement

PASS PATH
EXECUTE → QA → INDEPENDENT REVIEW PASS → GPT ADJUDICATE → AUTO-NEXT

FAIL PATH
QA/REVIEW FAIL
   ↓
classify root failure
   ↓
bounded repair
   ↓
QA
   ↓
independent re-review
   ↓
PASS or BLOCKED

Retry / strategy pivot

Two identical failures with no changed approach terminate the same-method loop. Three failed attempts toward the same objective force STRATEGY_PIVOT_REQUIRED before attempt four. Native platform capabilities, alternate executor/integration, simpler architecture and governed fallbacks must be reconsidered.

Human exception boundary

Telegram/owner attention is reserved for unavoidable COPY/PASTE/native action, identity/MFA/consent, unresolved blocker, serious production/security/credential incident, P3 owner decision, configured major milestone or explicit status request.

Durable event example

schema: vpl.autonomous_event.v1
correlation_id: VPL-MSR-W2-014
event_type: REVIEW
actor: Independent Review Agent
executor: Claude
source:
  repository: RocketAIStudio/mysmartrouter
  branch: main
  sha: 7d31...
risk: P1
result: PASS
basis:
  - exact frozen source reviewed
  - deterministic QA passed
negative_evidence: []
human_action_required: NONE
next_permitted_action: RELEASE

07 · Change-Control Modes

Normal build, precise change and delicate work are not the same thing.

Normal governed build

Bounded product work under project acceptance, readiness, QA, review and banking.

Precise / surgical change

Lock accepted baseline, isolate one requested change, touch the narrowest selector/object, render QA, regression check, overwrite same destination only after PASS.

Delicate work

Read entire artifact, baseline every approved section/style/claim/link, preserve first, make smallest bounded change, run preservation audit. No opportunistic cleanup or compression.

Precise-change contract

LOCK BASELINE
  → isolate requested change
  → touch narrowest selector/object
  → render / test
  → compare before/after
  → regression check
  → overwrite authoritative destination
  → evidence record

Delicate-work contract

READ ENTIRE ARTIFACT
  → baseline sections/nav/claims/tables/styles/links
  → list REQUESTED CHANGES ONLY
  → everything else = DO NOT ALTER
  → preserve first
  → smallest bounded change
  → preservation audit
  → overwrite only after PASS

08 · QA / Debug / Recovery

Tests become enterprise evidence only when the claimed contract is actually exercised.

Deterministic QA

Unit, contract, schema/idempotence, secret guards, lint/static checks, acceptance/regression and repeatable raw outputs.

Real contract proof

Provider HTTP behavior, DB persistence/migrations, filesystem paths, concurrency primitives, queue/cron where relevant, deployment/runtime health and recovery.

Recovery

Cold rehydrate, interrupted execution, stale lock/lease, idempotent retry, failed delivery, rollback/LKG, post-recovery health and incident evidence.

MySmartRouter target: maintain 20–30 meaningful enterprise regression scenarios and grow the suite from every material defect. Its existing deterministic evidence includes a banked 263 PASS / 0 FAIL QA run; the framework now requires stronger source→runtime→recovery traceability around that proof.

Failure taxonomy

PRODUCT/SOURCE DEFECT
TEST/EVIDENCE DEFECT
PREPARATION DEFECT
PLATFORM LIMITATION
HUMAN-BOUND BLOCKER

Evidence maturity

SPECIFIED

IMPLEMENTED_SOURCE

BUILD_VERIFIED

RUNTIME_VERIFIED

PRODUCTION_VERIFIED

BANKED_WITH_REGRESSION_EVIDENCE

09A · Secure Production Promotion

Push exact approved source to Hostinger through a proven machine route.

Hostinger is VPL's current production environment. Browser navigation is not a deployment protocol.

Approved route order

Governed Git production branch → Hostinger GitHub auto-deploy or governed GitHub Actions.
Hostinger MCP/API through OAuth or scoped token, only when the active session exposes and proves the required tools.
Scoped SSH/SFTP as the recovery route.
Human-supervised hPanel/File Manager for emergencies only.

Browser automation prohibition

An authenticated browser tab or a setting labeled “connected” does not prove MCP/API access. Cloudflare, CAPTCHA, MFA, login or consent interruption makes the route human-bound. The candidate must fail closed and move to a proven machine route; browser automation must never be described as MCP deployment.

Required production record

Repository, production branch, exact commit SHA, release/package hash, approved file boundary, target domain/root, deployment route and principal, backup/LKG, rollback target, approval, deployment log, live URL/fetch, cache-aware smoke result and evidence-bank location.

Environment evolution

Current public sites may promote to Hostinger production after all gates pass. Every material or stateful web application must add a distinct preview/staging target plus migration, data backup, secrets, health, observability, incident and rollback controls before production activation.

Plane separation: Google Drive is governance/evidence. Governed Git is deployable source. Hostinger is production runtime. Production is never the source of truth, and an unversioned Drive-only file is reconciled into Git before release.

09 · Release / Database / Deployment

Deploy from exact approved source, then prove what is live.

Production contract

approved candidate SHA
   ↓
release identity + hashes
   ↓
target/site/path verification
   ↓
backup / last-known-good
   ↓
database/migration gate if needed
   ↓
bounded deploy
   ↓
canonical live fetch
   ↓
cache-busted/version verification
   ↓
health/content/runtime verification
   ↓
PASS → bank
FAIL → stop / rollback / recover

Release Agent

Freezes version/package, hashes, changelog and release manifest after QA/review/adjudication.

Database Agent

Owns schema/migration/data-path proof, idempotence and rollback when a release changes persistent data.

Hostinger Deploy Agent

Historical role contract retained. V4 governs both API and Git routes: deploy exact approved source, prove live version/health/rollback, and record actual runtime acceptance. Hostinger stays a target, never the generic controller.

10 · Traceability & Evidence Bank

Make the architecture inspectable from business constraint to production behavior.

The September assessment findings are now directly reflected in the master framework.

Architecture traceability chain

Business / user constraint
        ↓
Architecture decision / ADR
        ↓
Source module / path
        ↓
Runtime responsibility
        ↓
Provider / model routing
        ↓
Conversation / state independence
        ↓
Persistence
        ↓
QA
        ↓
Independent review
        ↓
Deployment / live verification
        ↓
Failure / recovery / rollback
        ↓
Banked evidence + version history
        ↓
Material human decision trace (only when applicable)

Acceptance evidence

Problem → constraint → authorized wave → acceptance gate → observed result. Every strong claim points to the chain.

Orchestration evidence

Persist orchestrator, automation, executor, reviewer, model/provider route, retries, gate outcomes, adjudication, bank/release and correlation IDs.

Human architectural agency

Persist material overrides, vetoes, constraints, commercial assumptions, destructive approvals and post-failure strategy changes—with prior agent proposal retained.

Evidence package layout

/evidence/<correlation-id>/
  event.yaml
  source_manifest.yaml
  readiness_packet.json
  hashes.sha256
  qa/
    raw_output.txt
    regression_matrix.md
    negative_evidence.md
  review/
    reviewer_identity.md
    frozen_review_packet_manifest.txt
    review_result.md
  runtime/
    health.json
    provider_contract_evidence/
    db_contract_evidence/
  deployment/
    deployed_version.txt
    live_verification.txt
    rollback_target.txt
  decisions/
    human_material_decisions.md
  disposition.md

13 · Independent Validation & CONTROL

Independent criticism is a CONTROL input, not a competing authority.

Revision 0.3 synchronizes the final architecture assessment and architect-aptitude evidence into the framework handoff package while keeping the V3 operating manual, CONTROL, authorized errata and active project state as the operative rule authority.

Current Gemini Reassessment

94.5/100 · Google Gemini · Expert · September 23, 2026.

This controlled delta reassessment used the prior 93.75 Gemini baseline and newer V4 / MySmartRouter evidence. It explicitly preserved negative evidence: runtime integrations remain unverified in places and the proposed persistence verifier was criticized as over-engineered. The preserved 97.0 V3 result remains historical evidence under an earlier assessment instrument.

Architect Aptitude

94.0/100 public display · raw 93.90 · Principal-Level Architect Capability.

This separate blind audit evaluates Peter DeCaro as the architect: systems thinking, judgment, operational translation, AI direction, communication, learning and process control.

Framework Maturity

M4 · Highly Mature / Governed AI Engineering.

Independent evaluator convergence validates the framework as a disciplined boutique applied-AI engineering operating system. The maturity finding is supporting evidence, not framework authority.

CONTROL feedback loop

INDEPENDENT CRITIQUE
        |
        v
CLASSIFY FINDING
 defect | evidence gap | resolved defect | maturity opportunity
        |
        v
BOUND REMEDIATION
        |
        v
IMPLEMENT / DOCUMENT
        |
        v
DETERMINISTIC QA + INDEPENDENT REVIEW
        |
        v
BANK EVIDENCE
        |
        v
GENERALIZABLE?
  yes -> BACKFILL FRAMEWORK -> FREEZE / VERSION / REUSE
   no -> PRODUCT-LOCAL CLOSE

CONTROL law: external model review, architecture assessment and adversarial critique may propose findings; they may not silently mutate authority. Generalizable improvements enter the framework only after bounded remediation, verification, evidence banking and versioned acceptance.

What Revision 0.3 now carries

final Assessment Evidence HTML;
final Overview and case-study presentation artifacts;
persisted Gemini, OpenAI, Grok, GLM and Claude raw evaluator returns;
complete blind Gemini architect-aptitude audit;
MySmartRouter 263/0 banked QA evidence;
MyFlightWatcher acceptance, integration and state/recovery payloads;
V3 operating manual, manifest and SHA-256 verification.

What stays separate

assessment findings do not replace V3 operating authority;
architecture capability and architect aptitude remain different constructs;
framework maturity remains separate from product/release readiness;
marketing scores are not imported into executor or reviewer control logic;
secret values and unsupported production claims remain excluded.

11 · Flagship Adoption

Use V4 as MySmartRouter's mandatory engineering operating framework.

MySmartRouter must not merely be “documented by” the framework. It must bootstrap from current V4 authority, demonstrate applicable VPL-GL-01–14 conformance, use its governed gates, and bank an end-to-end proof chain. Runtime implementation is verified separately; a reference to a control is not proof it is implemented.

Project control package

Recommended project-control tree

/MySmartRouter_Control/
  PROJECT.md
  STATE.yaml
  DECISIONS.md
  ESCALATIONS.md
  ACTIVE_DIRECTIVE.md
  SOURCE_MANIFEST.yaml
  GATE_READINESS_PACKET.json
  ACCEPTANCE_EVIDENCE_MATRIX.md
  HUMAN_DECISION_TRACE.md
  /evidence/
  /releases/
  /incidents/

Mandatory inherited behaviors

Bootstrap master-control refresh
authority + environment freshness
source freeze before material work
GPT Scheduled Tasks governance scheduling; runtime capability verified per role
specialized QA/review/release/database/deploy agents
historical 20–30 scenario target, expanded by risk and protected requirements; counts alone never establish PASS
real provider/DB/runtime proof
cold state/recovery/rollback proof
independent review
live deploy verification
banked architecture traceability

Reusable principle: future apps follow the same bootstrap, state, automation, readiness, QA, review, release/deploy and evidence architecture. Only the product-specific acceptance criteria, domain architecture, integrations and risk profile change.

Framework Improvement · September 12, 2026

What MySmartRouter V5.1 changed in the VPL Build Framework

Feature-complete boundary: MySmartRouter V5.1 is now treated as the feature-complete staging baseline. The next iteration is a pure defect-remediation and verification cycle. New capability ideas are captured separately and do not silently expand the hotfix.

1. One mutable authority, explicit supersession

Long-running builds accumulate stale instructions. V5.1 proved that appending new decisions is not enough: superseded rules must be explicitly marked as superseded, and downstream test plans must be regenerated from the current authority. A continuation model must read the current locked specification before issuing tests or code changes.

2. Bugs + UX in one governed hotfix

User-facing defects and functional defects are tracked together when they affect the same release. Severity still distinguishes blockers from polish, but a cosmetic-only “later wave” is not allowed to leave obvious product drift in a release candidate.

3. Grouped test blocks, individual adjudication

Testing should be fast enough for a human operator. Related controls are exercised in compact blocks, while each result still receives its own PASS / DEFECT / BLOCKED adjudication and evidence.

4. Live evidence outranks inherited certification

Prior PASS evidence never substitutes for current staging evidence after bytes change. Visible build ID, exact failing scenario, current runtime output and bounded regression are required before closure.

5. Capability matrices prevent orphaned features

Multi-provider products need an explicit model × provider × modality capability matrix. A provider reference is not a feature until configuration, credential status, model inventory, price/health evidence, telemetry and user-facing controls are all reachable.

6. General settings vs section settings

Cross-application settings belong in one General Settings plane. Mode-specific defaults and provider eligibility belong in the relevant section. This reduces duplicated credentials, hidden prerequisites and inconsistent controls.

7. Persistent shell is a product invariant

Reports, Diagnostics, Help, Settings, history and media remain inside the same branded navigation shell. Secondary utilities should not feel like separate applications.

8. Context is a workflow, not a storage brand

Users should think in terms of reusable context, not internal “Library” implementation details. Session History OPEN becomes a prepared follow-on state, supports multi-source context with provenance, and never auto-submits a provider call.

9. Source-to-package correspondence is mechanical

Production candidates must be byte-correspondent to certified source. Git object identity, SHA-256 reconciliation, secret scan, runtime lint and deterministic manifesting belong in the packaging gate—not in reviewer intuition.

10. Rollback is a complete tree swap

Deployment and rollback use immutable directory/tree replacement. Overlay rollback is prohibited because release-only files can survive as orphans.

11. Runtime boundaries are explicit

A product package documents what it does not own. MySmartRouter PHP runtime, the separate VPL Telegram Node runtime, private configuration, Lovable downstream design work and canonical Git authority remain separately governed.

12. Anti-drift refresh becomes operational control

Framework persistence uses Bootstrap as the control source: use GPT Scheduled Tasks as the default VPL scheduler; retain GitHub Actions for deterministic CI/deployment and Hostinger cron only for product/runtime-specific jobs. Every route surfaces current authority/stage without silently widening scope or mutating production.

New framework gate	Required evidence	Failure prevented
Feature Freeze Gate	Feature-complete declaration + deferred enhancement register	Scope growth during stabilization
Authority Freshness Gate	Current locked spec read + superseded-rule scan	Instruction drift
Provider Capability Gate	Config + inventory + pricing/health + model mapping	Orphaned integrations
UX Consistency Gate	Persistent shell, global controls, responsive parity	Fragmented product experience
Package Correspondence Gate	Git blob/object evidence + exact package hash reconciliation	Checkout/line-ending/source drift
Rollback Gate	Immutable pre-deploy tree + atomic swap instructions	Orphaned release files
Independent Review Chain	Claude engineering review → Cursor implementation → Claude verification → Gemini → DeepSeek	Self-certification bias

Technology patterns now formalized

VPL products can use multi-model inference routes, media-specific PAYG providers, Google Drive persistence, Telegram/Pushover notifications, Hostinger cron, GitHub/GitHub Actions and Lovable as downstream design execution—provided each integration is bounded by configuration, telemetry, provenance and independent review.

OpenRouterMulti-model routing

API MartAPI marketplace

TelnyxVoice / communications

RunwareImage generation

ReplicateModel execution

RunwayVideo / media AI

Stability AIGenerative media

Google DriveGovernance / evidence

TelegramMobile control

PushoverLegacy attention routing

GitHub ActionsCI / scheduled automation

HostingerHosting / runtime services

LovableDesign / app execution

12 · Portable Framework Kit

Frozen integrity artifacts + pre-extracted inspection trees.

Complete ZIP directory structure

VPL_BUILD_FRAMEWORK_MASTER_REV_0_2_2026-09-07/
├── 00_MASTER/
│   ├── VPL_BUILD_FRAMEWORK_CONSOLIDATED_REFERENCE.html
│   ├── VPL_BUILD_FRAMEWORK_MASTER_REFERENCE.md
│   ├── LIVE_AUTHORITY_PACKAGE_REGISTRY.md
│   └── PACKAGE_MANIFEST.json
├── 01_AUTHORITY/
├── 02_STARTUP_READINESS/
├── 03_AUTOMATION_AGENTS/
├── 04_MODULES/
├── 05_DIRECTIVES/
├── 06_STATE_EVIDENCE/
├── 07_BUILD_CREATE_TEMPLATES/
│   ├── Build - Create Templates.zip
│   └── PRE_EXTRACTED/
├── 08_ASSESSMENT_EVIDENCE/
│   ├── Assessment_Evidence_Assets.zip
│   └── PRE_EXTRACTED/
├── 09_MYSMARTROUTER_ADOPTION/
├── 10_SCHEMAS_TEMPLATES/
└── 11_LINEAGE_POINTERS/

Why both ZIP + pre-extracted? The assessment explicitly identified evaluator/access friction as an evidence problem. The master package preserves frozen source packages for integrity while also carrying pre-extracted trees so humans and agents can inspect content without an extraction dependency.

13 · Live Authority and Supporting Package

All package families are listed here. One ZIP carries the complete handoff.

Use the live links when you need the continuously updated Drive authority. Use the canonical ZIP when handing the framework to MySmartRouter, another product, Cursor, an engineer, architect or reviewer.

VPL Build Framework — Complete Enterprise Package

Revision 0.3 remains a historical portable handoff: operative V3 authority, Bootstrap/readiness controls, agent portfolio, modules, templates, schemas, MySmartRouter adoption blueprint, and the final complete Assessment Evidence Asset Pack with raw evaluator returns and machine-readable QA/state evidence.

Download Master Rev 0.3 ZIP

All framework Markdown authorities, modules, path/location registry data, assessment evidence, and manifests are included in the single master ZIP. No secure-folder access is required to use the portable framework package.

Package	Purpose	Included in ZIP	Status
Master Launch Authority	Historical Revision 0.3 master HTML + Markdown + portable ZIP	00_MASTER/	MASTER
V3 Architecture	Plane separation, Git-first, persistence-first, deployment/recovery architecture	`01_AUTHORITY/VPL_BUILD_ARCHITECTURE.md`	CURRENT
V3 Final Operating Manual	Executive operating law, authority, risk, autonomy, refresh, production gates	`01_AUTHORITY/VPL_BUILD_FRAMEWORK_V3_FINAL_OPERATING_MANUAL.md`	CURRENT
V3 CONTROL	Mandatory load order and locked control-plane rules	`01_AUTHORITY/VPL_BUILD_FRAMEWORK_CONTROL_V3.0.md`	CURRENT
V3 Baseline	Full inherited V3 baseline and operational lineage	`01_AUTHORITY/VPL_BUILD_FRAMEWORK_V3_BASELINE.md`	CURRENT
V3 Errata / Transition / Regression	Risk clarifications, transition gates, QA/lineage	`01_AUTHORITY`	CURRENT
Cursor Automation Control	Historical Cursor-exclusive preference; superseded for V4 by GPT scheduled-agent default	`03_AUTOMATION_AGENTS/VPL_V3_CURSOR_AUTOMATION_AGENT_CONTROL_AMENDMENT_V1.md`	CURRENT
Autonomous Agent Control	NEXT/REVIEW ownership, event schema, no-self-certification, bounded repair	`03_AUTOMATION_AGENTS/AUTONOMOUS_AGENT_CONTROL_MODULE_V3_FINAL.md`	FINAL
Bootstrap / V3.2 pragmatic recovery lineage	Source-before-memory, path/environment reconciliation, strategy pivot, frustration controls	`02_STARTUP_READINESS`	CURRENT
Engineering Gate Readiness	18-field readiness packet and no-unprepared-gate law	`02_STARTUP_READINESS/ENGINEERING_OVERSIGHT_GATE_READINESS_MODULE_V3_1.md`	ACTIVE
Permission / Capability Preflight	Actor-resource-operation access proof and PA readiness states	`02_STARTUP_READINESS/STARTUP_PERMISSION_CAPABILITY_PREFLIGHT_PA_MODULE_V3_1.md`	ACTIVE
Project Bootstrap	Create V3-ready project control/state/source/evidence structure	`04_MODULES/PROJECT_BOOTSTRAP_MODULE_V3_1.md`	APPROVED
GitHub Governance	Durable source, branch, commit, PR/cloud handoff rules	`04_MODULES/GITHUB_GOVERNANCE_MODULE_V3_1.md`	APPROVED
Hostinger Deployment	Production target/deployment contract and validation lineage	`04_MODULES/HOSTINGER_DEPLOYMENT_MODULE_V3_1.md`	APPROVED
Evidence Banking	Durable evidence/state banking	`04_MODULES/EVIDENCE_BANKING_MODULE_V3_1.md`	APPROVED
Rollback / Recovery	Last-known-good and controlled recovery	`04_MODULES/ROLLBACK_RECOVERY_MODULE_V3_1.md`	APPROVED
Health / Monitoring	Health checks and transition alerts	`04_MODULES/HEALTH_MONITORING_MODULE_V3_1.md`	APPROVED
Secrets / Credentials	Least-privilege secret lifecycle and non-disclosure	`04_MODULES/SECRETS_CREDENTIALS_MODULE_V3_1.md`	APPROVED
Executor Routing	Route GPT/Cursor/Claude/provider work to correct logical role	`04_MODULES/EXECUTOR_ROUTING_MODULE_V3_1.md`	APPROVED
Design Precise Change	Surgical change / render QA / overwrite controls	`04_MODULES/DESIGN_PRECISE_CHANGE_MODULE_V3_1.md`	ACTIVE
Delicate Work	Preservation-first high-risk artifact editing controls	`04_MODULES/DELICATE_WORK_MODULE.md`	ACTIVE
Static Asset Publishing	HTML/CSS/JS/image publishing controls	`04_MODULES/STATIC_ASSET_PUBLISHING_MODULE_V3_1.md`	APPROVED
Case Study Publishing	Frequent lightweight HTML edit/publish/rollback	`04_MODULES/CASE_STUDY_PUBLISHING_MODULE_V3_1.md`	APPROVED
Guided / I Never Did This Before	First-party-doc-first guided UI support	`04_MODULES/I_NEVER_DID_THIS_BEFORE_MODULE_V3_1.md`	MANDATORY
Telegram + Mobile Operations	Exception/query/status transport and safe phone operations	`04_MODULES`	ACTIVE
Remote Access / Tailscale	Private mobile-to-persistent-Windows recovery/interactive path	`04_MODULES/REMOTE_ACCESS_TAILSCALE_MODULE_V3_1.md`	APPROVED
Notification	Low-noise exception/status event notifications	`04_MODULES/NOTIFICATION_MODULE_V3_1.md`	APPROVED
Build / Create / Certification Templates	Portable prompt SDK, manifesto, sprint, mockup and certification assets	`07_BUILD_CREATE_TEMPLATES`	TEMPLATE AUTHORITY
Assessment Evidence	Frozen assessment ZIP + pre-extracted evaluator evidence tree	`08_ASSESSMENT_EVIDENCE`	SUPPORTING EVIDENCE
MySmartRouter Adoption Blueprint	Product-specific inheritance blueprint for flagship architecture proof	`09_MYSMARTROUTER_ADOPTION`	ADOPTION

Authority rule: the portable ZIP preserves the complete Revision 0.3 handoff snapshot and its then-current status labels. Current published work follows V4 FINAL / REV 006; REV007 R4 remains candidate/HOLD; V3/V3.2 records remain historical. Refresh the applicable V4 controls before reuse. This table is retained for lineage and does not reactivate a candidate or superseded module.

V4 maturation · continuous engineering control

Every wave leaves a safer next step.

The V4 FINAL revision turns preservation, feedback and progression into explicit operating contracts, while retaining the historical architecture and evidence below.

V4.0 FINAL · REV 006 · current published operating authority

Build on accepted work. Prove each next step.

V4 carries forward the portfolio’s engineering lessons into one go-forward framework: three evidence-selected build paths, seven progressive checkpoints, two-baseline regression comparison, earlier owner feedback and independent-model challenge throughout material work. The intent is faster learning without losing what already works.

Choose the right execution path

Manual, Light Build and MySmartRouter are peer options. Select by actual capability, risk and coordination value; escalate only the component that needs it.

Make preservation measurable

Compare each candidate with both the last accepted checkpoint and the locked baseline. Keep requirements, visual behavior, source identity and untested cases visible.

Connect tools to accountable outcomes

Git and Drive, Hostinger API and Git deployment, membership, payment and marketing each have a defined responsibility, proof requirement and recovery boundary.

FINAL identifies owner-directed operating guidelines. Historical assessments retain their original scope and dates; independent framework assurance and each product’s runtime acceptance remain separately evidenced.

Three routes. One quality standard.

Path	Choose from evidence	Operating contract
Manual	A real native interaction, local toolchain or specialist capability is needed; persistent orchestration adds little value.	Exact prepared session and pinned directive → bounded executor wave → independent review and GPT adjudication. Owner-paced transport stays owner-paced.
Light Build	A contained application or component can be inspected, changed, tested and packaged directly with equal or lower risk.	GPT-direct work, early real BETA/UAT, bounded repair, generalization and the same release evidence. A repository or a large corpus alone does not require another executor.
MySmartRouter	Multiple actors, services or stages gain enough from durable coordination to justify its added operational complexity.	Current authority, safe dispatch, source-matched handoffs, restart/duplicate protection, independent gates and mandatory VPL conformance.

Record path, cadence and location separately: Manual / Light Build / MySmartRouter; owner-paced / bounded automatic; local / remote / hybrid. New identity, payment, regulated-data, complex-migration or worker requirements trigger component reassessment—not automatic approval because a module exists.

G0–G6: checkpoint and release progression

Gate	Required evidence	Progression boundary
G0 · Re-anchor	Current V4 authority; exact accepted source, data and configuration; locked behaviors; selected path and rollback.	Unknown or mixed source stops mutation. Completed work stays preserved.
G1 · Bound the change	Requirement IDs; touched and untouched surfaces; risk; executable test plan; reviewer and return destination.	Prepare the actual environment before implementation; do not discover predictable access gaps downstream.
G2 · Freeze the candidate	Exact diff and candidate identity; smoke, lint, security and failing-first defect evidence where applicable.	A working BETA can be shared early. It is not yet an accepted checkpoint.
G3 · Compare and challenge	Last checkpoint → candidate and locked baseline → candidate; invariant tests; affected integrations; required owner UAT and independent review.	Any mandatory failed, skipped or unverified case holds the affected promotion.
G4 · Accept and bank	Source-matched tests and reviews; closed blockers; accepted known gaps; verified durable readback.	Advance only the accepted checkpoint. Preserve the prior checkpoint and an exact restore target.
G5 · Prove the release candidate	Cumulative regression, real loader and integration contracts, clean extraction/staging, independent release review and required owner acceptance.	Mock-only evidence, a stale review or a different candidate cannot certify this release.
G6 · Validate production	One selected API or Git deployment route; exact approved candidate; provider receipt; ordinary and cache-aware live checks; recovery evidence.	Deployment passes only when observed public behavior agrees; otherwise stop and recover.

Two baselines, not one

Compare the candidate against the last accepted checkpoint for the immediate change, and against the locked release or UX baseline for cumulative preservation. Reuse a reproducible harness, environment and test data. Track each protected requirement as preserved, improved, added, explicitly changed, regressed or unverified.

Feedback during the build

Actively solicit qualified independent-model review at architecture decisions, material checkpoints, recurring defects and release. Reviewers inspect the same frozen source and report evidence, severity and gaps. Executor self-review, a prepared prompt or a favorable score is not independent acceptance.

Early UAT; honest promotion

Return a real working BETA as soon as a coherent journey exists. Owner-observed failures override the affected automated PASS. Keep failed, blocked and not-run cases visible; never rebase tests or screenshots merely to turn a regression green.

A working candidate, an accepted checkpoint and a Recovery Anchor are different evidence states. A mandatory unresolved review or test holds dependent promotion; useful discovery and clearly labeled early UAT can continue. No numeric score overrides a critical/high release blocker.

V4 maturation · complete module consideration

One framework. Explicit responsibilities.

Bootstrap considers 21 inherited module families, three commercial contracts and one proposed support extension. Applicable controls are loaded before action; excluded or conditional families receive a reasoned disposition.

Control family	Retained and expanded coverage
Bootstrap & governance	Bootstrap and executive communication; project Bootstrap; executor environment/access; executor routing; autonomous-agent control; GitHub governance.
Assurance & operations	Evidence and banking; health and monitoring; rollback/recovery; secrets/credentials; technical deep-dive recalibration.
Delivery & communication	Hostinger deployment; case-study publishing; static-asset publishing; guided support; mobile operations; notifications; Telegram control; remote access/Tailscale.
Preserved candidates	Delicate Work and Design Precise Change remain explicitly considered candidates. Existing preservation obligations continue; a candidate label is not silent activation.
V4 commercial contracts	aMember membership; Stripe payments; GetResponse lifecycle. These are first-class contracts with product-specific installation, acceptance and activation gates.
Proposed extension	Support-email automation is retained as a proposed, separately authorized capability, with customer isolation, draft-first scope, loop prevention and escalation.

Hostinger API + Git

Both are established VPL connection routes. Git provides repeatable source-led promotion; API/MCP operations provide a separately authenticated hosting route when the required action is exposed. Select one release path, verify the target, preserve rollback and reconcile direct patches to Git before the next automatic deployment.

Cursor + Claude: Git and Drive

Both have Git and Google Drive connections. Git carries implementation identity; Drive carries control and evidence. Verify the exact actor, session, permission and operation instead of denying a known connection or inheriting another actor’s PASS.

Evidence before activation

Fourteen logical agent roles remain preserved. A role contract, created task, executed pilot and verified active service are separate states. Scheduling never expands scope, certifies a deployment or installs universal memory across unrelated chats.

V4 expansion · membership, payments & scheduled orchestration

From a collection of tools to reusable operating contracts.

V4 connects the existing development stack to a governed customer lifecycle: lead capture in GetResponse, payment through Stripe, account and entitlement control in aMember, and product access backed by explicit evidence. These are reusable framework contracts; implementation and activation are verified separately for each product.

aMember

Reusable account, membership and protected-access integration. V4 defines entitlement checks, payment-to-membership mapping, safe return-to-app behavior and recovery tests.

Stripe

Payment and checkout integration with verified server-side outcomes, existing product/price reuse, authenticated events and duplicate-safe fulfillment.

ChatGPT Scheduled Tasks

Capability-gated scheduled orchestration and read-only readiness pilots. Current authority is reloaded on each invocation; defined roles, created tasks and verified runtime remain distinct.

The aMember and Stripe marks are embedded from their official websites; the scheduled-task card reuses this portfolio’s existing OpenAI identification mark. No new external logo dependency is required. Technology inclusion identifies its role in the portfolio or framework, not a claim that every service is live in every application.

Customer lifecycle: visitor → optional lead capture → offer and checkout → server-verified payment → idempotent membership provisioning → authorized onboarding → authenticated login and entitlement validation → protected product access.

Stripe establishes payment outcomes; aMember establishes membership access; GetResponse manages approved marketing lifecycle. Test the full journey and partial-failure recovery, not only isolated vendor screens.

MySmartRouter · binding operating guidance

VPL conformance is required, not optional.

MySmartRouter and its reviewers must respect the locked VPL-GL-01–14 requirements: current authority; correct project and source; preserved accepted work; evidence-based routing; complete module consideration; actor-specific readiness; continuous regression; early UAT; independent review; gated banking; bounded repair and safe concurrency; secret and owner boundaries; governed deployment/recovery; and freshness with truthful communication.

Before dispatch or promotion, map every applicable requirement to current implementation, tests and evidence. Missing required conformance holds the affected action. Product-specific architecture stays in the product; applying the framework does not imply every planned runtime adaptation is already implemented.

14 · Revision Record

Master document lineage

V4.0 RC1 · Historical audit candidate

GPT scheduled-agent default, every-invocation Bootstrap, preserved V3 architecture, sequential migration of fourteen roles, and independent Claude/DeepSeek/Gemini review. Bootstrap pilot created; other migrations pending.

Version 2.5 · Historical predecessor

Balanced operating-path presentation: Manual, Light Build, and MySmartRouter are explicit peer paths selected by a neutral Build Path Assessment. Human-in-the-loop is promoted to a first-class governance principle, while NEXT/REVIEW remain routine system events. Historical change detail remains in the V3 changelog rather than dominating this operating reference.

Version 2.1 · 2026-09-13

Bootstrap-first enterprise refresh: BOOTSTRAP becomes the first/master control; the live tree manifest and shorthand registry are explicit; edit framework routes changes to the correct owner; provider-currentness and actor-specific environment prep are mandatory; manual stage naming ties 1:1 across recap/directive/returns; the public structure map reflects current V3 controls, candidates and reference boundaries.

Revision 0.1 · 2026-09-07

Initial consolidated launch reference. Corrected the major Cursor Automation/Hostinger plane distinction but remained too abbreviated for enterprise product handoff.

Revision 0.3 · 2026-09-07

Enterprise master rebuild: full package registry, current authorities, agent contracts/portfolio, schemas/code blocks, readiness, autonomy, precise/delicate work, QA/recovery, release/database/deploy, traceability, MySmartRouter adoption, certification templates, assessment evidence and one complete ZIP.

V4.0 FINAL · REV 006 · September 23, 2026

Go-forward V4 authority with V3 sunset; complete module consideration; clearer Manual/Light Build/MySmartRouter routing; G0–G6 promotion gates; two-baseline regression comparison; model feedback during material work; mandatory MySmartRouter guidelines; Hostinger API and Git; and reusable aMember, Stripe and GetResponse contracts. Public iteration E1 enhances this existing reference without replacing its historical evidence or visual structure.

Current audit cycle · September 23, 2026

Public evidence follows the review cycle; it does not outrun it.

Published framework authority remains V4 REV006. REV007 R4 is a pre-audit candidate on HOLD after independent Claude review identified bounded structural defects. Gemini’s September 23 controlled reassessment of Peter DeCaro returned 94.5/100 · Expert, up from its September 1 baseline of 93.75 while lowering Product / System Integration and preserving runtime limitations. The current audit artifact is F:\My Drive\VPL\Framework\DECARO ARCHITECT ASSESSMENT_9_23_26.docx. Historical assessments retain their original scope and dates.

One first file. One current tree. One build-driving control surface.

First file

Current providers

Environment first

Stage 1:1

edit framework

add shorthand / add to shorthand

list shorthand

Build

Build Review

The file tree is a control surface, not housekeeping.

Authority / routing

Source / implementation

Reference / lineage

Three peer build paths. One evidence-based routing decision.

01 · Manual

03 · Light Build

02 · MySmartRouter

Automate routine mechanics. Keep human judgment where it adds value.

Human owns

System owns

Practical best-practice pattern

Separate the planes. Make every handoff observable.

Governance

Implementation

Persistent Automation

Execution

Verification

Independent Review

Runtime

Banking

Git is a source plane, not an automatic reason to invoke Cursor.

GPT-direct first

Escalate the component

Measure complexity correctly

Mandatory Executor Fit Record

Executor Fit Record

Rules that prevent drift, owner babysitting and false readiness.

Source before memory

Connected ≠ usable

No gate opens unprepared

Freshness is mandatory

Exact source identity

No self-certification

Silent routine autonomy

Negative evidence persists

Bounded repair + pivot

Human attention boundary

Evidence caps maturity

Preserve accepted work

One governed lifecycle. Three peer operating paths.

Light Build · GPT-Direct Engineering

Manual · GPT-Led

MySmartRouter · Orchestrated

Wave 1 · Core Architecture + State

Wave 2 · Runtime + Security + Observability

Wave 3 · Convergence + Release

Prove the build can execute before dispatch.

18-field Gate Readiness Packet

Permission Dependency Map

Specialized agents are capabilities invoked by the selected path—not the default path itself.

Persistent Build Agent

VPL Bootstrap Master Control

VPL Independent QA / Review Agent

Independent Review Agent / Router

Release Agent

VPL Database Agent

Hostinger MySQL Provisioning & Maintenance Agent

Hostinger Deploy Agent

Evidence Banking Agent

Recovery / Rollback Agent

Notification / Status Agent

Hostinger Domain Discovery & Availability Agent

VPL Daily AI Intelligence Ingestion Agent

VPL Integration / Handoff Validator Agent

NEXT and REVIEW are events, not owner chores.

Retry / strategy pivot

Human exception boundary

Normal build, precise change and delicate work are not the same thing.

Normal governed build

`edit framework`

`add shorthand` / `add to shorthand`

`list shorthand`

`Build`

`Build Review`