# Next Work

last_reviewed: 2026-07-12

## P0: Build One Stateful Learning Path

Use Agent Memory as the first vertical slice, but do not reuse the failed 45-minute lecture format.

The unit of interaction should be a claim, not a paper. A minimal claim object needs:

```text
question
claim
supporting evidence
counterevidence
confidence
scope / failure boundary
prerequisites
related claims
user judgment
last reviewed / next review
```

The first path should contain a small number of consequential claims from the existing audit, for example:

- strong retrieval can dominate write complexity on static QA;
- current-value maintenance is distinct from retrieval;
- execution-state memory is different from historical recall;
- automatic experience promotion requires evidence and rollback;
- memory can have negative marginal value inside an Agent scaffold.

The interaction should progressively reveal:

```text
problem -> current hypothesis -> evidence -> conflicting evidence
-> user judgment -> application to a new design -> delayed recall
```

Persist the user's state. Merely rendering these sections is not enough.

### P0 Data Work

Define a versioned, inspectable local schema before adding a database. Suggested initial files:

```text
data/learning/claims.json
data/learning/user-model.json
data/learning/reviews.jsonl
```

Requirements:

- every claim links back to evidence-ledger entries;
- user notes and AI synthesis remain distinguishable;
- claim updates preserve history;
- confidence changes record a reason;
- review records are append-only;
- no generated summary can silently replace source evidence.

### P0 AI Roles

Use AI above the per-paper level:

- evidence auditor: check whether a claim is actually supported;
- contradiction finder: surface papers that challenge the current model;
- synthesis maintainer: update the claim network when evidence changes;
- research partner: help the user reason through an unfamiliar target;
- review generator: create recall/application prompts from validated claims.

Use Luna for cheap classification, Terra for retrieval briefs and bounded dialogue, and Sol only for explicit synthesis/critique. The user also has a company GPT-5.5 data-agent API with effectively unlimited tokens, but integration must wait until its endpoint, auth, rate behavior, and data policy are documented.

### P0 Validation

Do not judge success by page completion or time spent. Validate whether the user can:

1. explain five claims without paper names;
2. identify the evidence boundary of each claim;
3. diagnose a new Agent memory design;
4. predict when memory will hurt;
5. recover the model after 1, 3, and 7 days;
6. change a belief when presented with counterevidence.

## P1: Connect Research to the Frontend

The current Atlas/search/reader can remain, but it should feed the stateful path:

- selecting a topic opens its unresolved questions and claims, not only a paper list;
- selecting a paper shows which claims it supports or challenges;
- search results can be promoted into an evidence review queue;
- paper chat can create a candidate claim, never an automatically accepted fact;
- the primary desktop focus should shift to the active research/learning task;
- mobile should preserve the same conceptual flow with fewer simultaneous panes.

Avoid another navigation-heavy redesign before the data and learning loop exist.

## P1: Continue Collection Selectively

Current gaps:

- only 6 JD items, last checked 2026-07-08;
- only 9 industry items;
- 959 of 974 paper items are still queued;
- paper source approval and automated collection policy need an explicit user decision;
- the corpus is heavily biased toward May-July 2026 and broad arXiv query terms.

Next collection work should be question-driven:

- refresh Beijing DeepSeek/Tencent/ByteDance/Alibaba/Baidu roles and record changes;
- add official company material that explains memory, evaluation, coding agents, or computer use;
- deepen only papers that challenge or extend current claims;
- do not add another thousand papers without a processing and evidence plan.

After any item changes:

```bash
python3 tools/collection/build_index.py
python3 tools/check_project.py
```

## P2: Research Refresh Protocol

When refreshing the memory audit or starting another topic:

1. define exact date windows and approved sources;
2. save the broad candidate snapshot;
3. separate deterministic filters from model triage;
4. identify comparable benchmarks and controlled studies;
5. read experiments, ablations, costs, and limitations in full text;
6. update an evidence ledger before writing conclusions;
7. preserve negative results and failed hypotheses;
8. record the run under `experiments/` and update project status.

Do not compare raw scores across papers unless model, embedding, prompt, visible information, and budget are controlled.

## P2: Operations

Still missing:

- public-domain deployment documentation outside this repository;
- authentication/authorization for a public or multi-user site;
- automated backup for future personal learning state;
- CI that runs `tools/check_project.py` on push;
- tests for web API behavior and frontend flows.

The repository now has an enabled user-level systemd service managed through `web/manage.sh`. It restarts on failure and survives user sessions because linger is enabled on the current host, but it is not a complete production deployment: proxy/TLS/auth configuration remains external.

## Explicit Non-Goals

- Do not make the graph more decorative as the next milestone.
- Do not present 974 queued papers as knowledge already learned.
- Do not revive the 12-paper lecture as the primary path.
- Do not use per-paper summary/translation as the main AI value proposition.
- Do not let AI write durable memory solely because a statement repeats in traces.
- Do not hide model, embedding, context, or cost changes inside an architecture comparison.

## First Continuation Task

The best next task for another AI is:

1. read the memory findings and evidence ledger;
2. define the claim/user-state/review schemas;
3. compile 5-8 audited claims into a stateful local dataset;
4. implement one progressive learning/research view;
5. run it with the user and record what changes in their understanding;
6. keep or discard the interaction model based on that evidence.

That is the shortest path from the current corpus browser toward the actual goal.