LocalStorage Schema

Relevant source files

The following files were used as context for generating this wiki page:

• index.html
• Quest.html
• README.md
• Task Database Structure (via index.html)
• System Data initialization (via Quest.html)

Introduction

The Solo-System project utilizes a centralized LocalStorage schema to maintain user progress, task states, and penalty history. This client-side storage strategy ensures that a user's Level (LVL), Rank, and Experience Points (XP) persist across browser sessions without the need for a backend database.

The schema is encapsulated within a single key, solo_penalty_v1, which stores a serialized JSON object. This object acts as the primary state container for the application, driving the logic for daily task generation, level calculations, and the application of failure penalties.
Sources: index.html:105-107, Quest.html:105-107

Core Data Structure

The application state is managed through the systemData object. This object is initialized by parsing the solo_penalty_v1 LocalStorage key or providing a default state if the key is absent.

systemData Object Schema

Field	Type	Description
points	Number	The total XP/points accumulated by the user. Used for Rank and Level calculation.
lastUpdate	String	A date string (format: YYYY-MM-DD) representing the last time the daily cycle was checked.
dailyTasks	Array	A collection of Task objects generated for the current day.
lastPenalty	Number	The amount of points deducted during the last daily cycle transition due to incomplete tasks.

Sources: index.html:105-107, Quest.html:105-107

Task Object Schema

Each entry within the dailyTasks array follows this structure:

Field	Type	Description
n	String	The name/description of the task (e.g., "ضغط 10 عدات").
c	String	The category of the task: 'جسدي' (Physical), 'انضباط' (Discipline), or 'عقلي' (Mental).
d	Boolean	Completion status: true if completed, false otherwise.

Sources: index.html:142-144, Quest.html:142-144

Data Persistence Flow

The system follows a reactive persistence pattern where the LocalStorage is updated whenever a user interacts with a task or when a new daily cycle is initiated.

The diagram shows the lifecycle of the LocalStorage data from initial load to state updates via user interaction or daily transitions.
Sources: index.html:147-178, Quest.html:147-178

Logic and Calculations

The values stored in the LocalStorage schema are processed through several key functions to determine the UI state.

Rank and Level Determination

The system does not store "Rank" or "Level" directly; instead, it derives them dynamically from the points field.

• getRankConfig(pts): Determines the Rank (F through R) and associated rewards/penalties based on point thresholds.
• calculateLevel(pts): Iteratively calculates the user's level and progress percentage toward the next level based on variable requirements defined in the rank configuration.

This diagram illustrates how the single points value in LocalStorage is used to derive multiple UI components.
Sources: index.html:109-130, Quest.html:109-130

Daily Cycle and Penalty Logic

The lastUpdate field is critical for the "Penalty System." When the system detects a date change (using Asia/Riyadh timezone), it iterates through the dailyTasks stored in LocalStorage. For every task where d (done) is false, it subtracts the pen (penalty) value associated with the user's current rank.
Sources: index.html:147-167, Quest.html:147-167

Implementation Details

The persistence is handled by a simple wrapper function that serializes the state.

// index.html:184-184
function save() { 
    localStorage.setItem('solo_penalty_v1', JSON.stringify(systemData)); 
}

The initial load utilizes the logical OR operator to handle first-time users:

// Quest.html:105-107
let systemData = JSON.parse(localStorage.getItem('solo_penalty_v1')) || {
    points: 0, lastUpdate: '', dailyTasks: [], lastPenalty: 0
};

Summary

The LocalStorage schema for the Solo-System is designed for lightweight, offline-first progress tracking. By storing the raw points, task states, and a timestamp, the system effectively manages complex mechanics like rank-based difficulty scaling and daily penalties without requiring a server-side state.