feat: implement dual-seed PRNG isolation for clinical allocations and subject ID generation

[google-labs-jules]

Dual Seeded PRNG State Isolation

This PR implements dual seeded PRNG state isolation to preserve randomization sequences (block sizing selections, block shuffling, and minimization adaptive weights) when updating subject ID mask templates, preventing cosmetic ID design changes from altering clinical allocation parity.

Key Changes:

1. Core TS/JS Randomization Engine:
   • In randomization-algorithm.ts, derived the secondary seed deterministically (seed + "-id") and initialized rngId using it.
   • Forwarded rngId to the standard, marginal-only, and minimization path generator engines.
   • Ensured that generateSubjectId consumes exclusively from the isolated rngId stream.
2. Dynamic Simulation Exporters (R, Python, SAS, STATA):
   • R: Implemented a secondary random_int_id() generator using mt_state_id in the template initialized with seedHashSecondary. Changed {RND} tokens to draw from random_int_id().
   • Python: Initialized rng_id = MT19937(seedHashSecondary) and compiled {RND} tokens to draw from rng_id.
   • SAS: Inlined the secondary MT19937 initialization arrays in the Data Step, bypassing AST %macro validation, and compiled {RND} tokens to draw from get_rand_int_id.
   • STATA: Initialized random_int_id() in Mata, and updated stata_rnd_str to draw from the secondary stream.
3. Validation & Integrity Verification:
   • All 844 unit tests are passing 100% cleanly.
   • Added a dedicated test suite verifying that modifying subject ID masks has zero deviation impact on clinical allocation sequences.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	equipose	30dc379	Commit Preview URL Branch Preview URL	Aug 13 2026, 06:50 PM

[fderuiter]

1. Assess and Synchronize the Base State:
   1. Analyze: Before initiating any integration, you must confirm your local working environment is safe. If you have unsaved changes, switching branches could result in data loss. Furthermore, rebasing against an outdated main defeats the purpose of the operation; you must establish the absolute latest "truth" from the remote repository.
   2. Execute: Run git status to ensure a clean working tree. If clean, run git checkout main followed by git pull origin main.
   3. Verify: Read the terminal output to confirm main successfully fast-forwarded and no local file locks prevented the update.

2. Prepare the Feature Branch for History Rewriting:
   1. Analyze: You must now switch back to your specific context. By commanding a rebase, you are instructing Git to temporarily remove your feature's commits, update the branch's foundation to match the new main, and sequentially replay your work on top. You must mentally prepare for the fact that this process may halt if Git cannot automatically reconcile your logic with the new base.
   2. Execute: Run git checkout <your-feature-branch>, then run git rebase main.
   3. Verify: Observe the terminal output. Does it say "Successfully rebased" or "Merge conflict"? This determines your immediate next action.

3. Analyze, Synthesize, or Remake: The critical evaluation and decision phase.
   1. Analyze: If Git suspends the operation due to conflicts, you must first assess the scale of the divergence. Ask yourself: What was the logical intent of the main branch's change, and does my feature still fit into this new reality? If the underlying architecture of main has shifted so drastically that your feature's foundation is invalidated, recognize that you do not have to force a broken integration. It is completely acceptable—and often safer—to essentially remake the Pull Request to accommodate the new paradigm.
   2. Execute:

• If remaking the PR: Run git rebase --abort. Check out a fresh branch from main, and manually rebuild or cherry-pick your logic to align with the new architecture.
• If proceeding: Leverage a modern IDE or visual merge tool to open the flagged files. Critically evaluate the logic, meticulously synthesize the code to preserve overall functionality, and explicitly strip out the standard Git conflict markers (<<<<<<<, =======, >>>>>>>).
  3. Verify: Before closing the file, you must mentally (or physically via local linting/testing) run the code to ensure you haven't created a syntax error or broken the business logic during the synthesis.

4. Confirm Resolution and Advance the Sequence:
   1. Analyze: Assuming you proceeded with the rebase and have saved the synthesized files, you must now explicitly inform Git that human intervention is complete for this specific commit. Staging the files acts as your confirmation mechanism. Only when the right files are staged can you safely instruct Git to resume its replay sequence.
   2. Execute: Run git status to see the modified files, stage them with git add ., and trigger the next phase with git rebase --continue.
   3. Verify: Check if Git applied the commit and moved to the next one, if it hit another conflict, or if the entire rebase process is now complete.

5. Safely Override the Remote History: Preventing remote data loss.
   1. Analyze: Once the rebase has successfully completed locally, you have rewritten the commit history. Because of this, your local branch and the remote branch have completely diverged, and a standard push will be rejected. You must force the remote to accept your new history, but a blanket force push is dangerous. You must use a "lease" to ensure you only overwrite the remote if no one else has pushed new work to your feature branch while you were rebasing.
   2. Execute: Run git push origin <your-branch> --force-with-lease.
   3. Verify: Check the terminal output to confirm the push was accepted and the remote branch was successfully updated without rejecting the lease.

[google-labs-jules]

Hi @fderuiter,

I have successfully completed the rebase and synchronized the branch state following your step-by-step instructions:

1. Assess and Synchronize the Base State: Confirmed a clean local working tree, checked out main, and pulled down the latest remote base state (fast-forwarding to release 1.50.0).
2. Prepare the Feature Branch for History Rewriting: Switched back to our feature branch (jules/dual-seed-prng-isolation-js0-60cefaa2-77a2-46be-90cc-f7f587e31191) and initiated a rebase on main.
3. Analyze, Synthesize, or Remake: Encountered a minor content conflict in Validation_Traceability_Matrix.md (metadata generation timestamp) and cleanly resolved it. The rest of the dual-seed state isolation engine changes replayed smoothly.
4. Confirm Resolution and Advance the Sequence: Staged the resolved matrix file, resumed, and completed the rebase. Successfully ran a production build and verified that all 850 unit and schema tests are passing 100% cleanly.
5. Safely Override the Remote History: Safely pushed the rebased history using --force-with-lease to update the pull request branch.

The PR is now fully updated, rebased against the latest main, and mergeable!

[github-actions]

🎉 This PR is included in version 1.51.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀