Repository navigation
feat: expose hash input components through id_hash_debug #3097
Description
Situation and need
The application exposes backend-derived id_hash metadata, but a user cannot inspect which configured components contributed to a hash. On main a4c18bfa66aad051627378ae885798af405ed59e, no id_hash_debug field exists in application source.
The user requested an adjacent id_hash_debug collection of strings, with as many strings as components concatenated/reordered to build the hash, including participating variables. Their illustrative command/profile example is:
["codex", "--yolo -m gpt-6.1-sol -c model_reasoning_effort=high --dangerously-bypass-hook-trust"]Intended change and scope
Expose the real inputs through the requested informational string collection, reconciled with the actual hash implementation. Preserve existing hash values, stable IDs, and runtime behavior. Cover the necessary derivation, serialization, persistence and transport paths for the existing hash metadata. The architect-authored exact plan-v3 set has complete owner and independent-review consensus, recorded below; implementation follows its mapped sequential phases and cold gates. This issue is a bounded addition, not a reopening of delivered #3047 or authorization to execute other pending #2432 packages.
Verified source facts
src-tauri/src/config/settings.rs:4945:identity_preimageexpands Unicode lowercase, removes Unicode whitespace and sorts characters across the supplied parts. It does not shell-tokenize commands.settings.rs:4959: base inputs include the configured command and every configured environment key/value; theconfiguration_identitycomment at line4984 includes disabled rows.settings.rs:4968,4998: profile input and base input feed the pair identity. Legacy base metadata and profile-cell pair metadata are distinct.settings.rs:4991,5008,5036: effective base/pair refresh and physical pair refresh are separate paths.src/shared/types.ts:434,569: both metadata surfaces have optionalid_hash.
Original evidence baseline: a4c18bfa66aad051627378ae885798af405ed59e; affected-source review refreshed it to design baseline 9813d6a59ec67e67905331fd492ec57c63e2024b. The approved contract exposes original configured leaf strings on base and pair records, preserving base env vector order and profile env BTreeMap order. Exact lifecycle, compatibility and verification are fixed by the reviewed phase specifications below.
Acceptance criteria
- The requested
id_hash_debugis a collection of strings adjacent to applicableid_hashmetadata and exposes the components actually used in that hash, including participating configured variables. - The grouping and ordering contract is explicit, matches the current hash implementation, and explains the user's example with and without variables.
- Existing hash outputs, stable identifiers, command launch behavior and persisted source ownership remain unchanged.
- Metadata is derived consistently from the correct physical/effective source; stale or supplied diagnostic metadata cannot misrepresent newly calculated hashes.
- Existing data remains readable and necessary frontend transport preserves the collection. Focused verification proves actual input coverage and unchanged hash outputs.
No unrelated CI repair, new runtime/GUI behavior, packaged binary, installation, release or version bump is requested. No product implementation begins before a fresh immutable canonical plan and exact-version consensus under the applicable workflow. Standing user authorization applies within this scope.
Approved sequential phase delivery
Exact-set consensus: plan-v3 B86F5DC6F3813AF551FD1055953829DC0493936AD82EAE1BAF05DA8D1520351E; architect, both actual owners and both independent Grinches approved the same complete set. The original requested feature scope is unchanged. Standing user authorization applies to this in-scope consensus; implementation follows the separate cold gate.
| Phase | Native child | Class | Owner | Files | Depends on |
|---|---|---|---|---|---|
| P01 inert storage | #3098 | mechanical | ac-dev-rust-v5 | 19 (one-rule exception) | none |
| P02 metadata schema/neutrality | #3099 | design-bearing | ac-dev-rust-v5 | 2 | P01 merged |
| P03 derived persistence | #3100 | design-bearing | ac-dev-rust-v5 | 4 | P02 merged |
| P04 typed transport | #3101 | patterned | ac-dev-webpage-ui-v5 | 2 | P03 merged |
The union is21 product files. Each child has its own branch and PR from current main, after its dependency lands. Phase PRs close their child only. The epic stays open until all children and the required final integrated main validation finish. No packaged build/install/release/version change was requested.
Activity
mblua commentedon Oct 18, 2026
Technical scoring for #3097, using the confirmed change at
a4c18bfa66aad051627378ae885798af405ed59e, architect candidate v1C9F54A6539229FE784B1DA3FE1BAB19413E663D8A7523CDE788112CF5674747E, and independently verified 21-file envelope (19 Rust files including settings.rs, plus TS types and IPC fixtures).Raw sum: 55/200. Final:
round((55-10)/190*99)+1= 24/100.Excluded as ceremony: issue/branch creation, delegation, messaging, review rounds, PR, push, waiting for CI, merge/cleanup, release/version/changelog work. No unrelated main-coverage diagnosis or repair is included.
Score band: low, but Full veto applies because the change adds a serialized/schema/persistence contract. This selects architect author, owning dev plus Rust Grinch plus architecture Grinch reviewers, with four matching exact plan digests. The state/data score10 also independently selects the architect contract; verification score8 requires independent review of the proof. Not Express or an implementing Narrow bypass.
Formal Full partition rule must be resolved by the architect in the canonical plan: the candidate has21 files and mixed substantive/constructor work. The rule partitions when more than10 files, more than one owner or more than one contract changes, except a single mechanical rule across N files validated by one command. One behavior owner alone is not that exception. Architect must supply a compliant minimum cut/partition or evidence that the actual final cut meets the stated exception; coordinator does not design the phases or waive the rule.
Rust candidate feasibility and final file/fixture inventory are still pending. The owning dev may dispute exactly one category using source evidence before implementation. This score is technical cost, not an implementation authorization. Canonical immutable plan, exact-version consensus and cold gates remain required; standing user authorization covers in-scope execution once those exist.
mblua commentedon Oct 18, 2026
Delivered readable id_hash_debug metadata beside id_hash, including original configured command/profile strings and environment keys/values. Existing identity hashes and runtime behavior are preserved.
All four native phase issues are closed:
Final merge: 8118af2, with tree ef95bd659d355049d2a7535c9576d1c3af416e2f exactly equal to reviewed and CI-validated feature commit 93573d8. The repository is clean on synchronized main; the feature branch is removed.
Independent source/proof reviews and completed local schema/hash/persistence checks passed across the phases. Final phase local checks passed: nine Rust layering tests, formatting, and unchanged PRE/POST module structure. Required PR CI succeeded on the exact final feature head (run 39144010162; normal light tier). Its optional frontend-regression job was skipped. Local frontend checks and extra final local reruns were not executed after the user directed normal CI followed by merge; no additional toolchain was installed and no skipped check is represented as a pass.
No packaged build, installation, release, or version change was requested or performed. No remaining feature work.