Jujutsu Zero Progression Planner

Begin by choosing the goal that best describes the next outcome you want to investigate. The selector does not assign a permanent build and it does not claim that the chosen path is mandatory. It simply replaces a large wiki archive with a focused reading and verification queue. Read the short reason under each task before opening its guide. That reason explains the decision the page can support, so you know what question to bring into the game rather than passively copying every detail you see.

Open the linked page and note its evidence status and review date. A verified page has passed this site's publication standard for the claims it actually makes, but its date still matters. Compare any patch-sensitive prompt, item label, activity entrance, reward preview, or confirmation screen with your live client. Mark the task complete when you have made the relevant comparison or decision for your own route. Completion means you performed the check; it does not convert an unknown rate or requirement into a confirmed fact.

The checklist saves separately for every goal in local browser storage. You can leave one route partly complete, inspect another route, and return without combining their tasks. Use Copy current plan when you want a portable text record containing task state, guide routes, evidence labels, and page review dates. Reset this goal clears only the selected checklist. If browser storage is blocked, the tool continues to work for the current visit and reports that the local save is unavailable.

1. 01
   Choose one outcome

   Select the route that matches the decision you need to make now, not every feature you may eventually want.

2. 02
   Read the reason

   Use each task's why-it-matters note to define the question you will verify in the current client.

3. 03
   Check the dated guide

   Open the linked field file and pay attention to its evidence status, review date, and stated uncertainty.

4. 04
   Compare with the game

   Let current prompts and visible results override older wording whenever the two no longer agree.

5. 05
   Record the checkpoint

   Mark the task complete and copy the plan if you need to resume on another device or share the research state.

A static progression staircase usually assumes that every player has the same technique, resources, unlock state, execution skill, and version of the game. It also encourages precise thresholds to survive long after their evidence expires. This planner uses goal paths because a goal remains understandable even when one activity moves or one reward changes. The first-route path focuses on learning the current objective loop. Specialized paths focus on investigating Ten Shadows, Shrine, Limitless, the Rika and Copy quest, or a resource farm without pretending those routes are interchangeable.

Every task follows the same editorial pattern: establish context, identify the current decision, open a verified indexable guide, and return to the live client for the patch-sensitive detail. A task may ask you to distinguish two item names, classify a blocker, or review an official update before acting. Those are durable operations. The planner does not state a required level, a guaranteed drop, a probability, a material amount, or a fixed number of clears because the source set does not support a complete current table for those values.

Order still matters, but the order is logical rather than numerical. Context comes before commitment. Exact names come before inventory or route assumptions. A visible access prompt comes before a grind. A controlled test comes before a broad build change. The final checkpoint records what remains unresolved so the next session begins with a question instead of a vague instruction to do more farming. This structure is designed to survive corrections: if a page changes, the player can repeat the relevant check without discarding every part of the route.

Verified is a scope label, not a promise that every sentence will remain current forever. It means the page's published claims were supported to the site's standard on the displayed review date and that uncertainty was kept visible. Some verified field files combine official update text with dated playable footage or community observations. In those cases, the page should tell you which layer supports each conclusion. A named feature in an official description can be verified even when its complete unlock method remains unknown.

The page review date helps you decide how much live checking a claim needs. Compare it with the update context shown on the official game listing and with the interface in your server. A later patch does not automatically erase every older observation, but it does make affected access rules, balance advice, rewards, and interface paths candidates for re-verification. Preserve the old result as a dated baseline, capture the new wording, and describe the difference. That is stronger evidence than silently replacing one confident claim with another.

Unknown should remain a valid outcome. If the current interface does not disclose a drop rate, do not derive one from a short personal sample. If an activity refuses entry without a clear message, record the full response rather than naming a hidden requirement. If a reward preview and the received result appear inconsistent, keep both observations and stop before spending more scarce-looking resources to reproduce the problem. The planner helps organize these checks; it cannot see your account, server, inventory, or live menus, so it cannot resolve uncertainty that only the current client exposes.

• Verified describes supported published scope, not permanent game behavior.
• A review date tells you when the evidence was last checked, not when every mechanic was created.
• Official naming does not automatically prove acquisition, quantity, odds, or combat effect.
• One observed result can establish possibility under disclosed conditions, but not a universal rate.
• A live mismatch is evidence to record, not a reason to force the older guide.

Turn the selected path into a session plan by choosing the first unchecked task that addresses your current question. Before entering the game, write down the page date, the exact thing you expect to inspect, and the observation that would count as a useful result. A useful result may be a readable objective, the exact name of a locked entry, confirmation that an older interface no longer appears, or a repeatable combat problem. It does not have to be a successful unlock or drop.

Keep the session narrow enough that you can tell why the result changed. If you are evaluating a technique, preserve the surrounding build and use a familiar activity where practical. If you are checking an acquisition route, capture the activity or prompt before and after the relevant action. If the question concerns an item, use the exact displayed name and inspect the inventory change rather than relying on memory. Changing several build layers, activities, and resources together may feel productive, but it leaves no clear explanation for the outcome.

End the session at a return checkpoint. Mark the planner task complete if its decision was resolved, or leave it open and write the specific missing evidence in your copied plan. Note any changed wording, the patch context, and the safest next check. This turns an interruption into a clean handoff to your future self. It also makes community discussion more useful because another player can compare the same prompt or route instead of debating two undocumented recollections.

Start with

One current question

Authority

Live client prompts

Change

One variable at a time

Finish with

A return checkpoint

When progress stops, classify the blocker before choosing a solution. An access blocker is a visible gate, locked interaction, or unfinished prerequisite. A build blocker appears when access works but the current setup cannot perform the needed role consistently. An execution blocker means the plan is possible but timing, positioning, recognition, or recovery is failing. An information blocker exists when you cannot identify the current objective, requirement, item, or interface path well enough to test it. These categories can overlap, but naming the strongest one prevents a random response.

Use the smallest safe test that separates the possibilities. Read the complete prompt for access. Repeat a familiar attempt without changing the build to inspect execution. Compare one reversible build variable when the setup itself seems responsible. Check the current objective, official listing, and relevant verified field file when the route is unclear. A test that would consume limited-looking resources should have a written reason and a visible confirmation screen before you continue. The absence of an answer is not permission to substitute a rumor.

Choose the next planner task from the diagnosis. An information blocker may send you back to the dated update or exact-name guide. An access blocker may require a live prerequisite that the guide explicitly leaves open. A build or execution blocker may call for a controlled technique test rather than a different farming path. If no verified page addresses what you see, preserve a screenshot or transcript with the update context and stop the checklist there. A responsible route includes a boundary where current evidence runs out.

• Access: the current client shows a gate, lock, or missing prerequisite.
• Build: the setup does not reliably perform the job required by the activity.
• Execution: the intended response fails through timing, positioning, recognition, or recovery.
• Information: the objective, requirement, item name, or route is not clear enough to test.

The planner stores the selected goal and checked tasks in localStorage after the component loads in your browser. The saved record is versioned and validated before use. Unknown goals and task identifiers are ignored, so stale or malformed data cannot silently add checklist completion. Storage access can still fail because of browser privacy settings, restricted contexts, quota policies, or cleared site data. When it fails, the controls remain usable for the current page visit and the status indicator reports that persistence is unavailable.

Copy current plan creates plain text rather than a hidden account or cloud record. The export includes your selected goal, completion percentage, each task's reason, its internal guide route, evidence status, and review date. Paste it into your own notes when you want an explicit backup, a cross-device handoff, or a starting point for a group discussion. The export intentionally contains no inferred account state and no claim that a checked task proves a universal mechanic.

Reset this goal removes completion only from the route currently visible in the selector. Other goals remain untouched. Use reset when a major update changes the questions enough that you want to repeat the verification path, not merely because one live result was inconvenient. For a patch review, copying the old plan before resetting gives you a dated comparison record. After reset, begin with the earliest task whose evidence or decision may have changed and preserve still-valid observations instead of assuming the entire game route was replaced.

This tool is anchored to four source roles. The official Roblox game page identifies the experience and provides developer-controlled public context. The official Roblox game API supplies structured universe data and dated update descriptions. The current balance listing establishes the latest reviewed patch scope. A community new-player discussion contributes practical questions and route concerns, but it is treated as community evidence rather than developer documentation. Source type and confidence affect what a page is allowed to claim.

The planner links only to existing indexable pages whose page record is verified. It excludes draft pages marked as needing live capture even when their topics would make a route look more complete. That constraint matters: an attractive checklist can amplify a weak claim by repeating it as an instruction. Route completeness is less important than claim integrity. When an evidence-limited page later meets its publication gate, it can be considered for a future planner review with its own date and purpose.

Official sources receive priority for identity, update names, and developer-published scope. They still do not answer every progression question. Community material may locate a question, demonstrate a playable path, or provide a lead for reproduction, but it does not become an official rate, guarantee, or permanent requirement. Editorial guidance explains how to test and decide; it must remain visibly separate from literal interface text and observed results. Precise claims require precise evidence with enough context for another reviewer to understand what was tested.

Maintenance begins whenever the official listing changes or a linked page no longer matches the live client. Reviewers should compare the route registry, page status, review date, and task wording. Remove or revise a task if its guide becomes non-indexable, its evidence status is downgraded, or its reason no longer reflects the page. Do not preserve a route merely to keep the checklist the same length. A trustworthy planner changes openly, retains uncertainty, and sends players back to current visible evidence at every consequential decision.