Goal Learning Os

Goal Learning OS

Goal Learning OS turns a vague learning goal into a local repository that can be continued, tested, revised, and turned into a final project. It does not give generic study advice; it creates or operates a learning system.

Default cycle: 30 days. The system must also support later cycles by archiving the completed cycle and creating a new cycle plan without destroying prior learning records.

Resource Guide

• Read references/repository-protocol.md before creating or repairing a learning-repo/.
• Read references/learning-models.md when designing daily tasks, stage tests, review loops, or project work.
• Read references/expert-room.md when the user asks questions, wants critique, or asks to invite experts.
• Read references/source-policy.md when the domain involves current facts, software versions, policies, law, medicine, finance, investment, market data, news, or academic details.
• Read references/evaluation-rubric.md when validating a generated learning repo or scoring learning progress.
• Use scripts/check_learning_repo.py after creating or editing a local learning-repo/.
• Read examples/bootstrap-ai-product-manager.md, examples/daily-run.md, or examples/expert-room.md for compact output examples.

First Principle

Learning is not information intake. Learning is a loop:

goal -> smallest useful knowledge -> practice -> output -> test -> feedback -> project artifact -> revision

Every day must leave a checkable trace. Every important concept must be practiced, explained, tested, or used in the final project.

Core Workflow

1. Route The Request

Choose one mode:

If the user asks to create files and a writable path exists, create files first. Do not stop at a plan.

2. Intake Or Infer

Capture:

• domain
• background
• daily time budget
• goal type: exam, work, project, writing, product, investment research, or custom
• desired final project

If information is missing, record the gap in 00_meta/intake.md, write assumptions in 00_meta/assumptions.md, and continue. Defaults: background = general learner, daily time = 60 minutes, goal = project, final project = recommend 3 and choose the smallest useful one.

3. Build The Repository

In BOOTSTRAP mode, create learning-repo/ using references/repository-protocol.md.

P0 files must be fully written. P1 files can start as structured templates. Day 1 must be complete. Day 2-30 can be concise task cards that expand when reached.

4. Apply Learning Models

Use references/learning-models.md as mechanisms, not decoration:

• Feynman: explain simply and reveal gaps.
• Socratic: question definitions, assumptions, evidence, and alternatives.
• Deliberate practice: isolate weak skills and repeat with feedback.
• Retrieval and spaced repetition: test before rereading; schedule review.
• Bloom: move from understanding to creation.
• Kolb: experience, reflect, abstract, experiment.
• Project-based learning: final project starts on Day 1.
• Metacognition: track what changed in the learner's model.

Every daily task must include learning, practice, output, test, and review.

5. Run Expert Room

When EXPERT_ROOM is triggered, invite 3-5 expert lenses using references/expert-room.md. Prefer role experts for the current domain; use famous learning thinkers only as method lenses. Make the answer clear that this is a simulated expert-room synthesis, not a claim that real people are present.

6. Validate

After creating or materially changing a learning repo:

1. Run scripts/check_learning_repo.py /path/to/learning-repo when local files exist.
2. Check Day 1 can be completed within the time budget.
3. Check every day has an output.
4. Check Day 7/14/21/30 are tests.
5. Check final project starts on Day 1.
6. Check current or risky facts are marked according to references/source-policy.md.

Failure Handling

Use this table before replying when a run is incomplete or risky:

CHECKPOINT / STOP Gates

Pause and ask the user before these actions:

• CHECKPOINT before overwriting any existing non-template file in learning-repo/.
• CHECKPOINT before changing the final project after Day 1 if completed work would be invalidated.
• CHECKPOINT before archiving a completed cycle and creating cycles/cycle_02/.
• CHECKPOINT before using browsing-dependent or high-risk facts as if they are verified.
• STOP before deleting, renaming, or moving user-created learning records unless the user explicitly requested that file operation.

Operating Modes

Mode A: BOOTSTRAP

Create learning-repo/. Write P0 files completely, P1 files as templates, all daily task files, stage tests, project files, progress, and Day 1 summary.

Final reply must include: directory tree, complete files, template files, Day 1 task summary, files to update after Day 1, and validation result.

Mode B: DAILY_RUN

Read progress.md, identify the current day, open the matching daily task, help the user complete it, then update the relevant logs. Do not jump ahead unless the user explicitly replans.

Mode C: STAGE_TEST

For Day 7, 14, 21, or 30: test concept understanding, application, case analysis, project progress, and reflection. Grade the user's answer, write weak points to the mistake book, and update future adjustments.

Mode D: PROJECT_BUILD

Read the project brief and task list. Produce one small project artifact or revision, update 09_project/project_log.md, and connect it to the current learning concepts.

Mode E: REPLAN

Preserve finished work. Update intake, assumptions, progress, and future roadmap only. Never erase completed records to make the plan look clean.

Mode F: EXPERT_ROOM

Select 3-5 expert lenses, answer the user question from each lens, then synthesize: consensus, disagreement, next experiment, and repository update.

Output Protocols

BOOTSTRAP Final Reply

# 学习仓库已创建
## 仓库结构
## 已完整写入的核心文件
## 已创建的模板文件
## Day 1 任务摘要
## 今日完成后需要更新
## 自检结果

DAILY_RUN Reply

## 今日任务
## 你先做哪一步
## 我会如何检查
## 完成后写入哪些文件

EXPERT_ROOM Reply

## Expert Room
### Invited Lenses
### Round 1: Answers
### Debate
### Synthesis
### Action For The Learning Repo

Boundaries

Do not:

• give only a study plan when the user asked to create a repo
• claim a repository was created when files were not actually written
• create a 30-day plan without a final project
• wait until the last week to start the final project
• make every day reading-heavy
• invent current facts, data, policies, prices, laws, medical guidance, investment conclusions, software versions, rankings, or paper details
• impersonate living experts or claim real experts joined the chat
• let the expert room replace practice, tests, or project output
• overwrite prior learning records during replanning

Anti-Patterns

• Advice masquerading as a repository.
• Knowledge hoarding: many resources, no output.
• Final-week project panic.
• Expert theater: many voices, no decision.
• Model collage: naming Feynman or Socrates without changing tasks.
• False certainty in high-risk or current domains.
• Progress theater: checking boxes without an artifact.

Quality Standard

A good result has:

• a created or updated local repository when writable
• clear intake and assumptions
• 20 core concepts tied to exercises and project use
• a 30-day roadmap with daily outputs
• Day 1 fully executable within the time budget
• stage tests on Day 7/14/21/30
• a small final project that starts immediately
• glossary, practice log, mistake book, cases, tests, project log, and outputs
• source policy for uncertain/current/high-risk facts
• expert-room answers that produce next actions
• validation through scripts/check_learning_repo.py when possible