Document and harden project handoff
This commit is contained in:
@@ -0,0 +1,167 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user