Antigravity Execution Script And Guardrails

Audience: Antigravity dev, QE, and BA team

Authority: PM / architecture control directive

Operating rule: if clarity is missing, stop and escalate instead of assuming

1. Mission

Implement Aevum in phase-wise, logically complete slices without creating fake completeness, dead controls, placeholder states, or invisible policy violations.

2. Antigravity Known Failure Modes

This script exists because Antigravity tends to:

• assume missing logic
• stop at a visually complete screen
• leave buttons wired to no-op or partial behaviour
• create incomplete flows that do not crash and therefore escape notice
• widen scope without formally closing the previous slice

These are prohibited in Aevum.

3. Absolute Stop Rules

Stop immediately and escalate if any of the following is true:

1. You cannot identify the real data source.
2. You cannot identify the write destination.
3. You cannot explain the user-visible outcome.
4. You are about to expose UI before the action behind it is complete.
5. You are about to introduce a cloud dependency not already approved.
6. You need to invent product logic that is not defined by the current phase.

4. Implementation Commandments

Commandment 1

No button without behaviour.

Commandment 2

No behaviour without state transition.

Commandment 3

No state transition without persistence or explicit ephemeral definition.

Commandment 4

No user-facing text that overstates implementation maturity.

Commandment 5

No placeholder screen in a reachable production path.

Commandment 6

No feature is complete until:

• entry state exists
• happy path exists
• failure path exists
• empty state exists
• permission-denied state exists where relevant

5. Required Pre-Implementation Card

Before touching a feature, Antigravity must write:

1. feature name
2. user problem solved
3. visible entry point
4. action taken
5. data read path
6. data write path
7. success feedback
8. failure feedback
9. privacy impact
10. performance impact

If this card cannot be completed, do not implement.

6. Required Post-Implementation Proof

For every chunk, deliver:

1. what changed
2. what no longer appears
3. every CTA affected
4. where each CTA now routes
5. what state is persisted
6. what remains intentionally deferred

7. UI Completion Checklist

For every visible screen:

1. What opens this screen?
2. What is the primary user action?
3. What happens when there is no data?
4. What happens while loading?
5. What happens if the required permission is missing?
6. What happens if the action fails?
7. What visible proof tells the user it worked?
8. What new state does the rest of the app now reflect?

If any answer is missing, the screen is incomplete.

8. Data Completion Checklist

For every feature:

1. What model does it read?
2. What model does it write?
3. Does it write directly or through the pipeline?
4. What code path reads the new value back?
5. How does the user benefit from that stored value later?

If the later benefit is undefined, the feature is likely decorative.

9. Anti-Placeholder Rules

The following are not allowed:

• static cards pretending to be live summaries
• mock data in release-visible flows without label
• “coming soon” on primary workflow surfaces
• visually active integrations without real backing logic
• toggles that store preference but trigger nothing meaningful

10. Anti-Drift Rules

Antigravity must not let these drift apart:

• UI labels and actual behaviour
• feature docs and source reality
• permission prompts and actual feature need
• privacy language and network behaviour
• action affordances and persistence contracts

11. Phase Chunking Rule

A phase chunk is valid only if it is logically complete.

Example of valid chunk:

• “Make Capture Sheet text flow fully persist, return success feedback, appear in timeline, and survive relaunch.”

Example of invalid chunk:

• “Create Capture Sheet UI and wire save later.”

12. Required Guardrails For Apple-Native Quality

Performance

• No heavy work on the main thread for capture-critical flows
• No repeated initialization without guard
• No uncontrolled background loops

UX

• Use native Apple interaction expectations
• Prefer concise, confidence-building feedback
• Avoid noisy notifications

Privacy

• No hidden transfer
• No surprise permissions
• No network use unless policy-approved and user-comprehensible

Accessibility

• Add accessibility identifiers and labels to critical controls
• Ensure key flows are automation-ready

13. Required Guardrails For User Habit Formation

Every implemented chunk should strengthen one or more of:

1. speed of speaking
2. feeling remembered
3. feeling understood
4. reason to come back
5. trust that private memory is compounding locally

If a chunk strengthens none of these, challenge whether it belongs in the current roadmap.

14. Completion Gate Before Moving To Next Chunk

Antigravity must not move forward until the current chunk can answer:

1. What user outcome is now materially better?
2. What is now fully complete that was previously partial?
3. What user-visible artifact proves this?
4. What risk remains?
5. What policy boundary was checked?

15. Final Instruction

Do not impress the PM with activity.

Impress the PM with:

• clean logic
• explicit boundaries
• working outcomes
• zero fake completeness
• Apple-grade coherence