ai calculator

# Document-defined scientific calculator

Specification revision: 1.2 — initial creation, traditional scientific calculator

Revision 1.2 records the authorized replacement of expression editing with traditional calculator entry and a flexible, OS-styled layout. It supersedes the expression-language interface and its editing tests from revision 1.1; the scientific functions, dependency boundary, and delivery requirements remain in force. No application source is created by this amendment.

## 1. Purpose and entry point

This repository demonstrates a development method: a complete project is defined in a document, and a human or agent produces an implementation from that document. The example project is a desktop scientific calculator. The method, rather than a particular language or framework, is the subject of the demonstration.

This file is the authoritative specification for the initial implementation. A request such as “make project,” “begin,” or “this is a project, figure it out” means: read this document, conduct the setup below, and produce the specified deliverables. It does not mean redesign the application or propose a broader product. Reading the repository without an implementation request does not authorize creation.

Success means that independent implementations, including those written in different languages, exhibit the behavior specified here and pass the same acceptance cases. Reproducibility means equivalent behavior and a documented build process; it does not require identical source code, pixel-identical windows, or byte-identical binaries.

Everything required of the application is defined here. Product behavior and design requirements are technology-independent. Named languages, libraries, and build tools are confined to the implementation-defaults section, which also records the user's exclusion of Rust. Product behavior does not depend on the selected permitted stack. The setup answers select an implementation profile within this specification; they do not silently add application requirements. Do not infer requirements from typical calculator products, framework examples, or personal preferences.

## 2. Rules for the implementing agent or human

1. Read this whole document before asking questions or writing application code.
2. Inspect existing repository instructions and files. Preserve unrelated work. For initial creation, generate the complete project only after the required setup answers have been received.
3. Ask the defined setup questions together in one concise message. Do not turn initial creation into an open-ended design consultation.
4. Implement this revision faithfully. Do not add features, improve the product, expand its scope, or silently correct perceived specification deficiencies.
5. Supporting implementation code is permitted when necessary to satisfy a stated requirement: event handling, parsing, layout, resource cleanup, dependency configuration, and test infrastructure are examples. Supporting code must not introduce additional user-visible capabilities or unrelated services.
6. Make ordinary internal engineering choices without asking for approval when observable behavior is already defined. Record consequential implementation choices in the implementation record.
7. If a genuine ambiguity would change observable behavior or prevent implementation, identify the exact conflict or omission and ask the smallest question needed. Do not resolve it by inventing a requirement. Pause only the work dependent on that answer.
8. Report improvements and security concerns separately. Do not implement them unless explicitly authorized. A security finding is not authorization to change the application.
9. An authorized behavioral change must be recorded as a specification amendment before implementing it. Preserve this revision's original requirements and identify what the amendment replaces. A suggestion alone is not an amendment.
10. Do not edit this specification merely to make an implementation pass. Report deviations honestly.

Instructions from the user or governing environment still take precedence. If they conflict with this specification, state the conflict and record the resulting deviation; do not claim unqualified conformity.

## 3. Required setup conversation

Ask these questions before generating application source. Skip only questions already answered explicitly in the current request or an existing implementation profile. Silence is not an answer.

| Question | Permitted answer and handling |
| --- | --- |
| Use the suggested default stack below, or a different language and GUI framework? | Offer the defaults below. Accept a specific compatible alternative, “use defaults,” or “choose for me.” Record the selected stack. Do not ask the user to compare a catalog of frameworks. |
| Which operating systems need build verification now? | Windows, macOS, Linux, or any combination. Default, if the user explicitly accepts defaults: the current host. Source support for all three remains mandatory. |
| Where should built application binaries be placed? | Default: `./output/`, relative to the repository root. Accept another explicit location. Record the resolved choice and configure the documented build process to place runnable application artifacts there. |
| Are there dependency, compiler, or build-tool restrictions? | Accept stated restrictions or “none.” No restriction means dependencies are allowed; it does not authorize unrelated capabilities. |

The user may answer “choose for me and use the defaults” to delegate the stack and accept the defaults for the remaining questions, including no additional restrictions. Do not treat the original vague implementation request as that delegation.

The design and OS-controlled styling are already specified in section 5; do not ask the user to choose them again.

### Default technology preferences

Prefer C++17, Qt 6 Widgets, and CMake on all three operating systems. Use one shared implementation across platforms. Qt Widgets is sufficient for this calculator; do not add Qt Quick/QML, Qt WebEngine, or other Qt modules unless required by a stated requirement. Rust is excluded for this revision.

| Build operating system | Default compiler and setup preference |
| --- | --- |
| Windows | MSVC from Visual Studio Build Tools, a matching prebuilt Qt desktop package, and CMake. The full Visual Studio IDE is not required. |
| macOS | Apple Clang from Xcode Command Line Tools, a compatible prebuilt Qt desktop package, and CMake. Do not require the full Xcode application unless a selected supported configuration actually needs it. |
| Linux | GCC, the distribution's Qt 6 Widgets development packages, and CMake. Record the distribution and required packages; prefer packaged Qt over building Qt from source. |

Prefer compatible tools already installed. Install only the compiler/build tools and Qt components required for the selected target; do not require Qt Creator, a second language toolchain, containers, or building Qt itself. These preferences minimize unnecessary setup, but do not claim that Qt has no installation cost. Select and record exact compatible versions during implementation rather than relying on an unpinned “latest.” If the default is unavailable or conflicts with setup restrictions, ask about the specific replacement rather than silently changing the profile. Selecting an alternative compatible stack remains permitted, except Rust; the calculator requirements stay language-independent.

### Dependency boundary

Dependencies are permitted only for the selected language toolchain, build system, GUI framework, and the platform/runtime components they require. The language's standard library, including its mathematical functions, is permitted. Use these facilities for the interface, numeric primitives, and ordinary platform integration.

Write the calculator-specific implementation for this project. Do not add third-party expression parsers, calculation engines, numerical packages, utility libraries, or test frameworks, and do not copy or vendor prewritten calculator implementations. Input handling, evaluation, calculator state, button behavior, and formatting rules must be implemented in the project source using the permitted facilities. Tests must likewise use the standard library, a simple project-written harness, or test facilities included in the selected GUI framework without introducing another dependency. Required framework internals and their transitive dependencies do not count as additional application libraries; do not add optional packages unrelated to the required application behavior.

Setup answers may further restrict these permitted dependencies, but allowing additional application libraries requires an explicit specification amendment. A general answer of “no restrictions” does not override this boundary.

OS release and architecture compatibility are implementation/toolchain details, not additional calculator features or required setup questions. Record the environments actually used and any known toolchain limitations without inventing product-level OS version requirements. Dependency acquisition and build-time network use follow the developer's environment and authorization; this specification does not require an offline build.

All selected technologies must support the requirements in this document. If the answers are incompatible, explain the specific incompatibility and ask for a replacement choice before proceeding. Do not substitute a different stack silently.

Once answers are complete, write `IMPLEMENTATION.md` with the selected profile, specification revision, target architectures, supported build environments, and consequential implementation decisions. Then continue through generation and available verification without another routine confirmation. Do not ask the user to approve each file or implementation step.

### Binary output location

Default to the repository-local `./output/` directory. Under the chosen output directory, use `<os>/<architecture>/<configuration>/` subdirectories so builds do not overwrite one another. Use `windows`, `macos`, or `linux` for OS names, `x86_64` or `arm64` for those architectures, and `release` or `debug` for configuration names; record any additional architecture names if needed. The default configuration is release. For example, a release build for an ARM64 macOS host goes in `./output/macos/arm64/release/`.

Place the executable, application bundle where applicable, and any adjacent runtime files needed to launch it together in that target directory. An executable filename or bundle structure may follow the selected platform's conventions; `BUILD.md` must identify the exact launchable artifact. Intermediate build files may live elsewhere, with their locations documented and ignored by Git. Source, tests, and documentation must not be generated into the binary output directory.

The generated project must add `/output/` to the repository-root `.gitignore` when using the default. For another repository-local output directory, ignore that selected directory instead; for an external location, no repository ignore entry is needed. Preserve existing ignore rules. Do not ignore source files or broad executable extensions. Do not delete existing output contents or other files to prepare a build. Document one build command per target that produces artifacts in the selected location without requiring manual copying. If a target has not been built, do not create placeholder binaries or claim that its artifacts exist.

## 4. Product and platform scope

Create one single-window scientific calculator with a graphical interface. It must compile into a native desktop executable for Windows, macOS, and Linux from the same project sources, allowing documented platform configuration differences.

Native means the delivered application launches as an operating-system executable and requires no browser, local web server, separately installed language interpreter, or separately installed application runtime. A framework runtime may be bundled with the application. System libraries and documented adjacent application libraries are allowed. A single self-contained file is not required. A hosted website, browser wrapper, terminal application, or remote calculation service does not satisfy this requirement.

Compilation is performed separately for each target unless the selected toolchain supports cross-compilation. Do not imply that one executable runs on all operating systems. Use the host architecture for local verification; document the architecture and prerequisites for each other target. Installers, app-store distribution, signing, notarization, and automatic updates are outside this revision.

There is no networking, account system, telemetry, advertising, database, persistent preferences, file import/export, calculation history, plotting, symbolic algebra, unit conversion, plugin system, or scripting facility. Do not add any of these.

## 5. Interface and interaction

### Application icon

Use the supplied `assets/calculator-icon.png` as the authoritative application icon. It is a 1024×1024 opaque square source asset. Import it into the project and use it for the application's executable/bundle identity and window/task-switcher icon wherever the host OS supports those surfaces. Do not substitute a generated icon, redraw it, recolor it to match the theme, add a rounded-square frame, or introduce transparent corners. The artwork is branding only; its depicted keys and colors do not override the interface requirements below.

Convert and resize this asset as needed for the icon formats, resolution variants, and packaging expected by the selected OS and implementation stack. Preserve the original PNG and its aspect ratio. Integrate the required derived assets and resource metadata into the normal build so a compiled application uses the icon without manual post-build steps. Document the conversion method and any platform-specific verification not performed. Prefer conversion tools supplied by the permitted platform/toolchain facilities; no additional application runtime dependency is authorized for icon handling. Any mandatory OS-applied presentation mask is outside the source artwork's control.

The title is `Scientific Calculator`. Use one wide scientific layout at all times; there is no compact mode or alternate function layer. Use controls, window decorations, fonts, and theme colors appropriate to the host OS. Do not hardcode an accent color or imitate another operating system's window decorations.

A full-width, noneditable display occupies the top of the window, with a large right-aligned current number or result, initially `0`. Show the active angle mode and a memory indicator (`M` when memory is nonzero) unobtrusively within this area. Errors must remain readable without truncation; the status text may wrap. An editable expression field is not part of the design.

Below the display is a visually aligned scientific keypad. The following ten-column, five-row arrangement defines the preferred grouping and order, rather than pixel measurements. Scientific controls occupy the left six columns, the numeric keypad occupies the next three, and arithmetic operators occupy the far-right column. The zero key spans two columns. Use flexible layout facilities to accommodate native controls, font metrics, and resizing while preserving these groups, their order, and access to every key. The two empty cells must not acquire new features.

| Row | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | ( | ) | mc | m+ | m− | mr | AC | +/− | % | ÷ |
| 2 | empty | x² | x³ | xʸ | eˣ | 10ˣ | 7 | 8 | 9 | × |
| 3 | 1/x | ²√x | ³√x | ʸ√x | ln | log₁₀ | 4 | 5 | 6 | − |
| 4 | x! | sin | cos | tan | e | EE | 1 | 2 | 3 | + |
| 5 | Rad/Deg | sinh | cosh | tanh | π | empty | 0 (spans 7–8) | continued | . | = |

Use proper superscripts and mathematical glyphs where supported, with equivalent readable labels otherwise. Adjacent keys have consistent spacing and alignment. Exact dimensions and font sizes are implementation choices; declare a minimum window size at which all controls remain readable and unclipped. Resizing preserves the keypad grouping, with no hidden keys or layout-mode switch. Prefer the host OS's native control appearance and palette. Do not force a visual theme belonging to another OS. The implementation mechanism is a stack choice, not a product requirement. Grouping may use the OS theme's available control styles; specific colors are not required.

### Traditional entry and calculation

Use traditional calculator input: digits build the current number; operators prepare a calculation; scientific function keys immediately transform the current value. There is no text-expression editor, caret, selection-based operation, or typed function syntax. Place visible `asin`, `acos`, and `atan` keys in a small supplementary group beside the trigonometric keys or above the main keypad, without an alternate function layer.

Starting a number after a result or unary transformation replaces that value; starting a number after a binary operator supplies its right operand. Leading zeros do not accumulate. Decimal point starts `0.` when needed; subsequent decimal points in the same mantissa are ignored. `+/−` changes the sign of the current entry/value, including before entering digits. Constants π and e supply a complete current operand at internal precision. A digit or constant entered immediately after another completed constant starts a replacement operand rather than implicit multiplication.

Binary operations are addition, subtraction, multiplication, division, power (`xʸ`), and nth root (`ʸ√x`, with the first operand as radicand and second as degree). Use scientific algebraic precedence: addition/subtraction below multiplication/division below power/root. Addition, subtraction, multiplication, and division associate left; power and root associate right at the same precedence. Unary buttons act immediately on the current operand before it is combined with pending operations. Thus entering 2, +/−, xʸ, 2, = yields 4; sign change is an operation on a value, not a typed unary-minus precedence rule.

When accepting a binary operator after an operand, first resolve pending operators of higher precedence, and those of equal precedence that associate left, within the current parenthesis group. Display the resulting current value; operations deferred by precedence remain pending. Resolve a group on closing parenthesis and all remaining operations on equals. Report errors at the action that resolves the offending operation, not earlier. When another binary operator is pressed before its right operand is entered, replace the pending operator. Do not invent an operand. `=` resolves pending operations and displays the result. With no pending operation it leaves the current value unchanged. With a missing operand or unmatched opening parenthesis it shows `Error: Incomplete calculation`. Repeated equals leaves the result unchanged; it does not repeat the last operation. A binary operator after a result continues from its full internal value; entering a new number starts a fresh calculation.

`(` starts a grouped calculation where an operand is expected. `)` resolves that group and supplies its value as an operand to the surrounding calculation. Parentheses override precedence. An opening parenthesis immediately after a completed operand or an unmatched/empty closing parenthesis shows `Error: Invalid operation`; there is no implicit multiplication or automatic parenthesis completion. Scientific buttons apply to a just-closed group's value just as to another current operand.

| Keys | Immediate operation on current value x |
| --- | --- |
| +/−; % | Negate x; divide x by 100 |
| x²; x³ | Square x; cube x |
| eˣ; 10ˣ | e raised to x; 10 raised to x |
| 1/x; ²√x; ³√x | Reciprocal; square root; real cube root |
| x! | Factorial |
| ln; log₁₀ | Natural logarithm; base-10 logarithm |
| sin; cos; tan | Trigonometric functions in active angle mode |
| asin; acos; atan | Principal inverse trigonometric functions in active angle mode |
| sinh; cosh; tanh | Hyperbolic functions, independent of angle mode |

After equals, digits, decimal point, constants, memory recall, or an opening parenthesis begin a fresh calculation. EE begins a fresh entry with mantissa 1. A unary function instead transforms the result, and a binary operator continues from it. These rules also apply when equals was pressed without any pending operation.

While a binary operator is waiting for its right operand, the display retains the last current value. A unary function or sign-change key uses that displayed value and supplies the transformed value as the right operand. For example, `9, +, ²√x, =` produces 12. Memory addition/subtraction uses the displayed value without supplying a right operand or resolving the pending calculation. Immediately after an opening parenthesis there is no current operand in that group: unary and memory-add/subtract actions do nothing until a number, constant, recalled memory value, or closed inner group supplies one. A sign-change key may begin a signed zero entry there. Closing an empty group remains an invalid operation as specified above.

`EE` begins a base-10 exponent on the number being entered; if no number is being entered, begin with mantissa 1. Digits then build the exponent, and +/− toggles the exponent sign. Repeated EE is ignored. Until an exponent digit is entered, its value is zero. A binary minus remains subtraction; use +/− for a negative exponent. Scientific notation is numeric entry, not multiplication by e.

Backspace removes the last entered digit or decimal point only while entering a number. In scientific notation, remove exponent digits first; after the last exponent digit is removed, show exponent zero while remaining in exponent entry. The next Backspace removes the exponent marker and its sign and returns to mantissa editing. Removing the final mantissa digit restores `0`. Backspace does not delete a sign set by +/− and otherwise does nothing when no numeric entry is active. `AC` or Escape resets the current value to `0`, discards all pending operations/groups and errors, and retains memory and angle mode. After an error, only AC/Escape, mode switching, and mc operate; other calculation input is ignored until cleared. Failed operations do not change memory. Errors appear without modal dialogs or application termination.

The angle button shows `Rad` in Degrees mode and `Deg` in Radians mode, naming its destination. Startup mode is Degrees; a separate indicator always names the active mode. Switching modes leaves current values and pending operations unchanged and does not recalculate prior results. Future trigonometric operations use the new mode. Mode is not persisted.

### Memory and keyboard

One numeric memory register starts at zero on launch. `mc` clears it. `mr` supplies its full-precision value as the current operand, replacing the current entry without evaluating pending operations. `m+` and `m−` add/subtract the displayed current operand's internal value to/from memory without resolving pending operations or changing the display. Memory arithmetic overflow shows `Error: Numeric range` and leaves memory unchanged. AC does not clear memory. No memory state is persisted.

Support keyboard digits, decimal point, `+`, `-`, `*`, `/`, `^`, parentheses, Enter or `=` for equals, Escape for AC, and Backspace as described above. Keyboard `^` invokes xʸ. Other scientific operations remain keyboard-accessible through normal focus navigation and button activation. Unsupported character input is ignored; pasted text and expression entry are not supported. Preserve normal focused-button activation with Space. Every control has a descriptive accessible name, and keyboard calculation input works regardless of which keypad button has focus.

### Menus and application lifecycle

Menus must follow host OS placement, naming, behavior, and keyboard-shortcut conventions; how the selected stack provides that integration is an implementation detail. Provide About and Quit/Exit where the OS convention places them: in the application menu on macOS, and under Help and File respectively on Windows and Linux. Menus provide application lifecycle and application information only; do not add calculator features or settings through menus.

- Do not add an Edit menu: this revision has no text editor or clipboard features.
- The About action opens a standard dismissible dialog containing the application name and specification revision. Do not invent author, organization, copyright, licensing, or external-link content.
- Quit/Exit terminates the application without confirmation. Closing the sole calculator window also terminates the application on every platform, including macOS. All entry, result, memory, and angle-mode state is discarded. There is no save prompt, background process, tray presence, or persistent session.

Automatically supplied platform application menu items may remain when supplied automatically. Do not build custom replacements for operating-system menus or add empty menus for hypothetical future features.

## 6. Calculation model

The public input is the sequence of calculator actions in section 5, not a programming or expression language. An implementation may internally represent pending calculations as tokens, a tree, or another structure, but that is not an additional user interface. Do not add variables, assignments, scripting, typed function calls, or implicit multiplication.

For mathematical descriptions and tests below, names such as `sqrt(x)`, `fact(x)`, and `root(x,n)` denote the corresponding button operations, not text the user types. `root(x,n)` uses the nth-root binary key. `percent(x)` denotes the percentage key. `abs` is not a required button or additional user operation.

Apply mathematical errors when an operation is actually resolved, following the precedence and grouping rules. Stop at the first error. Current-entry conversion outside the finite numeric range shows `Error: Numeric range` when that entry is committed by another operation or equals.

## 7. Mathematics and numeric behavior

Use real-number arithmetic with at least IEEE 754 binary64 precision. Complex values, arbitrary-precision modes, and symbolic results are outside scope. Constants `pi` and `e` use the implementation's available precision meeting this requirement. Arithmetic uses ordinary real addition, subtraction, multiplication, division, and exponentiation subject to these rules:

- Division by zero, including negative zero, produces `Error: Division by zero`.
- `sqrt(x)` requires `x >= 0`. `ln(x)` and `log10(x)` require `x > 0`. `asin(x)` and `acos(x)` require `-1 <= x <= 1`.
- `ln` is the natural logarithm, `log10` is the base-10 logarithm, and `exp(x)` is e raised to x.
- A negative base raised to a noninteger exponent is a domain error. An exponent is integer only when its evaluated numeric value is exactly integral; do not round it to an integer. Zero raised to zero or to a negative exponent is a domain error. Zero raised to a positive exponent is zero.
- `sin`, `cos`, and `tan` interpret arguments in the selected angle mode. Inverse trigonometric functions return values in that mode. `asin` returns its principal value in [-90, 90] degrees, `acos` in [0, 180], and `atan` in (-90, 90), with the equivalent intervals in radians.
- To handle tangent singularities consistently across libraries, compute the argument in radians and treat `abs(cos(argument)) <= 1e-12` as a domain error. Otherwise evaluate tangent normally.
- `percent(x)` means x divided by 100 in every context. There is no context-dependent business-calculator percentage behavior: `200+percent(10)` is `200.1`.
- `cbrt(x)` is the real cube root, including for negative x. `root(x,n)` is the real nth root: n must be an exactly integral, nonzero value. Negative x requires odd n. Negative n means the reciprocal of the corresponding positive-degree root; zero x with negative n is a domain error. Zero x with positive n returns zero. Evaluate x before n, then check domains. Do not implement negative odd roots using a power operation that rejects fractional exponents of negative bases.
- `fact(x)` requires a nonnegative, exactly integral argument and returns the product of integers from 1 through x; `fact(0)` is 1. Nonintegral or negative arguments are domain errors; a factorial exceeding the finite numeric range is a numeric-range error. Do not extend factorial to the gamma function.
- `sinh`, `cosh`, and `tanh` are the real hyperbolic functions, independent of angle mode. Use numerically stable standard-library implementations where available; intermediate overflow must not turn a finite representable result such as `tanh(1000)` into an error.
- Violations of these domains produce `Error: Domain`. Do not clamp arguments into valid ranges.
- A numeric literal outside the finite supported range, or an operation whose result overflows to a nonfinite value, produces `Error: Numeric range`. Mathematical domain rules take precedence over a library's NaN or infinity result. Underflow to a finite subnormal value or zero is allowed.

Resolve pending calculations according to section 5; unary keys evaluate immediately on the current operand. Do not expose library exceptions, NaN, infinity, or stack traces as results.

For numeric acceptance, compare finite internal results using `abs(actual - expected) <= 1e-12 * max(1, abs(expected))`. This tolerance defines conformance for the cases below; it does not promise equal last bits across math libraries or reliable results for arbitrarily ill-conditioned inputs.

Display finite results with 12 significant decimal digits, rounding to nearest with ties to even. Remove unnecessary fractional trailing zeros and a trailing decimal point. Use a decimal point independent of locale, no digit grouping, and no leading plus. Normalize a result that rounds to zero, including negative zero, to `0`.

Use ordinary decimal notation when the rounded nonzero value has base-10 exponent from -6 through 11 inclusive; otherwise use scientific notation with lowercase `e`, an explicit exponent sign, and no exponent-leading zeros. For example, display `0.000001`, `1e-7`, `100000000000`, and `1e+12`. While entering a number, preserve the entered decimal point and trailing zeros so users can see their input. Apply result formatting after an operation or evaluation; continuing calculations always uses full internal precision.

## 8. Security review without unsolicited changes

Always generate `SECURITY_REVIEW.md` after source generation, even when no concerns are identified. Review the actual generated code and dependencies, not only this specification. State the scope and limitations of the review; do not claim a formal audit or guarantee of security.

For each finding, include the relevant file or component, observed behavior, practical impact, evidence or reasoning, whether the specification requires the behavior or leaves a gap, and a proposed mitigation for the user to consider. Distinguish confirmed findings from unverified concerns. If no findings are identified, say so and list what was reviewed. Record dependency versions and whether vulnerability information was actually checked; do not claim a current dependency audit without performing one.

For example, this specification does not prescribe a pending-operation limit, parenthesis-depth limit, or execution time budget. If the implementation can freeze or exhaust resources on extreme input, report that concern and offer limits as an optional amendment. Do not silently add input limits or other behavioral restrictions. Handling invalid action sequences as specified in section 5 is required conformance, not an optional improvement.

Treat calculator input as data. Implement entry handling and pending-operation evaluation in the project source within the dependency boundary in section 3. General-purpose language evaluation, shell execution, or dynamic code execution of calculator input is outside the specified calculator behavior and must not be used. This is an explicit requirement, not permission to add unspecified security features.

Security findings do not block delivery of an otherwise complete implementation. Present unresolved concerns plainly and leave proposed changes unimplemented unless the user authorizes an amendment. If governing instructions prevent implementing a requirement, explain that limitation instead of silently substituting behavior.

## 9. Acceptance and verification

Include automated tests for the actual calculator state, action handling, mathematics, errors, and formatting; do not test a separate reference implementation. Use section 7's numeric tolerance except for exact display/error checks. Each action sequence below starts from a fresh launch unless stated otherwise. Commas separate button presses; multi-digit numbers abbreviate their digit presses.

| Actions | Expected result or state |
| --- | --- |
| 2, +, 3, ×, 4, = | 14 |
| (, 2, +, 3, ), ×, 4, = | 20 |
| 8, ÷, 4, ÷, 2, = | 1 |
| 2, xʸ, 3, xʸ, 2, = | 512 |
| 2, +/−, xʸ, 2, = | 4 |
| 2, xʸ, 2, +/−, = | 0.25 |
| 9, +, ²√x, = | 12; unary key supplies transformed displayed value as right operand |
| 5, +, m+ | Memory 5; right operand still missing |
| 2, +, 3, × | Display 3; addition remains pending |
| 2, ×, 3, + | Display 6; multiplication resolved |
| 1, ÷, 0, + | `Error: Division by zero` at + |
| 2, +, 3, =, π | Fresh calculation with pi as current value |
| 2, EE, +/−, 3, Backspace, Backspace | Entry 2; exponent removed, mantissa editing resumed |
| 2, +, ×, 3, = | 6 (operator replacement) |
| 9, ²√x | 3 immediately |
| 2, +, 3, x², = | 11 |
| (, 2, +, 3, ), x², = | 25 |
| 32, ʸ√x, 5, = | 2 |
| 8, +/−, ³√x | -2 |
| 16, ʸ√x, 2, +/−, = | 0.25 |
| 5, x!; separately 0, x! | 120; 1 |
| 1.5, x!; separately 1, +/−, x! | `Error: Domain` |
| 10000, x! | `Error: Numeric range` |
| 25, % | 0.25 |
| 200, +, 10, %, = | 200.1 (percentage always divides current operand by 100) |
| 30, sin; separately 60, cos; separately 45, tan | 0.5; 0.5; 1 in Degrees |
| Rad, π, ÷, 2, =, sin | 1 in Radians |
| 1, asin; separately 1, +/−, acos; separately 1, atan | 90; 180; 45 in Degrees |
| Rad, 1, asin | pi/2 in Radians |
| 0, sinh; separately 0, cosh; separately 1000, tanh | 0; 1; 1 |
| e, ln; separately 100, log₁₀; separately 0, eˣ | 1; 2; 1 |
| 1, ÷, 0, =; separately 0, 1/x | `Error: Division by zero` |
| 1, +/−, ²√x; separately 0, ln; separately 2, asin | `Error: Domain` |
| 0, xʸ, 0, =; separately 0, xʸ, 1, +/−, = | `Error: Domain` |
| 8, +/−, ʸ√x, 2, =; separately 4, ʸ√x, 0, = | `Error: Domain` |
| 90, tan | `Error: Domain` in Degrees |
| 10000, eˣ | `Error: Numeric range` |
| 2, EE, +/−, 3, = | 0.002 |
| ., 5, ., 0 | Entry `0.50`; second decimal point ignored |
| 2, +, =; separately (, 2, = | `Error: Incomplete calculation` |
| ); separately 2, ( | `Error: Invalid operation` |
| =, = | 0 |
| 2, +, 3, =, = | 5 |
| 1, ÷, 3, = | Exact display `0.333333333333` |
| 1, ÷, 3, =, ×, 3, = | 1 using full internal precision |
| 2, +, 3, =, 7 | New entry 7, not 57 |
| 5, m+, AC, 2, m−, AC, mr | 3 with M indicator; mc clears M; subsequent mr supplies 0 |
| 5, +, 2, m+, = | Result 7 and memory 2; m+ does not resolve addition |
| 30, sin, Rad | Value remains 0.5; active mode changes to Radians |

Also test numerical domain boundaries, root-degree integrality, hyperbolic independence from angle mode, memory overflow preserving memory, Backspace during entry, mode/memory retention across AC, and error recovery through AC. Test the formatting rounding rule and exact displays `0`, `0.000001`, `1e-7`, `100000000000`, and `1e+12` for their respective values.

Verify the GUI manually or through GUI automation on available selected platforms: startup state, flexible scientific keypad grouping, double-width zero, visible inverse functions, no compact or alternate-function mode, every key's operation, keyboard equivalents and focus accessibility, mode/memory indicators, native styling, and unclipped layout at minimum size. Verify platform menu placement, About contents and dismissal, and termination through both Quit/Exit and window close. Relaunch restores startup state. Do not claim GUI checks from unit tests alone.

Run builds and tests when the environment permits. Missing compilers, unavailable operating systems, or unavailable GUI sessions must be reported as unverified, with exact commands the user can run. Source generation can be complete with explicitly unverified targets; cross-platform execution cannot be claimed until checked. Do not download tools, install system packages, or perform privileged changes without applicable authorization. Do not let unavailable platforms prevent delivery of the complete source project.

## 10. Required delivery and completion criteria

Deliver these repository files and artifacts:

- Complete application source and resources, with no placeholder implementation or outstanding required TODOs.
- Build configuration and dependency declarations, including exact direct dependency versions and supported lockfiles where applicable. Document necessary system dependencies separately.
- Automated tests and instructions for running them.
- `BUILD.md`: prerequisites, supported toolchain versions, and concrete build/run commands for Windows, macOS, and Linux; the selected output directory, exact launchable artifact paths, and any runtime files to distribute. Users must not need to invent missing configuration or source files.
- A repository-root `.gitignore` excluding the selected repository-local binary output directory and generated intermediate build files, while preserving existing rules.
- `IMPLEMENTATION.md`: the setup profile, implementation decisions, selected target architectures, and any approved amendments or known deviations. Do not store machine secrets or absolute paths specific to the generating machine as build requirements.
- `VERIFICATION.md`: checks performed, commands, observed outcomes, toolchain/platform details, failures, and checks not performed. Distinguish generated, compiled, tested, and manually verified status.
- `SECURITY_REVIEW.md` as required by section 8.

Preserve this README as the specification. Organize other source and test files according to the selected stack. Do not add unrelated project infrastructure, CI services, containers, deployment tooling, promotional content, or extra product documentation. Do not commit, push, publish, or release without a separate instruction.

The initial implementation is complete when the selected profile is recorded, all required source and supporting files exist, available verification has been performed and reported, and the security review has been delivered. Report any unmet requirement rather than hiding it behind a claim of completion. The final response should identify the chosen stack, files to consult, build/test status, unverified platforms, deviations, and security findings requiring the user's attention. Optional suggestions belong after that report and must remain unimplemented.

The measure of success is a faithful, reviewable implementation another human or agent can reproduce from this document and its recorded setup profile. Additional functionality does not earn credit for this revision.