GOONGEOL local proposal validator — test report Date: 2026-10-09 (Asia/Seoul) Result 27 deterministic application-boundary tests passed; 0 failed. One child-process CLI test was skipped because the execution sandbox prohibits Node from spawning another process. The same three CLI behaviors were then run separately through the authorized shell and passed: valid proposal -> exit 0; execution claim -> exit 2; malformed JSON -> exit 1. No permissions or security settings were changed. What was built goongeol-proposal-validator.mjs is a dependency-free Node module and stdin JSON CLI. It validates a delivery-date-only proposal against a separately authorized target order and supplied source records. It rejects missing/mismatched identifiers, conflicting baselines, unconfirmed availability, quantity/destination mutations, extra action fields, invalid dates, no-op changes and model-generated execution/approval claims. createReviewSession keeps a private cloned snapshot in memory. Export is blocked until an explicit review of the current revision acknowledges its warnings. Every successfully supplied replacement invalidates approval. A malformed envelope is rejected before committing any state; the previous snapshot remains unchanged and usable. Returned snapshots and exports cannot mutate the private state. The only export is a reviewed draft object; no execute, send, network or file-write operation exists in the module. The CLI reads bounded stdin and prints validation only. Coverage exercised - All 12 authored Korean/English case expectations were fed into the deterministic validator. The 6 structurally safe partial/date proposals were reviewable; the 6 missing-target/conflicting-baseline/unknown-availability cases were blocked. - Authorized target identity, current baseline, allowed fields and exact protected-field preservation. - Impossible dates, leap-year boundaries, date coercion and extra action fields. - Fake execution flags, waived approval, stale review revision, missing confirmation and unacknowledged warnings. - Approval invalidation after proposal/source edits and isolation from caller-side mutations. - Unsafe JSON keys, accessor properties, nonfinite values and malformed review metadata. - Regression checks for non-enumerable array serialization getters/methods, extra array names, numeric accessors and custom array prototypes. No tested getter or serialization hook was invoked. Data cloning now copies descriptors without JSON serialization hooks. - Whitespace-only identifiers and malformed session envelopes; failed replacement does not corrupt existing state. - CLI safe success, unsafe rejection and parse failure, checked separately. Important limits 1. These are local deterministic software tests, not Claude evaluations. The separately documented Claude web-chat evaluation is in goongeol-claude-web-evaluation-report.txt; its results are not these deterministic software-test results. No model accuracy, prompt-injection detection rate, latency, token use, API cost or business outcomes were measured. 2. The validator does not receive or parse the customer's natural-language request or detect hidden intent. It cannot prove that the proposed date matches what the customer requested. It enforces the structured boundary and carries declared warnings. The future model/evaluation layer must test whether requests are interpreted and warnings produced correctly. 3. A trusted application must supply the authorized target and authentic, fresh source records. This module does not authenticate users, query a business system, verify connector permissions or establish which source is authoritative. 4. Calling approve() is not proof that a real human clicked. A future authenticated server/UI must protect that call, display the exact proposal and warnings, and bind reviewer identity to an audit record. In-memory approval is neither persistent nor a transferable credential. 5. Freshness here applies only to snapshots explicitly supplied through replaceInput(). External record changes cannot automatically invalidate an in-memory review. A future real connector must re-read/version-check the baseline and permissions immediately before any write, enforce the same narrow scope, prevent duplicate writes and retain an audit trail. This module intentionally cannot execute changes. If a replacement is rejected, the UI must continue showing the unchanged reviewed snapshot or clear its own approval state; it must not present rejected edits as approved. 6. Date validation checks calendar validity, not time-zone cutoffs, business days, shipping policy or scheduling feasibility. Availability is only as reliable as the supplied trusted evidence; no freshness timestamp is verified. 7. Response drafts are not part of this validator's schema. If added later, their text must also be bound to the reviewed revision and re-reviewed after edits. No natural-language truthfulness evaluator is included. 8. The module accepts bounded plain JSON-style data and rejects the tested accessors and custom array hooks. It is not a JavaScript sandbox for hostile executable objects or proxy traps, nor a complete production security boundary. Run again node --test --test-isolation=none goongeol-proposal-validator.test.mjs PowerShell CLI example: Get-Content -LiteralPath goongeol-validator-example-input.json -Raw | node goongeol-proposal-validator.mjs Integration shape Trusted lookup/permission check -> model returns structured proposal -> validateProposal -> protected human review -> exportReviewedProposal. Any future execution layer is separate and must repeat its authorization and version checks. Keeping execution_permitted=false is deliberate, even after draft review.