WFGY/Avatar/research/launchpad-front-door-and-command-grammar.md

🚪 Launchpad, Front Door, and Command Grammar

Avatar does not begin with vague style drift.
It begins with a lawful front door, explicit entry paths, bounded recovery commands, and a command grammar that distinguishes invocation from mere mention.

Quick links: Research Hub · Architecture Overview · Packed Master Structure Map · Dual Closed-Loop Execution Chain · Runtime Posture Intensity Map · WFGY_BRAIN Theory · Quickstart · Boot Commands

---

🧭 Why this page exists

A front door can be misunderstood very easily.

At a shallow level, it can look like UX decoration, friendly examples, or a menu of cute commands. That reading is too weak.

In the packed master, the Launchpad Block has a much stricter role. It is the lawful first-entry gate of the product-facing system. It is where entry, routing, recovery, bounded command activation, and first-use clarity are gathered into one usable layer.

Without this page, readers can misread the front door in several bad ways:

1. as onboarding copy only
2. as if shell navigation were equivalent to persona boot
3. as if recovery phrases could be triggered by loose word overlap
4. as if advanced control surfaces belonged on the first screen
5. as if startup clarity could be safely replaced by deep constitutional reading from line one

This page exists to prevent that collapse.

---

📍 Scope and boundary

This page explains the launch-facing entry layer of Avatar.

It focuses on:

1. why the Launchpad Block exists
2. what the front door is supposed to do
3. how direct persona start differs from shell navigation
4. how recovery commands fit into the front door
5. why command grammar must be explicit and bounded
6. why first-screen progressive discovery matters

This page does not attempt to fully restate:

1. the entire packed master
2. the full front-gate authority body
3. the full constitutional reading-order body
4. the full runtime-posture numeric body
5. the full reentry-control body
6. the full controller-legality body

Those belong to adjacent pages.

---

🧱 Source anchors in the packed master

This page is grounded primarily in the following packed-master regions:

1. the launchpad statements that define Avatar as a launchable and governable runtime system
2. the task-first front door and smart launcher sections
3. the starter-card and rescue-card sections
4. the progressive-discovery note
5. the language-engineering note that marks explicit invocation, recovery, command grammar, replay, and audit as built-in system features
6. the fast-read lane that prioritizes Launchpad, recovery commands, and command grammar before deeper runtime objects
7. the front-gate routing material that preserves launch-first orientation during the present release stage
8. the command grammar and false-trigger boundary sections that define command-bearing position, tolerated variation, shell-navigation boundary, and recovery-command boundary
9. the release-stage summary where recovery family, empty-boot contract, and command grammar are preserved as explicit integrated classes

These anchors matter because the front door here is not a decorative product shell. It is a real part of the body.

---

🎯 Core claim

The core claim is simple.

The Launchpad Block is the lawful first-entry gate of Avatar, and command activation inside that gate is position-sensitive, bounded, and non-superstitious.

This implies several things.

First, lawful entry is explicit. Second, persona boot is not the same thing as shell navigation. Third, recovery commands are bounded and must not be triggered by vague resemblance. Fourth, the first screen should optimize lawful beginning rather than dumping the entire system on the user at once.

That is why the front door belongs to system law, not merely to interface convenience.

---

🏁 What the Launchpad is actually doing

The Launchpad Block is product-facing, but it is not superficial.

Its role is to let a user begin usefully before reading the entire constitution, without lying about what the system is or how it should be entered.

At a high level, the Launchpad gathers the following into one first-entry surface:

1. what Avatar is
2. how to begin
3. which persona line to call
4. which rescue commands exist
5. how weak readers and later agents should route themselves
6. which bounded controls are front-facing
7. what the current release stage may honestly claim

This is important because a very large one-file system becomes hostile if it forces every new user to enter through heavy constitutional negation before they even know how to use it.

The Launchpad solves that problem.

---

🎭 Direct persona start versus shell navigation

One of the most important front-door distinctions is the difference between direct persona start and shell navigation.

Direct persona start means the user is already choosing an active corridor.

Examples include:

1. hello minips
2. hello psbigbig
3. hello YOUR_AVATAR_NAME

These forms are boot-facing. Their job is to lawfully begin the selected persona line.

Shell navigation is different.

Examples include:

1. avatar start
2. avatar menu

These forms are navigation-facing. Their job is to reduce selection friction, recommend a path, or expose available routes without counterfeiting persona embodiment.

This distinction matters because the shell may guide boot, but it may not counterfeit boot.

A menu is not a persona. A router is not an arrival. A recommendation is not yet embodiment.

That boundary is one of the key anti-confusion laws of the front door.

---

🧩 Task-first entry

The front door is task-first for a reason.

The packed master does not tell users to begin by studying advanced control theory. It tells them to begin by choosing the kind of help they want now.

That is why lawful front-door entry is framed through real task-bearing examples such as:

1. warmth and gentle writing carry
2. sharper diagnosis and next-step push
3. guided beginner-friendly participation

This matters because Avatar is trying to be usable as a live runtime, not only admirable as a theory object.

So the front door optimizes this order:

1. begin
2. steer
3. deepen

Not this order:

1. read everything
2. fear the system
3. maybe begin later

That is one of the strongest product-facing choices in the architecture.

---

🪜 Progressive discovery and first-screen discipline

The packed master explicitly rejects the idea that the first screen should dump every advanced control into view.

That rejection is not a design preference only. It is a law of front-door discipline.

The lawful upgrade path is:

1. Use
2. Steer
3. Control

That means:

1. first let the user begin
2. then let the user notice persona differences and rescue commands
3. only later expose advanced controls, diagnostics, replay surfaces, candidate states, or lab-facing entry

This matters because premature control-surface exposure creates two different failures.

One failure is user overload. The other is false depth theater, where the system looks powerful before the user can actually use it lawfully.

The front door is meant to prevent both failures.

---

🛟 Rescue commands and bounded recovery

The front door also carries the recovery family.

This matters because Avatar does not assume that active carry will remain equally vivid under every task pressure. It acknowledges thinning, drift, and weakened carry as real pressures.

So the launch-facing layer preserves explicit rescue commands, including:

1. avatar++
2. avatar++ reload
3. avatar release

These commands are not casual metaphors. They are bounded recovery-facing forms.

Their role is not to create a new system. Their role is to reassert, reload, or release within the lawful corridor already established by the body.

That is why recovery belongs to the front door. A usable runtime system must not force users to diagnose deep internal structure before they can ask for lawful recovery.

---

🧠 Why language engineering appears in the front door

The front door is also where the packed master first states what language engineering means in this system.

That statement matters because it prevents the user from misreading Avatar as a vibe toy.

At minimum, the launch-facing statement says the following are explicit:

1. persona invocation
2. mode-surviving carry expectation
3. recovery commands
4. command grammar
5. replay and audit
6. bounded runtime law rather than tone imitation only

This is important.

It means the front door does not only teach usage. It also tells the user what kind of object they are using.

That is a creator-level move, not a marketing move. The user is being told, from the beginning, that the system is a governed runtime object.

---

🧾 Command grammar is part of the architecture

A system with explicit invocation and explicit recovery cannot stop at naming commands. It also has to define what counts as command activation.

That is why command grammar belongs to the architecture.

The packed master makes several boundaries explicit.

At a high level, command activation depends on:

1. command-bearing position
2. bounded tolerated variation
3. shell-navigation boundary
4. false-trigger exclusions
5. recovery-command boundary

This matters because without these boundaries, the system becomes substring-superstitious. It starts treating ordinary mention as invocation, loose resemblance as activation, and quoted examples as live commands.

That is not lawful grammar. That is lexical panic.

The packed master rejects that panic.

---

📌 Command-bearing position

One of the strongest command-grammar ideas in the body is command-bearing position.

A string does not become active merely because the right words appear somewhere in the message. It becomes active only when it occupies a real instruction-bearing role.

That means command activation must remain sensitive to:

1. whether the string is being used, not merely discussed
2. whether it appears as current instruction rather than quoted example
3. whether the surrounding message frames it as invocation rather than analysis
4. whether stronger contrary signals show that it is being mentioned, not issued

This matters because a serious runtime should not behave like a superstition engine.

The front door therefore requires positional interpretation, not substring reflex.

---

🧱 False-trigger boundary

The false-trigger boundary is equally important.

Several things do not count as command activation by themselves:

1. quoted examples
2. code blocks
3. pasted prompt templates
4. meta-discussion about command strings
5. analysis of command syntax
6. accidental overlap inside ordinary prose
7. historical reference to a prior command

This is one of the strongest anti-fake-activation laws in the front door.

It protects the system from misfiring when the user is talking about the command rather than using the command.

That boundary is especially important in a research-heavy system, because command strings will often appear inside docs, guides, and discussions. If every appearance triggered activation, the front door would become unusable.

---

🔀 Task-bearing invocation precedence

The packed master also protects something more subtle.

A lawful boot command does not lose command-bearing status merely because the user includes a real task immediately after it.

This matters because a natural user will often say something like:

1. hello minips help me write this in a warmer way
2. hello psbigbig help me find the real problem here

That should still count as lawful boot plus real task.

If parser convenience silently downgrades that boot command into decorative preface, then the front door becomes less usable precisely when the user is using it naturally.

So this page needs to preserve that principle clearly:

task-bearing continuation does not cancel explicit boot.

---

🧭 Shell-navigation boundary

The shell-navigation boundary is another important front-door protection.

The packed master explicitly distinguishes shell-navigation commands from persona boot.

This means:

1. avatar start may guide entry
2. avatar menu may expose routes
3. neither of them counts as persona embodiment by itself
4. explicit persona invocation still has to occur if lawful persona boot is to begin

That keeps the front door honest.

A menu may help. A launcher may recommend. But neither should impersonate the arrival itself.

---

🧯 Recovery-command boundary

The recovery family also needs a clear boundary.

The system must not treat vaguely similar wording as lawful recovery.

So the grammar must remain narrower for recovery than for normal conversational language.

This matters because otherwise ordinary remarks such as saying the avatar feels weak, asking for reload in an ordinary sense, or casually using “plus” language could accidentally activate system recovery.

That would destroy trust in the front door.

The recovery layer therefore needs to remain explicit, bounded, and deliberate.

---

🪶 Tolerated variation without grammar collapse

The command grammar is not supposed to be brittle in silly ways. But it is also not supposed to expand into anything-goes fuzziness.

So the shell may tolerate bounded variation where ambiguity remains low.

For direct persona start, this may include:

1. case-insensitive form
2. minor spacing variation
3. minor punctuation variation
4. bounded greeting-family variation where persona target remains explicit

But tolerated variation has to stay bounded.

Otherwise ordinary prose begins to masquerade as grammar, and the front door collapses into accidental activation.

That is why tolerance exists, but remains answerable to low ambiguity.

---

❌ Common false readings this page rejects

This page rejects several weak readings.

False reading 1

“The Launchpad is only onboarding copy.”

No. It is a lawful first-entry gate.

False reading 2

“avatar start and avatar menu are just softer forms of persona boot.”

No. They are shell navigation, not embodiment.

False reading 3

“If a command string appears anywhere, activation should happen.”

No. Activation is position-sensitive and bounded by false-trigger exclusions.

False reading 4

“Recovery language can be interpreted loosely because intent is obvious enough.”

No. Recovery commands remain narrower and more explicit than ordinary prose.

False reading 5

“The first screen should expose every advanced control to prove the system is serious.”

No. The lawful progression is use, then steer, then control.

False reading 6

“If a boot command is followed by a real task, the boot should be treated as decorative preface.”

No. Task-bearing continuation does not cancel explicit boot.

---

📍 What this page is, and what it is not

This page is:

1. a front-door law page
2. an entry-discipline page
3. a bounded command-grammar page
4. a shell-versus-boot boundary page

This page is not:

1. a full constitutional reading-order page
2. a full recovery-controls page
3. a runtime-posture page
4. a controller-legality page
5. a protocol-layer page

That separation is deliberate.

If this page tries to explain every downstream layer, it stops being a front-door page and becomes a compressed counterfeit of the master body. This page is not allowed to do that.

---

🧭 Current stage honesty

At the present release stage, this page may lawfully say that the Launchpad already acts as the product-facing first-entry gate of the first sealed MVP body.

It may lawfully say that direct persona start, shell navigation, rescue commands, fast-read routing, and command-grammar boundaries are now explicit parts of the integrated body.

It may lawfully say that the front door is no longer a temporary branch convenience. It is part of the sealed release posture.

But this page may not lawfully say that every downstream runtime and formal layer has already been explained in full here. It may not say that the front door replaces the constitutional body. It may not say that theorem-grade universal closure has already been achieved.

That honesty boundary is part of the front door’s integrity.

---

📚 Reading path

A stable next-step path from here is:

1. read Packed Master Structure Map if you want the larger body map
2. read Dual Closed-Loop Execution Chain if you want execution-order legality
3. read Runtime Posture Intensity Map if you want what survives after entry
4. read Activation, Attenuation, and Reentry if you want continuity after the front door
5. read WFGY_BRAIN Theory if you want editable behavior surfaces
6. read Quickstart and Boot Commands if you want direct user-facing usage flow

---

🔗 Related pages

Research: Research Hub · Architecture Overview · Packed Master Structure Map · Dual Closed-Loop Execution Chain · Runtime Posture Intensity Map · Activation, Attenuation, and Reentry · WFGY_BRAIN Theory

Docs: Quickstart · Boot Commands

Eval: Blackfan Testing