# MazeXChain Project Scope

## 1. Project Definition

MazeXChain is a cognitive advancement protocol and Proof-of-Understanding chain project.

The protocol advances through Layer and Step challenges. Each Step exposes observable challenge behavior. A solver submits a bounded candidate model. The protocol verifies behavior equivalence, records the result as cognitive chain state, settles reward and fee rules, and derives the next Step commitment.

MazeXChain is not a generic web application, not a simple puzzle site, and not an EVM token wrapper. The active project direction is a native chain-style cognitive advancement protocol built around verifiable structural intelligence.

## 2. Active Protocol Line

The active protocol line is `Base1`.

```text
Base value
  -> operator units
  -> static parameters
  -> dynamic parameters
  -> deterministic behavior
  -> behavior commitment
  -> bounded candidate explanation
  -> verification
  -> Solve Block
  -> next Step commitment
```

Older formula-family prototypes, narrative-theme puzzles, direct formula-library allocation, and early demo commitment files are historical design material. They may be referenced for research, but they must not override the active Base1 protocol unless a migration document explicitly says so.

## 3. Non-Negotiable Engineering Rules

Any future change must follow these rules:

```text
1. Do not remove existing protocol modules without an explicit migration note.
2. Do not mix core chain logic into UI files.
3. Do not mix wallet private-key logic into server-side code.
4. Do not write private Step material, internal expressions, private seeds, or fragment selection paths into public API responses or logs.
5. Do not advance Layer or Step without passing the verifier and state transition path.
6. Do not bypass latest-head preflight before solve submission.
7. Do not let invalid local answers broadcast or enter chain state.
8. Do not add unbounded candidate answers, lookup tables, or unlimited expression payloads.
9. Do not treat browser test keys as production wallet infrastructure.
10. Do not upload local-only changes to the public server unless explicitly requested.
11. Every meaningful code change must be tested and committed to Git.
12. Every major feature change must update the relevant project document or status table.
```

## 4. Core State Transition

The canonical flow is:

```text
current chain head
  -> current Layer / Step
  -> challenge public commitments
  -> sampling / observation
  -> candidate explanation
  -> answer budget check
  -> deterministic behavior verification
  -> signed submission
  -> network confirmation path
  -> Solve Block
  -> reward and fee settlement
  -> next Step commitment
  -> new chain head
```

Any implementation that skips this path is a prototype and must be labeled as such.

## 5. Security Boundaries

Public data may include:

```text
Layer / Step
grid size
difficulty score
public commitments
behavior root
fragment registry root
answer hash
solve block data
reward settlement data
public wallet address
public key
signature
chain head
state root
block hash
```

Private data must not be exposed before reveal or protocol-defined publication:

```text
internal generated expressions
private seed material
fragment selection path
private vault content
wallet private key
mnemonic phrase
uncommitted future challenge material
server-only generator internals
```

## 6. Wallet Boundary

The native wallet uses Ed25519 signatures and MazeXChain addresses.

Wallet rules:

```text
Private keys and mnemonic phrases stay client-side.
The extension stores encrypted vaults.
The active wallet is decrypted only after local unlock.
Every site-requested signature must require explicit approval.
The server verifies signatures, but does not hold production key material.
```

The wallet extension is the production wallet direction. Website browser keys are development-only and must remain visually and technically separated from production wallet flows.

## 7. Chain Data Boundary

The chain state must remain replayable from blocks and snapshots.

Storage rules:

```text
Blocks, headers, state snapshots, samples, indexes, and downloads should stay logically separated.
Long-term storage must avoid rewriting one large state file for every block.
Any snapshot must be verifiable against block history and state roots.
Any node may choose full replay or snapshot-assisted replay.
```

## 8. Fragment and Behavior Commitment Boundary

Fragments are protocol inputs, not trusted secrets by themselves.

Fragment rules:

```text
Fragments must pass format, version, size, budget, executable, composable, and verification constraints.
Fragment registration, activation, quarantine, and versioning are protocol-governed.
Challenge behavior is committed through behavior roots and public commitments.
Solvers are judged by behavior equivalence, not by matching hidden internal construction text.
```

## 9. Network Boundary

P2P and relay systems are responsible for propagation, not for redefining validity.

Network rules:

```text
Nodes may relay head, block, candidate, witness, and safety messages.
Validity is determined by protocol verification and chain-state rules.
Peer reputation may reduce spam and prioritize propagation.
Network speed must not bypass verification.
```

## 10. Required Update Discipline

When a major feature changes, update:

```text
PROJECT_STATUS.md
PROJECT_CONTEXT.md if project direction, next work, or persistent handoff context changes
PROJECT_READING_RULES.md if required reading order or task routes change
README.md if user-facing behavior changes
related docs if protocol behavior changes
tests or smoke scripts if validation behavior changes
CHANGELOG.md once it exists
```

When a new conversation starts, the assistant must read `PROJECT_CONTEXT.md`, this file, `PROJECT_READING_RULES.md`, and `PROJECT_STATUS.md` before making project-level changes.
