[aybvip]

PiRC4: Pi Visual Builder AI-Driven No-Code Platform

Overview

This PR proposes Pi Visual Builder an Advanced Mode for Pi App Studio that combines the power of an AI Agent (Orchestrator) with professional-grade visual development tools, enabling every Pioneer to build complex, trust-enabled commerce apps without writing code.

Why This Matters

Pi App Studio's AI can generate apps from chat, but Pioneers currently have no way to control, customize, or refine the generated output. Pi Visual Builder closes this gap.

What's Included

6 Documentation Files:

#	Document	Description
1	Component Specification	20+ visual components (Layout, Display, Input, Navigation, Pi-Native)
2	Logic Blocks	Event blocks, logic blocks, data blocks, Pi SDK blocks
3	Code Generation	React/TS + HTML/CSS output, Pi SDK API, build pipeline
4	Component Marketplace	Publishing, monetization, verification, discovery
5	Example Apps	5 complete app examples (e-commerce, services, community, loyalty, HTML)
6	Editor UI Layout	Professional editor: canvas, property editor, AI assistant, workflow, data, styles

4 Interactive Mockups (Mobile-Optimized, Lucide Icons):

• Design Tab Visual canvas with elements tree on left and AI assistant
• Workflow Tab Step-by-step logic chains with Pi payment actions
• Data Tab Relational database with PiDCTP-linked fields and privacy rules
• Styles Tab Color/font variables, element styles, live preview with AI

Five Core Pillars

1. Design Tab: Pixel-perfect canvas with Elements Tree on the left and responsive engine
2. Workflow Tab: Step-by-step visual logic flows (When -> Do)
3. Data Tab: Relational database manager with field-level privacy and PiDCTP state mapping
4. Styles Tab: Color/font variables, element styles, and live preview with AI dark theme generation
5. Plugin Marketplace: Monetized ecosystem for community-built components and logic

PiRC3 (PiDCTP) Integration

Pi Visual Builder serves as the visual frontend for PiRC3 smart contract interactions:

• Verify Seller Reputation
• Create Milestone Escrow
• Lodge Dispute Complaint
• Award Trusted Merchant Badge

Related

• PiRC3 PR: PiRC3: Pi Decentralized Commerce & Trust Protocol (PiDCTP) - Complete Spec & Soroban Implementation #378
• Discussion: PiRC3 & PiRC4: Closing the Commerce Trust Gap with Decentralized Trust & AI No-Code #380, PiRC4: The Ultimate AI-Driven No-Code Platform (Visual Development) #381
• Full Repository: https://github.com/aybvip/Pi-Visual-Builder

License

Idea & Proposal License Original concept by Ayoub (aybvip). Implementation rights belong exclusively to Pi Network.

---

This proposal empowers every Pioneer to build professional, trust-enabled commerce apps without writing code, bridging the gap between AI generation and professional development.

[aybvip]

Measured context for this proposal

This comment adds measurement, not argument. No part of it asks Pi to adopt
anything; adoption stays not-claimed.

Everything below is re-checkable by anyone with Node.js >= 20, no npm install,
read-only. Each figure names the command that produced it.

---

1. What the public read surface actually returns today

The proposal describes a visual builder. The builder ultimately has to talk to
the Pi network, and the shape of that surface is measurable. Measured
2026-10-20 against https://rpc.testnet.minepi.com (node 28.0.1,
protocol 28), re-measured live just now:

pass=10  fail=0  error=0   (10/10 checks still match the recorded rows)

A transparent note on what that does not say: fail would mean an endpoint
moved; error means a check could not be evaluated and draws no conclusion.
An unreachable endpoint yields error for every check, never fail.

Reproduce:

git clone https://github.com/aybvip/pi-api-contract-registry
cd pi-api-contract-registry
node registry-cli.mjs --conformance   # reads only; never signs or submits

2. Nine recorded departures from what a spec-following client expects

These are the parts a visual builder would silently get wrong. All nine are
scoped version-scoped — none is claimed to be universal:

ID	Method	Severity	The trap
D-SIM-1	simulateTransaction	high	a failure is not a JSON-RPC error: HTTP 200, result present, result.error="Could not unmarshal transaction", result.latestLedger=0
D-TX-1	getTransaction	high	the type of events depends on status: {} (object) on NOT_FOUND, an array on success
D-CON-1	getContractData	high	method absent on this endpoint: -32601 "method not found" (tutorials still show it)
D-EVT-1	getEvents	medium	two timestamp encodings on one endpoint: event.ledgerClosedAt is ISO 8601 Z-suffixed, result.latestLedgerCloseTime is Unix seconds as a string
D-ENT-1	getLedgerEntries	medium	an empty key list is a server error (-32603), not an empty result
D-TX-2	getTransaction	medium	NOT_FOUND is signalled inside a success envelope; ledger=0 and createdAt="0" are placeholders, not data
D-FEE-1	getFeeStats	medium	fee figures are JSON strings ("max":"100000", "p50":"100000", "transactionCount":"13") while ledgerCount is a number
D-FEE-2	getFeeStats	low	the two fee objects cover different windows: sorobanInclusionFee.ledgerCount=50, inclusionFee.ledgerCount=10
D-VER-1	getVersionInfo	low	buildTimestamp is "2026-09-16T13:30:54" — no timezone designator

Separately measured and also worth a builder's attention: a getEvents page is
capped at 100 events and a larger limit is ignored.

node registry-cli.mjs --drift

Each of these is asserted by 465 offline checks in the same repository
(node test/registry.test.mjs), so a later edit that contradicts the recorded
measurement fails a test rather than passing silently.

3. The failure path, not just the success path

A builder that only handles the happy path reports success on failure. On this
endpoint most rejections arrive at HTTP 200 with a JSON-RPC error; one shape
returns HTTP 204 with an empty body. A client that checks HTTP status alone
cannot tell them apart.

15 measured failure shapes are catalogued and can be replayed offline — no
network, so a client can be tested without any load on Pi:

git clone https://github.com/aybvip/pi-chaos-lab
cd pi-chaos-lab
node chaos-cli.mjs --demo      # a naive client and a guarded client, SAME HTTP status, opposite verdicts
node chaos-cli.mjs --probe     # live re-measurement, invalid requests only

4. The measurable state of this channel

Recorded because it changes what a proposer should do, not as a statement about
anyone's intent. Re-measured live just now:

repo:                  PiNetwork/PiRC
open_pull_requests:    94
closed_pull_requests:  23
merged_pull_requests:   0
readme_nonempty_lines:  2
main_last_push:        2026-04-17T02:22:25Z

git clone https://github.com/aybvip/pi-gap-index
cd pi-gap-index
node gaps.mjs --probe          # G4 re-measures the channel

What this does not show: intent, priority, capacity, or that any specific
proposal will or will not be adopted. Those are not measurable from a
repository. A channel can be dormant for reasons that are not observable here,
so none are asserted.

---

The point of this comment

A proposal on this channel is normally text. The difference here is that the
claims above are not asserted — they are reproducible: each one names a
command, and the command can be run by anyone, including against a later version
of the endpoint, and will itself report when a recorded shape has moved.

This is offered as supporting measurement for a proposal that already exists.
It asks for no change of outcome. If any figure is wrong, re-running the command
will say so, and the correction is welcome.

What is not claimed

• Not claimed: that Pi will adopt, endorse, or is obliged to adopt anything.
• Not claimed: that any of this is a first — the prior-art position is "no prior work found".
• Not claimed: that a passing check proves a client is correct or safe. A passing
  check means a recorded shape was still observed, and nothing more.
• Not claimed: that any figure holds outside the endpoint, version and date recorded.

Repositories

Repository	What it measures
pi-api-contract-registry	the measured RPC surface as a dated registry, with drift separated from documented expectation
pi-chaos-lab	the failure shapes, replayable offline
pi-gap-index	measured gaps in the public surface, each with a reference spec and conformance tests
pi-event-integrity	which ledger ranges can be proven covered, with a replayable SHA-256 digest
pi-contract-simulator	how contract simulation failures classify on Pi Testnet (node sim.mjs --failures; 224 offline checks)

All read-only, zero-dependency, no keys, no signing, no submissions.