Repository navigation
Support REP Yes/No universes with shared fork navigation - #1158
Open
KillariDev wants to merge 24 commits into
Open
KillariDev wants to merge 24 commits into
KillariDev wants to merge 24 commits into
Conversation
…election # Conflicts: # docs/assets/screenshots/fingerprints.json # tooling/repo/source-size-policy.ts # ui/trading/ts/features/TradingDeploymentSetup.tsx
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
REP Yes and REP No are the two canonical Zoltar roots, descended from the Augur v2 universe. Each deployment supplies its selected REP token through Zoltar's existing constructor argument. The UI names the roots Augur v2 › Yes and Augur v2 › No; each is local universe
0in its own deployment.genesis=yes|nochoice in all three apps. A missing or invalid choice shows the verified historical fork question before starting the backend.UniverseBrowserView, the route-heading pattern, universe summary/status badge, fork-question section and outcome controls between the historical entry and future forks. Historical facts are supplied directly; live universes retain their loader, actual ID/supply/timestamp, actions and child state. No historical Zoltar metrics are invented.Protocol execution and ABI are unchanged. Solidity edits from main are comments. Bots and augurScan keep explicit Yes deployments; dual scanner ingestion is outside this change.
Current validation
bun run tsc, all shared/app/worker builds and all three production bundles pass with pinned Bun 1.4.2.bun run format:check, fullbun run check,bun run knip,bun run check:generated-cleanandgit diff --checkpass.genesis=yesbypasses the chooser and live callers omitpendingLabel), so those images remain visually current. Broad source-fingerprint warnings are recorded for this last change; hashes are not falsely marked fresh and strict freshness is not claimed on the final head.4c9a609389cfd995b39a1674010258d62742f4c5. Fetchedorigin/mainafter the final fix: zero commits behindd144ad301; worktree clean. The PR remains unmerged.Resulting UI
The historical Augur v2 universe and future forks share the same browser presentation:
Desktop and mobile across all three apps
The 14 resulting-UI images include the final stable pending states; unchanged live views retain their verified post-merge captures. All were uploaded through the permanent Catbox endpoint and download-SHA256 verified; QA images are not committed. Registered documentation figures use the canonical capture command.
Augur question/identity source: final fork record.