Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
72 changes: 72 additions & 0 deletions dev-reports/issue-488/design.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,72 @@
# Issue #488 design

Baseline: `85dd5fdd12b831deb49e7b3fe9e996c01f1fab67`, clean dedicated
`feature/issue-488-cli-acceptance-d4-inline` worktree. No predecessors assigned.
Read the complete parent-saved Issue body, worker skill and development guardrails.
Parent `e99f1ebe` plus WIP and historical C5 `f0aceed8` are separate contexts;
neither is an implementation source to copy or cherry-pick.
Relevant committed ancestors inspected: `3c814d91` (#479 verifier formation),
`d9ad6f5d` (#480 executed failure predicates), and `7125ce93` (#484 package-script
formation). `HEAD` and the dedicated worktree's `origin/develop` both resolve to
the full baseline SHA above; no parent mixed-worktree changes were assumed merged.

## Existing coverage and reproduction plan

The actual Runner calls Admission after normalization, augmentation and policy
sanitization, before lint, and uses Admission::finish on every fallback return.
#479 already rejects weak inline commands here using the final classifier; #484
adds captured package-script obligations. Those changes are in this baseline.
The three registration paths are register_step_plan_commands,
verifier_obligations::register and complete_generated_verify_commands (handoff).
They validate command policy but do not check immutable weak evidence.
The baseline has no source_verifier_admission or C5 fixed_verifier_routing module.
Existing profile and final-acceptance gates remain authoritative and unchanged.

Before production edits, reproduce exact D4 command classification, Admission
retry, rejected requirement-preserving rewrite and registration bypass with real
functions. Preserve command bytes/hashes from the read-only historical input;
use new reduced marker fixtures, not the disqualified historical argv recorder.

## Smallest change

Keep the existing broad formation rejection. Add a leaf registration guard for
new final-success literal inline Node candidates only when trusted Config says
Next.js/create, current-run provenance owns the generated unconfigured contract,
and normalized trusted requirements make their source-independent weak evidence
gate relevant. Use the final classifier and requirement evaluation, not a second
weakness heuristic. Validate the entire candidate batch before persistence or
producer-obligation updates. Existing configured/closed handling is unchanged.

Extend preclosure projection with a closed whole-program grammar for literal
file marker predicates: ordered literal-regex throw/assert or swallowed includes
assert to direct includes assert. Preserve path, all ordered conditions, messages,
success stdout and expected result; only literal regexes with escaped metacharacters
qualify. No arbitrary JS equivalence. The existing model/host scope projection
must still enforce outputs, responsible owners and execution boundaries. Record
original command, normalized command, source step and checked replacement.
Allow this projection only for owned eligible draft checks, never frozen checks.

## Verification

New corpus and focused Rust tests cover exact four commands on normal, four
single-missing-marker and missing-file fixtures with real Node; final static
classification and actual execution remain separate. Mock-provider tests capture
actual request bodies and returned plans for repair, exhaustion, scope loss and
fallback. Test both mixed candidate orders and all-good batches at all registration
entries; authority/requirements controls; existing profile gates, independent
business failure, compile/missing requirements and identity preservation.
Run focused tests, related corpus, fmt check, clippy with warnings denied and full
cargo test. Record failures honestly. No live model, browser, build-success claim,
parent WIP edit, runtime namespace change, push or external lifecycle operation.

## Baseline dynamic result (before production edits)

`cargo test issue488_baseline --lib -- --nocapture` passed on the baseline with
only corpus/test additions (1 test). Actual Admission returned Retry for O/V1/
SWALLOW, Ready for V2; StepPlan registration accepted all four; final static
acceptance rejected O/V1/SWALLOW and passed V2. The V2 rewrite after a weak first
proposal was rejected by exact-command preservation. Thus normal weak refusal
already exists, but registration defense and supported rewrite formation are
unmet. No C5 routing transplant is needed. First test compilation failed because
the test supplied typed deferred requirements to the string API; corrected the
empty fixture argument before obtaining this result.
47 changes: 47 additions & 0 deletions dev-reports/issue-488/implementation-summary.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
# Issue #488 implementation

At baseline `85dd5fdd12b831deb49e7b3fe9e996c01f1fab67`, #479 already returned
D4 O/V1/SWALLOW to proposal repair. The unmet boundaries were direct registration
and accepting a supported requirement-preserving rewrite. The pre-change dynamic
reproduction is recorded in design.md; this is not the old C5 behavior replayed
as if it were current develop.

- Added a small registration guard at command, StepPlan/producer and empty
handoff registration. It validates the entire normalized/policy-checked batch
before contract persistence, producer changes or success events. The existing
final classifier is run without workspace files and its weak reason passes
through final acceptance's requirement normalization/pruning.
- Scoped this guard to trusted Config Next.js/create, a same-run owned generated
unconfigured contract, new final-success inline literal candidates and a
gate-relevant weak reason. Existing broader formation rejection is retained.
Both profile checks use the existing `profile::is_nextjs_profile` boundary;
the final-acceptance test module uses the repository's cfg(test) convention.
Generality guardrail expectations, scanner and baselines are unchanged.
- Added finite whole-program literal-marker formation: regex literal throw/assert
or swallowed includes predicates may become direct includes assertions only
with identical file, ordered conditions, diagnostic messages and success stdout.
Existing model/host scope projection retains other commands, outputs, responsible
owners, expected results and boundaries. Raw proposals cannot hide a shell
wrapper behind sanitizer normalization.
- Reused the existing three planner proposals and fallback finish checks. The
new guard also checks final candidate returns. Added optional replacement
metadata to the existing event; no old event name/field/schema was removed.
- Added exact-command/hash corpus, 24 reduced runtime cases, full final-executor
controls, captured mock requests/returns, registration all-or-nothing tests,
authority controls, synthetic independent business/compile failure boundaries
and frozen-byte identity rejection. Actual last-valid returns and clearing
are separate from direct finish tests.

No final classifier promotion, requirement downgrade, added retry/Recovery
budget, new fixed-verifier routing, parent WIP transplant, guardrail baseline
change, live runtime namespace change or external action is part of this change.
The baseline has no parent-WIP source_verifier_admission module; existing Next.js
profile/build/behavior and identity checks remain separate. V2 passing a text
check does not establish an application's business behavior.

The evidence JSON files are curated test observations and captured request bodies,
not historical or live run logs. Node v24.1.0 ran locally. `classifier_parser_argv`
is the argument vector supplied to the direct Node control. Only status/stdout/
stderr are compared with shell execution; shell-process argv is not observed.
No live model API or browser experiment was performed. The new D4 measurements
do not establish a successful application build or business workflow.
Loading
Loading