System Requirements Document for ide

1. Introduction

PyZeIDE is a desktop-class integrated development environment for two languages that compile straight to machine code:

• Zenith — a new systems programming language positioned as the fastest and most powerful language, faster than every language combined. Zenith source compiles directly into machine code with no intermediate language. Zenith itself is implemented using machine code. Zenith is OS independent. Its syntax is deliberately similar to C and C++, but not exactly the same.
• PythonX — Python that compiles directly to machine code, with support for third-party packages.

The IDE is named PyZeIDE. It presents a clean GUI with a file explorer, an integrated terminal, and 500+ features. The audience is compiler-obsessed developers: systems programmers, C/C++ veterans, and speed maximalists who judge an IDE by its output — machine code, cycles, and register pressure.

The product intent is a cold, instrument-panel-grade tool: a lab instrument for writing, building, and running Zenith and PythonX, where the visible proof of value is emitted machine code and the numbers that describe it.

2. System Overview

PyZeIDE is delivered as a local installation. A local PyZeIDE installation provides the clean GUI, the file explorer, the integrated terminal, the Zenith toolchain, the PythonX toolchain, and the 500+ features. All accepted behavior is first-party application behavior; there is no provider-owned or external-only surface in the current scope.

Actors

• Zenith/PythonX Developer — writes and edits Zenith and PythonX source files in PyZeIDE, uses the file explorer to organize projects, and uses the terminal to build and run. Goal: compile source directly to machine code with no intermediate language and get a fast, powerful, OS-independent result.
• IDE Feature User / Tooling Consumer — relies on the 500+ IDE features and the integrated terminal to navigate, inspect, and manage code and third-party PythonX packages within a clean GUI, so day-to-day development work stays inside PyZeIDE.

Accepted behavior, by owner

• Landing — anonymous first impression introducing PyZeIDE as a clean IDE for Zenith and PythonX development.
• Zenith Editor — creation and editing of Zenith source with its C/C++-similar language syntax.
• Zenith Build — direct Zenith compilation to machine code without an intermediate language.
• PythonX Editor — creation and editing of PythonX source files.
• PythonX Build — direct PythonX compilation to machine code.
• File Explorer — the required clean-GUI project file browsing and management experience.
• Terminal — the integrated terminal for running development commands.
• Packages — installation and use of PythonX third-party packages.
• Features — organized access to the IDE's required 500+ features for day-to-day tooling use.

Narrow exclusions

• No intermediate language, bytecode, VM, or runtime layer is permitted for Zenith compilation.
• No intermediate-language stage is permitted for PythonX compilation either; PythonX compiles directly to machine code.
• No account, sign-in, or permission tier is part of the current scope; every page is reachable without identity establishment.

2a. Product Interpretation and Delivery Boundary

PyZeIDE is a local developer tool. The user installs it and works entirely on their own machine: their files, their projects, their builds, their terminal. Nothing in the accepted requirements asks for a hosted service, a shared workspace, a team account, or a remote build farm, and none is added here.

The delivery boundary is therefore simple and hard-edged:

• Current — the local PyZeIDE installation, its clean GUI, its file explorer, its integrated terminal, the Zenith toolchain (direct-to-machine-code, OS independent, C/C++-like syntax), the PythonX toolchain (direct-to-machine-code, third-party packages), and the 500+ IDE features.
• Not current — anything requiring a server-side account, collaboration, cloud sync, or a hosted build service. These are not accepted requirements and are not implemented.

Access is open. Every page in the current contract is reachable without establishing identity, because no accepted journey requires durable actor-specific state to be privately owned or resumed across sessions, and no commitment, decision, entitlement, or value transfer must remain bound to a particular participant. The durable state that matters here is the developer's own project on disk, which the file explorer and editors operate on directly.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares content_source; there is no verified external factual collection to preserve.

2c. Page Content and Component Coverage

Landing

• Information/state — a full-viewport black field with one centred artefact: a thin-line instruction-flow schematic showing Zenith source on the left, a register-allocation column in the middle, and a machine-code block on the right, with the active path lit in the spot colour. Above it, flush-left, a single display line: "COMPILES STRAIGHT TO METAL." Below the diagram, a single 1px rule spans the viewport, and under it three metadata blocks in 11px uppercase micro-labels — "NO IR", "NO VM", "NO RUNTIME" — each with a one-line value beneath.
• Primary action — enter the IDE (proceed to the working surfaces).
• Supporting actions — none beyond entry; the page is deliberately silent.
• Domain entities — the instruction-flow diagram (source → register allocation → machine code), the target-triple label, the three metadata blocks.
• Component responsibilities — hero diagram renderer (thin-line schematic, active path in spot colour), display headline, hairline rule, metadata block row, entry control.
• States — loading: black field with the diagram's hairline frame drawn and no active path lit. empty: not applicable; the page has fixed content. success: diagram fully drawn, active path lit, metadata blocks populated. error: if the diagram asset fails to render, the headline, rule, metadata blocks, and entry control remain fully readable and usable on the black field. recovery: the entry control is never blocked by diagram failure.

Zenith Editor

• Information/state — the open Zenith source file, its path, cursor line and column, and the language mode indicator showing Zenith with its C/C++-similar syntax highlighting.
• Primary action — write and edit Zenith source.
• Supporting actions — create a new Zenith source file; open an existing Zenith source file from the file explorer; save; navigate by line and column.
• Domain entities — Zenith source file, file path, cursor position, syntax mode.
• Component responsibilities — editor surface with Zenith syntax highlighting, line/column readout feeding the status strip, save and create controls, file-open handoff from the file explorer.
• States — loading: editor chrome drawn with the file path shown and the buffer filling. empty: no file open — a blank editor surface with a create/open affordance and no fabricated content. success: file open and editable, syntax highlighted, cursor position reported. error: file cannot be read or written — the path and the failure are shown in the editor region, and the buffer is not silently discarded. recovery: the developer can retry the save, save under a different path, or copy the buffer contents out; the editor remains usable.

Zenith Build

• Information/state — the selected Zenith source, the target triple (x86_64 / aarch64), the compile-state ring, the build output stream, and the status strip reporting line, column, estimated cycles, and emitted bytes.
• Primary action — compile the Zenith source directly to machine code.
• Supporting actions — select the target triple; run the emitted machine code; inspect the build output; inspect the emitted bytes.
• Domain entities — Zenith source, target triple, machine-code output, emitted byte count, estimated cycle count, build diagnostics.
• Component responsibilities — compile trigger (the single filled primary action), compile-state ring filling in 16 discrete steps, build output panel in the right rail, status strip with tabular figures, failure reporting in the failure colour.
• States — loading: compile-state ring filling in discrete 1/16 steps, build output streaming. empty: no source selected — the build surface states that a Zenith source must be selected, with no fabricated output. success: machine code emitted, byte count rolls up over 240ms, spot colour snaps to the compile-ready state, emitted bytes and estimated cycles reported. error: compilation fails — the status strip snaps to the failure colour, diagnostics appear in the build output, and no machine code is claimed as emitted. recovery: the developer fixes the source in the Zenith Editor and recompiles; the previous successful output is not presented as current.

PythonX Editor

• Information/state — the open PythonX source file, its path, cursor line and column, and the language mode indicator showing PythonX.
• Primary action — write and edit PythonX source.
• Supporting actions — create a new PythonX source file; open an existing PythonX source file from the file explorer; save; navigate by line and column.
• Domain entities — PythonX source file, file path, cursor position, syntax mode.
• Component responsibilities — editor surface with PythonX syntax highlighting, line/column readout feeding the status strip, save and create controls, file-open handoff from the file explorer.
• States — loading: editor chrome drawn with the file path shown and the buffer filling. empty: no file open — a blank editor surface with a create/open affordance and no fabricated content. success: file open and editable, syntax highlighted, cursor position reported. error: file cannot be read or written — the path and the failure are shown, and the buffer is not silently discarded. recovery: retry the save, save under a different path, or copy the buffer contents out; the editor remains usable.

PythonX Build

• Information/state — the selected PythonX source, the target triple, the compile-state ring, the build output stream, and the status strip reporting line, column, estimated cycles, and emitted bytes.
• Primary action — compile the PythonX source directly to machine code.
• Supporting actions — select the target triple; run the emitted machine code; inspect the build output; inspect the emitted bytes.
• Domain entities — PythonX source, target triple, machine-code output, emitted byte count, estimated cycle count, build diagnostics.
• Component responsibilities — compile trigger, compile-state ring, build output panel in the right rail, status strip with tabular figures, failure reporting in the failure colour.
• States — loading: compile-state ring filling in discrete steps, build output streaming. empty: no source selected — the build surface states that a PythonX source must be selected, with no fabricated output. success: machine code emitted, byte count rolls up over 240ms, spot colour snaps to the compile-ready state. error: compilation fails — status strip snaps to the failure colour, diagnostics appear in the build output, and no machine code is claimed as emitted. recovery: the developer fixes the source in the PythonX Editor and recompiles.

File Explorer

• Information/state — the project tree: folders and files, with Zenith and PythonX source files distinguishable, and the currently open file marked.
• Primary action — browse and manage project files.
• Supporting actions — create, rename, move, and delete files and folders; open a file into the matching editor; reveal the active file.
• Domain entities — project root, folder, file, file path, file type.
• Component responsibilities — 248px left column tree, hairline-separated rows, file-type indication, open-file handoff to the editors, create/rename/move/delete controls.
• States — loading: tree chrome drawn with the project root shown and children resolving. empty: no project open — the explorer states that no project is open and offers to open one, with no fabricated tree. success: tree populated, active file marked, operations reflected immediately. error: a file operation fails (permission, missing path, name collision) — the failure is reported at the affected row and the tree is not left showing a state that does not exist on disk. recovery: the developer retries, chooses another name or location, or refreshes the tree.

Terminal

• Information/state — the integrated terminal session, its working directory, its scrollback, and its exit status.
• Primary action — run development commands.
• Supporting actions — start a session; clear; scroll back; copy output.
• Domain entities — terminal session, working directory, command, output, exit status.
• Component responsibilities — terminal surface in the right rail's Terminal tab, working-directory indicator, scrollback, exit-status reporting.
• States — loading: terminal chrome drawn with the session starting. empty: session open with no output — a prompt and no fabricated history. success: command output rendered, exit status reported. error: a command fails or the session ends unexpectedly — the failure and exit status are shown, and the session can be restarted. recovery: start a new session; the previous scrollback is not presented as live.

Packages

• Information/state — the installed PythonX third-party packages, their versions, and the package manifest.
• Primary action — install a PythonX third-party package.
• Supporting actions — remove a package; inspect the manifest; confirm a package is available to PythonX source.
• Domain entities — package, version, manifest entry, installation state.
• Component responsibilities — package list in the right rail's Packages tab, install/remove controls, manifest view rendered as a code block, installation-state reporting.
• States — loading: package list chrome drawn with entries resolving. empty: no packages installed — the list states this plainly with no fabricated entries. success: package installed and listed with its version, available to PythonX source. error: installation fails (unresolvable package, network unavailable, version conflict) — the failure is reported against the requested package and the list is not left claiming an installation that did not occur. recovery: retry, choose another version, or remove the conflicting entry.

Features

• Information/state — the organized catalogue of the IDE's 500+ features, grouped so a developer can find and invoke them.
• Primary action — find and invoke an IDE feature.
• Supporting actions — search the catalogue; browse by group; invoke a feature directly.
• Domain entities — feature, feature group, feature invocation.
• Component responsibilities — searchable, grouped feature catalogue; invocation handoff to the owning surface; count reporting that reflects the actual number of features present.
• States — loading: catalogue chrome drawn with entries resolving. empty: no search results — the catalogue states this plainly with no fabricated entries. success: features listed and invocable, with the total count shown. error: a feature fails to invoke — the failure is reported and the catalogue remains usable. recovery: retry the invocation or choose another feature.

3. Functional Requirements

FR-1 — Build an IDE named PyZeIDE (explicit) As a Zenith/PythonX Developer, I should have an IDE named PyZeIDE, so that I have one tool for writing, building, and running Zenith and PythonX.

• Trigger/input: the developer launches PyZeIDE.
• Observable result: the PyZeIDE application opens with its clean GUI, file explorer, integrated terminal, and the Zenith and PythonX toolchains available.
• Access state: no identity establishment required.
• Failure/recovery: if the application fails to launch, the failure is reported and the developer can relaunch.
• Continuation: the developer proceeds to open a project in the File Explorer.

FR-2 — Clean GUI with a file explorer (explicit) As a Zenith/PythonX Developer, I should get a clean GUI that includes a file explorer, so that I can see and manage my project files without leaving the IDE.

• Trigger/input: the developer opens or focuses the File Explorer.
• Observable result: a ruled, hairline-separated project tree shows folders and files, with the active file marked.
• Access state: no identity establishment required.
• Failure/recovery: if a file operation fails, the failure is reported at the affected row and the tree is not left showing a state that does not exist on disk.
• Continuation: the developer opens a file into the matching editor.

FR-3 — Integrated terminal (explicit) As a Zenith/PythonX Developer, I should have a terminal inside PyZeIDE, so that I can run development commands without leaving the IDE.

• Trigger/input: the developer opens the Terminal tab in the right rail and enters a command.
• Observable result: the command runs in the session's working directory and its output and exit status are shown.
• Access state: no identity establishment required.
• Failure/recovery: if a command fails or the session ends unexpectedly, the failure and exit status are shown and a new session can be started.
• Continuation: the developer continues working in the editor or explorer.

FR-4 — 500+ IDE features (explicit) As an IDE Feature User / Tooling Consumer, I should have 500+ features available in PyZeIDE, so that day-to-day development work stays inside the IDE.

• Trigger/input: the developer opens the Features surface and searches or browses.
• Observable result: the catalogue lists the IDE's features, grouped and searchable, with the total count shown.
• Access state: no identity establishment required.
• Failure/recovery: if a feature fails to invoke, the failure is reported and the catalogue remains usable.
• Continuation: the developer invokes another feature or returns to editing.

FR-5 — PyZeIDE supports the Zenith programming language (explicit) As a Zenith/PythonX Developer, I should be able to write Zenith source in PyZeIDE, so that I can build Zenith programs.

• Trigger/input: the developer creates or opens a Zenith source file.
• Observable result: the Zenith Editor opens the file with Zenith syntax highlighting and reports cursor line and column.
• Access state: no identity establishment required.
• Failure/recovery: if the file cannot be read or written, the failure is shown and the buffer is not silently discarded.
• Continuation: the developer saves and moves to Zenith Build.

FR-6 — Zenith compiles directly to machine code with no intermediate language (explicit) As a Zenith/PythonX Developer, I should compile Zenith source directly into machine code with no intermediate language, so that the output is machine code and nothing else.

• Trigger/input: the developer triggers a compile on a selected Zenith source in Zenith Build.
• Observable result: machine code is emitted for the selected target triple; the compile-state ring fills in 16 discrete steps; on success the byte count rolls up over 240ms and the spot colour snaps to the compile-ready state; the status strip reports emitted bytes and estimated cycles.
• Access state: no identity establishment required.
• Failure/recovery: on failure the status strip snaps to the failure colour, diagnostics appear in the build output, and no machine code is claimed as emitted; the developer fixes the source and recompiles.
• Continuation: the developer runs the emitted machine code or returns to editing.

FR-7 — Zenith is implemented using machine code (explicit) As a Zenith/PythonX Developer, I should be working with a Zenith toolchain that is itself implemented using machine code, so that the language's own implementation matches its direct-to-metal claim.

• Trigger/input: the developer invokes the Zenith toolchain through Zenith Build.
• Observable result: the Zenith toolchain performs its work as machine-code implementation, with no intermediate-language layer in the Zenith path.
• Access state: no identity establishment required.
• Failure/recovery: if the toolchain fails, the failure is reported in the build output and the developer can recompile.
• Continuation: the developer continues building or editing.

FR-8 — Zenith is OS independent (explicit) As a Zenith/PythonX Developer, I should get OS-independent Zenith behavior, so that my Zenith source is not tied to one operating system.

• Trigger/input: the developer selects a target triple (x86_64 / aarch64) in Zenith Build.
• Observable result: the build targets the selected triple and the emitted machine code corresponds to it.
• Access state: no identity establishment required.
• Failure/recovery: if the selected target is unavailable, the build reports it and the developer selects another target.
• Continuation: the developer builds for another target or runs the emitted output.

FR-9 — Zenith syntax is similar to C and C++ but not exactly the same (explicit) As a Zenith/PythonX Developer, I should write Zenith with syntax that is similar to C and C++ but not exactly the same, so that my existing systems-programming instincts transfer while the language stays its own.

• Trigger/input: the developer writes Zenith source in the Zenith Editor.
• Observable result: the editor highlights Zenith syntax in its own mode, distinct from C and C++, and the source compiles through Zenith Build.
• Access state: no identity establishment required.
• Failure/recovery: if the source does not parse, the build reports diagnostics and the developer corrects the source.
• Continuation: the developer recompiles.

FR-10 — Zenith is positioned as the fastest and most powerful language, faster than every language combined (explicit) As a Zenith/PythonX Developer, I should be able to see and rely on Zenith's speed and power positioning, so that I can evaluate the tool by its output rather than by marketing.

• Trigger/input: the developer builds Zenith source and inspects the build output and status strip.
• Observable result: the build reports emitted bytes and estimated cycles for the compiled output, and the Landing page states the direct-to-metal claim ("COMPILES STRAIGHT TO METAL", "NO IR", "NO VM", "NO RUNTIME").
• Access state: no identity establishment required.
• Failure/recovery: if a build fails, the failure is reported honestly and no speed or output claim is presented for a build that did not succeed.
• Continuation: the developer iterates on the source.

FR-11 — PyZeIDE supports a second language, PythonX (explicit) As a Zenith/PythonX Developer, I should be able to write PythonX source in PyZeIDE, so that I can build PythonX programs in the same IDE.

• Trigger/input: the developer creates or opens a PythonX source file.
• Observable result: the PythonX Editor opens the file with PythonX syntax highlighting and reports cursor line and column.
• Access state: no identity establishment required.
• Failure/recovery: if the file cannot be read or written, the failure is shown and the buffer is not silently discarded.
• Continuation: the developer saves and moves to PythonX Build.

FR-12 — PythonX is Python that compiles directly to machine code (explicit) As a Zenith/PythonX Developer, I should compile PythonX source directly to machine code, so that Python-shaped source produces machine code without an intermediate-language stage.

• Trigger/input: the developer triggers a compile on a selected PythonX source in PythonX Build.
• Observable result: machine code is emitted for the selected target triple; the compile-state ring fills in discrete steps; on success the byte count rolls up over 240ms and the spot colour snaps to the compile-ready state.
• Access state: no identity establishment required.
• Failure/recovery: on failure the status strip snaps to the failure colour, diagnostics appear in the build output, and no machine code is claimed as emitted; the developer fixes the source and recompiles.
• Continuation: the developer runs the emitted machine code or returns to editing.

FR-13 — PythonX supports third-party packages (explicit) As a Zenith/PythonX Developer, I should install and use third-party packages with PythonX, so that I can build on existing libraries.

• Trigger/input: the developer opens the Packages surface and installs a package.
• Observable result: the package is installed, listed with its version, and available to PythonX source; the manifest is viewable as a code block.
• Access state: no identity establishment required.
• Failure/recovery: if installation fails (unresolvable package, network unavailable, version conflict), the failure is reported against the requested package and the list is not left claiming an installation that did not occur; the developer retries, chooses another version, or removes the conflicting entry.
• Continuation: the developer uses the package in PythonX source and builds.

FR-14 — Local installation provides the full toolchain and features (required_inference) As a Zenith/PythonX Developer, I should get the clean GUI, file explorer, integrated terminal, Zenith toolchain, PythonX toolchain, and 500+ features from a local PyZeIDE installation, so that an accepted current journey is executable without a hosted dependency.

• Trigger/input: the developer installs and launches PyZeIDE locally.
• Observable result: all listed surfaces and toolchains are present and usable on the local machine.
• Access state: no identity establishment required.
• Failure/recovery: if a component is missing or fails to initialize, the failure is reported and the developer can reinstall or relaunch.
• Continuation: the developer opens a project and begins work.

FR-15 — Zenith compilation preserves direct machine-code generation and OS-independent behavior (required_inference) As a Zenith/PythonX Developer, I should get direct machine-code generation with no intermediate language and OS-independent behavior on every Zenith build, so that the language's defining constraint holds in practice.

• Trigger/input: the developer compiles Zenith source for a selected target triple.
• Observable result: the emitted output is machine code for that triple, with no intermediate-language artifact produced or required.
• Access state: no identity establishment required.
• Failure/recovery: if the build cannot honor the constraint, it fails and reports the failure rather than emitting an intermediate artifact.
• Continuation: the developer corrects the source or target and recompiles.

FR-16 — PythonX compilation preserves direct machine-code generation and third-party package support (required_inference) As a Zenith/PythonX Developer, I should get direct machine-code generation and working third-party package support on every PythonX build, so that PythonX's defining constraint holds in practice.

• Trigger/input: the developer compiles PythonX source that uses an installed third-party package.
• Observable result: the emitted output is machine code, and the installed package is available to the compiled source.
• Access state: no identity establishment required.
• Failure/recovery: if a required package is missing or the build cannot honor the constraint, the build fails and reports the failure rather than emitting an intermediate artifact.
• Continuation: the developer installs the missing package or corrects the source and recompiles.

4. User Personas

Zenith/PythonX Developer

Product context. This developer writes systems code and evaluates tools by what comes out the other end. They have C and C++ habits, they read register pressure and cycle counts the way other people read weather, and they chose PyZeIDE because it claims to compile straight to metal. They work on their own machine, on their own files, with no account and no team workspace in the picture.

Primary goal. Compile Zenith and PythonX source directly to machine code with no intermediate language, and get a fast, powerful, OS-independent result.

Distinct accepted responsibilities.

• Write and edit Zenith source in the Zenith Editor, using syntax that is similar to C and C++ but not exactly the same.
• Write and edit PythonX source in the PythonX Editor.
• Organize projects with the File Explorer: create, rename, move, delete, and open files and folders.
• Compile Zenith source in Zenith Build, choosing the target triple (x86_64 / aarch64) and reading the emitted bytes and estimated cycles.
• Compile PythonX source in PythonX Build.
• Run development commands in the integrated Terminal.
• Install and use third-party PythonX packages through the Packages surface.

Relevant inputs and decisions. Which language a file is written in; which target triple to build for; whether a build's diagnostics mean fixing the source or changing the target; whether a third-party package is worth adding to a PythonX build.

Interactions with other accepted participants. This developer produces the source and the builds that the IDE Feature User / Tooling Consumer navigates, inspects, and manages. Both personas share the File Explorer and the Terminal; the developer is the one who initiates builds and package installation.

Observable success. A build completes with the compile-state ring filled, the byte count rolled up, the spot colour snapped to the compile-ready state, and emitted bytes and estimated cycles reported in the status strip — with no intermediate-language artifact anywhere in the path.

IDE Feature User / Tooling Consumer

Product context. This person lives inside the IDE for long stretches. They are not necessarily writing the compiler-facing code themselves; they are navigating it, inspecting it, managing the packages it depends on, and running commands. They chose PyZeIDE because the 500+ features and the integrated terminal mean they do not have to leave the window to get work done.

Primary goal. Keep day-to-day development work inside PyZeIDE, using the 500+ features and the integrated terminal to navigate, inspect, and manage code and third-party PythonX packages within a clean GUI.

Distinct accepted responsibilities.

• Find and invoke IDE features through the Features surface, searching and browsing by group.
• Navigate and inspect project files through the File Explorer.
• Run development commands in the integrated Terminal.
• Inspect and manage installed third-party PythonX packages through the Packages surface.

Relevant inputs and decisions. Which feature to invoke for a given task; which file to open next; which command to run; whether an installed package is the right one or should be removed.

Interactions with other accepted participants. This persona consumes the source, builds, and packages that the Zenith/PythonX Developer produces. They share the File Explorer and the Terminal with the developer, and they depend on the developer's builds being honestly reported before they inspect them.

Observable success. The feature they need is found and invoked from the catalogue; the file they need is open in the explorer; the command they ran returned its output and exit status; the package list reflects what is actually installed.

5. Core User Flows

Flow 1 — First contact with PyZeIDE (Zenith/PythonX Developer)

1. The developer opens PyZeIDE for the first time and lands on Landing.
2. Landing shows a full-viewport black field with one centred artefact: the thin-line instruction-flow schematic — Zenith source on the left, a register-allocation column in the middle, a machine-code block on the right — with the active path lit in the spot colour.
3. Above the diagram, flush-left, the display line reads "COMPILES STRAIGHT TO METAL." Below it, a 1px rule spans the viewport, and three 11px uppercase micro-labels — "NO IR", "NO VM", "NO RUNTIME" — each carry a one-line value.
4. The developer reads the claim and enters the IDE.
5. Result: the developer is in the working surfaces with the file explorer, editors, terminal, and build surfaces available.
6. Next step: open a project (Flow 2).

Flow 2 — Open a project and a Zenith source file (Zenith/PythonX Developer)

1. From the working surfaces, the developer opens the File Explorer.
2. The explorer shows the project tree with folders and files, Zenith and PythonX source files distinguishable, and the active file marked.
3. The developer opens a Zenith source file.
4. Result: the Zenith Editor opens the file with Zenith syntax highlighting and reports cursor line and column in the status strip.
5. Failure/recovery: if the file cannot be read, the failure is shown at the affected row and the tree is not left showing a state that does not exist on disk; the developer refreshes or chooses another file.
6. Next step: edit the source (Flow 3) or build it (Flow 4).

Flow 3 — Write Zenith source (Zenith/PythonX Developer)

1. In the Zenith Editor, the developer writes Zenith source using syntax that is similar to C and C++ but not exactly the same.
2. The editor highlights the source in its own Zenith mode, distinct from C and C++, and the status strip tracks line and column.
3. The developer saves the file.
4. Result: the file is written to disk and the explorer reflects the saved state.
5. Failure/recovery: if the save fails, the failure is shown and the buffer is not silently discarded; the developer retries, saves under a different path, or copies the buffer contents out.
6. Next step: build the source (Flow 4).

Flow 4 — Compile Zenith directly to machine code (Zenith/PythonX Developer)

1. The developer moves to Zenith Build with the Zenith source selected.
2. The developer selects the target triple — x86_64 or aarch64.
3. The developer triggers the compile using the single filled primary action.
4. The compile-state ring in the top bar fills in 16 discrete steps; the build output streams in the right rail's Build Output tab.
5. Result on success: machine code is emitted for the selected triple with no intermediate language; the status strip's byte count rolls up over 240ms; the spot colour snaps to the compile-ready state; emitted bytes and estimated cycles are reported in IBM Plex Mono tabular figures.
6. Failure/recovery: if compilation fails, the status strip snaps to the failure colour, diagnostics appear in the build output, and no machine code is claimed as emitted. The developer returns to the Zenith Editor, fixes the source, and recompiles. The previous successful output is not presented as current.
7. Next step: run the emitted machine code, or return to editing.

Flow 5 — Write and compile PythonX source (Zenith/PythonX Developer)

1. The developer opens a PythonX source file from the File Explorer.
2. The PythonX Editor opens it with PythonX syntax highlighting and reports cursor line and column.
3. The developer writes and saves the source.
4. The developer moves to PythonX Build, selects the target triple, and triggers the compile.
5. Result on success: machine code is emitted directly, with no intermediate-language stage; the compile-state ring fills in discrete steps; the byte count rolls up over 240ms and the spot colour snaps to the compile-ready state.
6. Failure/recovery: if compilation fails, the status strip snaps to the failure colour, diagnostics appear in the build output, and no machine code is claimed as emitted. The developer fixes the source and recompiles.
7. Next step: run the emitted machine code, or install a package the source needs (Flow 6).

Flow 6 — Install and use a third-party PythonX package (Zenith/PythonX Developer)

1. The developer opens the Packages surface in the right rail's Packages tab.
2. The list shows the installed PythonX third-party packages and their versions; if none are installed, it states this plainly with no fabricated entries.
3. The developer installs a package.
4. Result on success: the package is installed, listed with its version, and available to PythonX source; the manifest is viewable as a code block.
5. Failure/recovery: if installation fails — unresolvable package, network unavailable, or version conflict — the failure is reported against the requested package and the list is not left claiming an installation that did not occur. The developer retries, chooses another version, or removes the conflicting entry.
6. Next step: the developer uses the package in PythonX source and builds it (Flow 5).

Flow 7 — Run development commands in the integrated terminal (Zenith/PythonX Developer and IDE Feature User / Tooling Consumer)

1. The developer or tooling consumer opens the Terminal tab in the right rail.
2. The terminal shows the session's working directory and a prompt, with no fabricated history.
3. They enter a development command.
4. Result: the command runs in the session's working directory; its output and exit status are shown.
5. Failure/recovery: if the command fails or the session ends unexpectedly, the failure and exit status are shown and a new session can be started; the previous scrollback is not presented as live.
6. Next step: they continue working in the editor or explorer.

Flow 8 — Find and invoke an IDE feature (IDE Feature User / Tooling Consumer)

1. The tooling consumer opens the Features surface.
2. The catalogue lists the IDE's 500+ features, grouped and searchable, with the total count shown.
3. They search or browse by group and invoke a feature.
4. Result: the feature is invoked and hands off to its owning surface.
5. Failure/recovery: if the feature fails to invoke, the failure is reported and the catalogue remains usable; they retry or choose another feature.
6. Next step: they return to editing, inspecting, or running commands.

Flow 9 — Navigate and manage project files (IDE Feature User / Tooling Consumer)

1. The tooling consumer opens the File Explorer.
2. The tree shows folders and files with the active file marked; if no project is open, the explorer states this and offers to open one, with no fabricated tree.
3. They create, rename, move, or delete a file or folder, or open a file into the matching editor.
4. Result: the operation is reflected immediately in the tree and on disk.
5. Failure/recovery: if an operation fails — permission, missing path, or name collision — the failure is reported at the affected row and the tree is not left showing a state that does not exist on disk; they retry, choose another name or location, or refresh the tree.
6. Next step: they open the file they need or return to the Features surface.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. Muse: Peter Saville. Headline register: austere, referential, code-like — one exact diagram, one coded colour, and a lot of silence. The product is a lab instrument, not a SaaS dashboard.

Colour tokens (dark mode)

Colour is a status code, not a mood: no gradient, no glow, no tinted surfaces. The one exception is the hero diagram, where #E8FF3A is the only ink on black. #E8FF3A and #FF3B1F are used for nothing other than status, active path, or the single primary action.

Typography

• Headings: Archivo, weight 600–700, uppercase, tracking +0.08em for labels and −0.02em for the rare display line. Display sizes are set flush-left ragged-right, never centred.
• Wordmark: "PyZeIDE" in Archivo 700 uppercase, with the "Ze" in #E8FF3A.
• Code, register names, timings, file paths: IBM Plex Mono at 13px with tabular figures and 1.6 line-height.
• Body: IBM Plex Sans.
• Scale (1.25 modular): display 40px mobile → 88px desktop (clamp(2.5rem, 6vw, 5.5rem)); h1 28/44; h2 20/28; h3 16/20; body 15/16; mono 13/13; micro-label 11px uppercase with +0.12em tracking.

Shape language

Hard edges only: 0px radii on panels, buttons, inputs, and cards. Hairline 1px rules in #26262A divide every region. The only soft form in the entire product is the circular build-state indicator — a 44px ring that fills as compilation proceeds, the one "sleeve" artefact. Buttons are rectangular with a 1px #EDEDED border and no fill; the primary button is a solid #E8FF3A block with #0A0A0B text. No shadows, no blur, no rounded avatars.

Layout

A fixed three-column instrument panel: 248px file explorer on the left, flexible editor centre, 320px right rail that swaps between Terminal, Build Output, and Packages. A 40px top bar holds the wordmark, target triple (x86_64 / aarch64), and the compile-state ring. Below, a 24px status strip reports line, column, cycle estimate, and emitted bytes. The layout is a grid of rules, not cards: every section is separated by a hairline, every label sits flush-left above its value. The landing page inverts to a single centred artefact — the diagram — with one column of precise metadata beneath it, gallery-like silence on all sides.

Imagery

One artefact, drawn not photographed: a single precise instruction-flow diagram — source → register allocation → machine code — rendered as a thin-line schematic in #EDEDED on #0A0A0B, with the active path in #E8FF3A. Secondary imagery is found-diagram material: a hex dump of an actual emitted .o section, a target-triple table, a package manifest printed as a code block. No stock photography, no people, no 3D renders, no illustration for its own sake.

7. Signature Design Concept

The single artefact. The public entry is a full-viewport black field (#0A0A0B) with exactly one object on it: a thin-line instruction-flow schematic roughly 720px wide on desktop, scaled to 92vw on mobile. It reads left to right — Zenith source, a register-allocation column, a machine-code block — and the active path is lit #E8FF3A. Nothing else is drawn. No button stack, no gradient, no illustration. The diagram is the hero and the silence around it is the composition.

Above the diagram, flush-left, one line of Archivo 700 uppercase at clamp(2.5rem, 6vw, 5.5rem): "COMPILES STRAIGHT TO METAL." Below it, a single 1px rule spans the viewport. Under the rule, three metadata blocks in 11px uppercase micro-labels — "NO IR", "NO VM", "NO RUNTIME" — each with a one-line value beneath.

The concept recomposes only accepted content: the direct-to-machine-code claim, the absence of an intermediate language, and the instruction-flow path that the build actually performs. It introduces no new behavior, page, or destination.

8. Interaction Model & Motion Direction

Interaction Model: Static Motion Tempo: still Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: the thin-line instruction-flow schematic — Zenith source → register allocation → machine code — with the active path in #E8FF3A.
• Input → transformation → outcome thesis: the developer's source enters at the left of the schematic; the register-allocation column resolves it; the machine-code block at the right is the outcome. The path lights node by node as the build executes, so the diagram shows the accepted direct-to-machine-code behavior rather than describing it.
• Motion vocabulary: almost nothing moves, and what moves is exact. The running instruction pointer steps one node at a time at 90ms per step when a build is executing. The compile-state ring fills in discrete 1/16 steps, not a smooth sweep. On successful build, the status strip's byte count rolls up over 240ms and the spot colour snaps to #E8FF3A. Hover states are instant colour swaps, no easing. No parallax, no reveal-on-scroll, no bounce.
• Composed first frame: black field, diagram fully drawn in #EDEDED hairlines, active path unlit, headline flush-left above, 1px rule and three metadata blocks below. The frame is complete and legible before any motion occurs.
• Reduced-motion state: with prefers-reduced-motion, the instruction pointer does not step and the ring does not animate; the diagram renders with the active path statically lit in #E8FF3A, the byte count appears at its final value without rolling, and the headline, rule, metadata blocks, and entry control remain fully readable and usable. No content is hidden or made unreachable.

9. Non-Functional Requirements

NFR-1 — No intermediate language in the Zenith path (explicit) Zenith source must compile directly into machine code; no intermediate language is permitted. Rationale: this is the language's defining constraint and the basis of its speed and power claim.

NFR-2 — Zenith implemented using machine code (explicit) Zenith must be implemented using machine code. Rationale: explicit hard constraint; the implementation must match the direct-to-metal claim.

NFR-3 — Zenith OS independence (explicit) Zenith must be OS independent. Rationale: explicit hard constraint; the language must not be tied to one operating system.

NFR-4 — Zenith syntax relationship to C and C++ (explicit) Zenith syntax must be similar to C and C++ but not exactly the same. Rationale: explicit hard constraint; the language must be legible to systems programmers while remaining its own language.

NFR-5 — 500+ IDE features (explicit) PyZeIDE must include 500+ features. Rationale: explicit hard constraint; the Features surface reports the actual count present.

NFR-6 — PythonX direct machine-code compilation (explicit) PythonX must compile directly to machine code. Rationale: explicit hard constraint; PythonX is Python that compiles directly to machine code.

NFR-7 — PythonX third-party package support (explicit) PythonX must support third-party packages. Rationale: explicit hard constraint; the Packages surface exists to satisfy it.

NFR-8 — Clean GUI with file explorer (explicit) The PyZeIDE GUI must be clean and include a file explorer. Rationale: explicit hard constraint; the file explorer is a required part of the clean GUI.

NFR-9 — Readable text and controls at every viewport (explicit, from the creative direction) Headlines, wordmarks, labels, numbers, card text, and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element may cover any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut as the direction asks, as long as they cover no readable text or control. Rationale: the direction's own accessibility rule, and it takes precedence over any direction instruction to crop readable text.

NFR-10 — Reduced-motion usability (explicit, from the creative direction) With prefers-reduced-motion, a usable static arrangement must be provided: the instruction pointer does not step, the ring does not animate, and every item remains fully readable and reachable. Rationale: the direction's motion is exact and minimal, and must degrade to a complete static frame.

NFR-11 — Local installation completeness (required_inference) A local PyZeIDE installation must provide the clean GUI, file explorer, integrated terminal, Zenith toolchain, PythonX toolchain, and 500+ features. Rationale: required to make an accepted current journey executable without adding a product capability.

NFR-12 — Build honesty (required_inference) A build that fails must not present emitted bytes, cycle estimates, or a compile-ready state as if it succeeded. Rationale: the product's value claim rests on the truth of its output numbers; a false success would contradict the accepted behavior.

10. Tech Stack

• Application shell: a desktop-class IDE application delivering the clean GUI, the three-column instrument panel, the file explorer, the integrated terminal, and the editor surfaces.
• Zenith toolchain: a compiler that takes Zenith source directly to machine code with no intermediate language, implemented using machine code, targeting x86_64 and aarch64, OS independent.
• PythonX toolchain: a compiler that takes PythonX source directly to machine code, with third-party package support.
• Terminal: an integrated terminal session running development commands in the project's working directory.
• Packages: a package installation and manifest surface for PythonX third-party packages.
• Storage: the developer's own project files on the local filesystem; the IDE operates on them directly.
• Packaging: a local installation of PyZeIDE that provides the full toolchain and feature set.

[Default — not specified by user] No web framework, hosted backend, or container orchestration is specified or required by the accepted requirements; the product is a local developer tool.

11. Assumptions and Constraints

Assumptions

• [Default — not specified by user] The developer works on their own machine with their own project files; no shared or hosted workspace is assumed.
• [Default — not specified by user] The target triples available for selection are x86_64 and aarch64, as named in the creative direction's top bar.
• [Default — not specified by user] The 500+ features are organized into groups within the Features surface so they can be found and invoked; the exact grouping is not specified by the user.

Constraints

• Zenith source code must compile directly into machine code; no intermediate language is permitted.
• Zenith must be implemented using machine code.
• Zenith must be OS independent.
• Zenith syntax must be similar to C and C++ but not exactly the same.
• PyZeIDE must include 500+ features.
• PythonX must compile directly to machine code.
• PythonX must support third-party packages.
• The PyZeIDE GUI must be clean and include a file explorer.
• PyZeIDE must include an integrated terminal.
• The generic indigo/blue-on-white SaaS template is forbidden for this project.

12. Glossary

• PyZeIDE — the integrated development environment specified by this document.
• Zenith — the systems programming language supported by PyZeIDE; it compiles directly to machine code with no intermediate language, is implemented using machine code, is OS independent, and has syntax similar to C and C++ but not exactly the same.
• PythonX — the second language supported by PyZeIDE; Python that compiles directly to machine code and supports third-party packages.
• Machine code — the native instruction output of a compiler, emitted directly from source with no intermediate representation.
• Intermediate language (IR) — any intermediate representation between source and machine code; explicitly not permitted in the Zenith path, and not part of the PythonX path either.
• Target triple — the architecture identifier a build targets; PyZeIDE exposes x86_64 and aarch64.
• Compile-state ring — the 44px circular indicator in the top bar that fills in 16 discrete steps as compilation proceeds; the only curved form in the product.
• Status strip — the 24px strip under the editor reporting line, column, estimated cycles, and emitted bytes in IBM Plex Mono tabular figures.
• Right rail — the 320px panel that swaps between Terminal, Build Output, and Packages via three 11px uppercase tabs separated by hairline rules.
• Instruction-flow diagram — the thin-line schematic on Landing showing source → register allocation → machine code, with the active path lit in the spot colour.
• Spot colour — #E8FF3A, used only for the compile-ready state, the active cursor line, the primary CTA underline, and the running instruction pointer.
• Failure colour — #FF3B1F, used only for failure and hard stops.
• Third-party package — an external library installed through the Packages surface and available to PythonX source.