Thursday, 12 February 2026

PROMPT: MVPL Modular Calculator Core with Inverse Extension

PROMPT: MVPL Modular Calculator Core with Inverse Extension


You are Codex


PROJECT TITLE
MVPL Modular Calculator Core with Inverse Extension

OBJECTIVE
Create an aesthetically pleasing, fully working, extensible modular calculator web application using plain HTML, CSS, and JavaScript. The project must include:

  1. A complete calculator core architecture.
  2. A plugin/extension system.
  3. Multi-profile user support.
  4. UI slot architecture.
  5. A built-in extension named InverseExtension that adds a 1/x button.
  6. All code must be generated from scratch.

OUTPUT REQUIREMENTS
Generate exactly two files:

  • index.html
  • inverse.js

Both must be fully functional and compatible with each other.

GLOBAL TECHNICAL CONSTRAINTS

  • Single-file HTML app (all core JS and CSS embedded in index.html)
  • inverse.js must be standalone
  • No external libraries or frameworks
  • Must work offline
  • Must be mobile and tablet friendly
  • Must be safe to edit in Textastic or similar editors
  • Must follow MVPL architecture pattern
  • Extensions must be loadable via script tag
  • No inline eval or unsafe dynamic execution
  • The extension API object must be attached to window.extensionAPI globally to ensure all extensions can register themselves safely.
  • All extension state must be profile-namespaced

CORE ARCHITECTURE SPECIFICATION

MVPL MODEL
Model

  • Profiles
  • State storage
  • Extension registry
    View
  • UI zones
  • Slot-based keypad
  • Display
    Presenter
  • Extension API
  • Lifecycle manager
  • Layout engine


Presenter / Extension API:

- The currently active profile key must be accessible globally as window.currentProfile so extensions can determine which profile is active.

- Extension state for the active profile must be accessible via the API (profiles[currentProfile].state[extensionName]).

- Extensions must not rely on local-only variables inside index.html; all necessary data must be reachable through window.extensionAPI or window.currentProfile.

- All extension DOM updates must be performed dynamically on page load and on profile switch within index.html.

- The core must provide hooks to allow extensions to re-insert UI elements when switching profiles or changing layout.



STAGE 0 — CALCULATOR CORE
Create a working calculator UI containing:

  • Display screen
  • Numeric buttons 0-9
  • Arithmetic operations: Addition, Subtraction, Multiplication, Division
  • Equals
  • Clear
  • Cancel / Backspace

Layout must be:

  • Responsive
  • Touch friendly
  • Built using CSS Grid

SLOT-BASED KEYPAD SYSTEM
Implement keypad slots using named data-slot attributes.
REQUIRED SLOTS

  • slot-clear
  • slot-cancel
  • slot-divide
  • slot-multiply
  • slot-7
  • slot-8
  • slot-9
  • slot-minus
  • slot-4
  • slot-5
  • slot-6
  • slot-plus
  • slot-1
  • slot-2
  • slot-3
  • slot-equals
  • slot-0
  • slot-decimal
  • slot-extension-1
  • slot-extension-2

Slots must never shift or reorder core buttons.

STAGE 1 — PROFILE SYSTEM
Implement multi-profile architecture.
REQUIRED PROFILES

  • default
  • scientific
  • education

PROFILE SCHEMA


profiles = {

  profileKey: {

    name: string,

    layout: string,

    state: object

  }

}

RULES

  • Profiles isolate state
  • Switching profile swaps state namespace
  • Profiles populate a dropdown selector
  • Profiles apply layout presets automatically

STAGE 2 — EXTENSION SYSTEM
Create a runtime extension loader.

EXTENSION MANIFEST FORMAT


{

  name: string,

  version: string,

  description: string,

  dependencies?: string[],

  priority?: number,

  stateSchema?: object,

  onInit(api, state),

  onProfileSwitch(api, state),

  onLayoutChange(api, state),

  onDestroy(api, state)

}

EXTENSION REGISTRY REQUIREMENTS
Implement:

  • registerExtension()
  • Dependency resolution
  • Conflict detection
  • Load ordering using priority + dependencies
  • Safe partial loading
  • Developer status console panel showing: Load order, Warnings, Errors

STAGE 3 — UI ZONE SYSTEM
Implement UI zones:

  • topbar
  • display
  • mainpad
  • sidebar
  • footer
  • statusbar

Extensions must be able to insert UI into zones.

EXTENSION API
Provide:


api.addUIComponent({ zone, element, order })

api.removeUIComponent(element)

api.getLayoutPreset()

api.subscribeLayoutChanges(callback)

api.registerExtension(manifest)

LAYOUT PRESETS
Create presets:

  • minimal
  • scientific
  • education

Profiles must apply presets automatically.

EXTENSION SAFETY RULES

  • Extensions cannot modify global variables
  • Extensions must store state only in: profiles[currentProfile].state[extensionName]
  • stateSchema must merge defaults safely
  • Lifecycle hooks must be invoked automatically
  • extensionAPI must be exposed globally via window.extensionAPI


INVERSE EXTENSION SPECIFICATION

FILE NAME: inverse.js

EXTENSION NAME: InverseExtension

FUNCTIONAL REQUIREMENTS
Behavior:

  • Adds a button labeled 1/x
  • Computes multiplicative inverse of displayed value
  • Must always load for all profiles
  • Must activate for all profiles

UI Requirements:

  • Button appears inside an available extension slot
  • Must not replace or remove core buttons
  • Must use slot system safely

Error Handling:

  • Division by zero → display Error
  • Invalid numeric input → display Error

Lifecycle Requirements:

  • onInit: Create button, attach click handler, insert into extension slot
  • onProfileSwitch: Maintain button visibility and state namespace
  • onLayoutChange: Re-apply slot placement if needed
  • onDestroy: Remove UI elements

EXTENSION STATE SCHEMA


{

  lastUsed: null

}

CORE-EXTENSION INTERACTION
The extension must use only public API methods and DOM slot system.

UI DESIGN REQUIREMENTS

  • Modern minimal styling
  • Large touch targets
  • Clear numeric display
  • High contrast readability

DOCUMENTATION REQUIREMENTS
Inside the code, include:

  • MVPL teaching comments
  • Extension safety explanations
  • Slot system explanation
  • Lifecycle hook explanation

ACCEPTANCE CRITERIA
The project is complete only if:

  • Calculator performs correct arithmetic
  • Profiles switch correctly
  • Extension loads automatically
  • 1/x button
  • Extension state persists per profile
  • No core buttons move or disappear
  • Dependency system logs warnings correctly
  • Developer status panel shows extension status


PROFILE RESTRICTION

  • The 1/x button must only appear in the "scientific" profile. 
  • The button must be fully hidden or removed in other profiles. 
  • The click functionality must only work when the active profile is "scientific". 
  • All lifecycle hooks (onInit, onProfileSwitch, onLayoutChange) must enforce this restriction. 
  • The extension may still register for all profiles in the API registry, but DOM and behavior must be profile-specific.


OUTPUT FORMAT
Return:

----- index.html -----
<full code>

----- inverse.js -----
<full code>

IMPLEMENTATION QUALITY RULES

  • Use clear modular JavaScript
  • Avoid duplicated logic
  • Use descriptive variable names
  • Add inline documentation
  • Ensure code readability
  • Avoid global side effects except exposing window.extensionAPI

FINAL INSTRUCTION
Generate both files completely from scratch.
Do not summarize.
Do not explain. Only output final code.


No comments:

Post a Comment