erdos-problems 0.1.4 → 0.1.6

package/README.md

@@ -18,8 +18,9 @@ Official binary:
 
 - atlas layer with canonical local `problems/<id>/problem.yaml` records
 - bundled upstream snapshot from `teorth/erdosproblems`
-- workspace `.erdos/` state for active-problem selection, upstream refreshes, reports, scaffolds, and pull bundles
+- workspace `.erdos/` state for active-problem selection, upstream refreshes, scaffolds, and pull bundles
 - sunflower cluster as the first deep harness pack
+- quartet-aware sunflower context for `20`, `536`, `856`, and `857`
 - packaged compute-lane metadata for deep sunflower problems, surfaced directly in the CLI
 - seeded atlas now includes open and solved problems beyond sunflower
 - unseeded problems can still be pulled into a workspace from the bundled upstream snapshot
@@ -33,6 +34,7 @@ Seeded problems:
 erdos problem list --cluster sunflower
 erdos bootstrap problem 857
 erdos problem artifacts 857 --json
+erdos sunflower status 857
 erdos dossier show 857
 ```
 
@@ -40,23 +42,77 @@ What `bootstrap` does:
 - sets the active workspace problem
 - scaffolds the canonical dossier files into `.erdos/scaffolds/<id>/`
 - includes the upstream record when a bundled or workspace snapshot is available
+- copies pack-specific context and compute packets when the problem has them
 - gives an agent a ready-to-read local artifact bundle immediately after install
 
-## Pull bundles
+## Pull lanes
 
 For any problem number in the upstream snapshot, you can create a workspace bundle even if the problem is not yet seeded locally:
 
 ```bash
 erdos pull problem 857
+erdos pull artifacts 857
+erdos pull literature 857
 erdos pull problem 999 --include-site
 erdos pull problem 999 --refresh-upstream
 ```
 
-What `pull` does:
-- creates `.erdos/pulls/<id>/`
-- includes the upstream record when available
-- includes the local canonical dossier too when the problem is seeded locally
-- can optionally add a live site snapshot and plain-text extract
+What the pull lanes do:
+- `erdos pull problem <id>` creates `.erdos/pulls/<id>/` with:
+  - a root pull manifest
+  - `artifacts/`
+  - `literature/`
+- `erdos pull artifacts <id>` creates only the artifact lane
+- `erdos pull literature <id>` creates only the literature lane
+- when a problem is locally seeded, the artifact lane includes the canonical dossier, pack context, and compute packets
+- when `--include-site` is used, the literature lane can include a live site snapshot and plain-text extract
+
+## Maintainer seeding
+
+To turn a pulled bundle into a new canonical dossier in the repo:
+
+```bash
+erdos maintainer seed problem 1 \
+  --from-pull .erdos/pulls/1 \
+  --cluster number-theory \
+  --family-tag additive-combinatorics
+```
+
+What maintainer seeding does:
+- reads the pull bundle provenance
+- generates a canonical `problems/<id>/` dossier
+- writes:
+  - `problem.yaml`
+  - `STATEMENT.md`
+  - `REFERENCES.md`
+  - `EVIDENCE.md`
+  - `FORMALIZATION.md`
+- preserves upstream/site provenance in the local record
+
+## Sunflower pack
+
+The first deep pack is the sunflower quartet:
+- `20`: strong / uniform sunflower core
+- `857`: weak / non-uniform sunflower core
+- `536`: natural-density LCM analogue
+- `856`: harmonic-density LCM analogue
+
+Useful sunflower commands:
+
+```bash
+erdos cluster show sunflower
+erdos sunflower status 20
+erdos sunflower status 536
+erdos sunflower status 857 --json
+```
+
+`erdos sunflower status` surfaces:
+- family role
+- harness profile
+- active route
+- route breakthrough state
+- problem-solved distinction
+- compute posture when a packet exists
 
 ## CLI
 
@@ -83,10 +139,12 @@ erdos scaffold problem 857
 erdos bootstrap problem 857
 erdos bootstrap problem 857 --sync-upstream
 erdos pull problem 857
-erdos pull problem 857 --include-site
+erdos pull artifacts 857
+erdos pull literature 857
+erdos maintainer seed problem 1 --from-pull .erdos/pulls/1 --cluster number-theory
 ```
 
-## Canonical Sources
+## Canonical sources
 
 - local atlas truth: `problems/<id>/problem.yaml`
 - bundled upstream snapshot: `data/upstream/erdosproblems/`
@@ -109,11 +167,12 @@ The CLI can surface these directly:
 - `erdos scaffold problem <id>` copies the seeded dossier into the active workspace
 - `erdos bootstrap problem <id>` selects the problem and creates the scaffold in one step
 - `erdos pull problem <id>` creates a workspace bundle for any problem in the upstream snapshot
+- `erdos maintainer seed problem <id>` promotes a pull bundle into a canonical local dossier
 
-For deep sunflower problems, the CLI also surfaces packaged compute lanes:
-- `erdos sunflower status <id>` shows route + compute posture together
-- `erdos workspace show` includes the active sunflower compute summary when applicable
-- `erdos scaffold problem <id>` copies packaged compute packets into `.erdos/scaffolds/<id>/COMPUTE/`
+For sunflower problems, the CLI also surfaces pack-specific artifacts:
+- pack README context
+- per-problem context files under `packs/sunflower/problems/<id>/`
+- compute packets under `packs/sunflower/compute/<id>/` when available
 
 ## Notes
 
@@ -125,3 +184,34 @@ For deep sunflower problems, the CLI also surfaces packaged compute lanes:
 - `docs/ERDOS_PROBLEMS_REPO_SPEC.md`
 - `docs/ERDOS_PROBLEMS_PROBLEM_SCHEMA.md`
 - `docs/ERDOS_SUNFLOWER_CLUSTER_SEED_PLAN.md`
+
+## Research loop
+
+`erdos-problems` now carries the staged loop we defined in the sunflower lab and the `.gpd`-style harness work:
+
+```bash
+erdos problem use 857
+erdos state sync
+erdos preflight
+erdos continuation use route
+erdos checkpoints sync
+erdos workspace show
+```
+
+This runtime writes:
+- `.erdos/config.json`
+- `.erdos/state.json`
+- `.erdos/STATE.md`
+- `.erdos/QUESTION-LEDGER.md`
+- `.erdos/checkpoints/CHECKPOINTS.md`
+- `.erdos/checkpoints/CHECKPOINTS.json`
+- `.erdos/registry/preflight/`
+
+The public package uses the same status ladder we settled on in the lab:
+- open problem
+- active route
+- route breakthrough
+- problem solved
+
+See also:
+- `docs/RESEARCH_LOOP.md`

package/docs/ERDOS_PROBLEMS_PROBLEM_SCHEMA.md

@@ -4,20 +4,17 @@ Last updated: 2026-03-25
 
 ## Purpose
 
-This schema defines the minimum metadata for each problem entry in `erdos-problems`.
+This schema defines the canonical local dossier record for each seeded problem in `erdos-problems`.
 
-The goal is:
+Goals:
+- every Erdős problem has a consistent local home
+- local dossier truth stays separate from upstream public truth
+- agents can bootstrap from canonical artifacts immediately after install
+- pulled upstream/site bundles can be promoted into canonical dossiers without losing provenance
 
-- every Erdős problem has a consistent home
-- open and solved problems use the same shape
-- local dossier truth and upstream public truth stay explicitly separated
-- packaged CLI installs can scaffold problem workspaces from canonical artifacts immediately
-- unseeded problems can still be pulled into a workspace bundle from upstream truth
-
-## Canonical Files
+## Canonical files
 
 Each seeded problem should have:
-
 - `problems/<id>/problem.yaml`
 - `problems/<id>/STATEMENT.md`
 - `problems/<id>/REFERENCES.md`
@@ -25,44 +22,42 @@ Each seeded problem should have:
 - `problems/<id>/FORMALIZATION.md`
 
 Bundled upstream snapshot artifacts live in:
-
 - `data/upstream/erdosproblems/problems.yaml`
 - `data/upstream/erdosproblems/PROBLEMS_INDEX.json`
 - `data/upstream/erdosproblems/SYNC_MANIFEST.json`
 
-Workspace-generated artifacts may live in:
+Pack-specific context may live in:
+- `packs/<pack>/README.md`
+- `packs/<pack>/problems/<id>/context.yaml`
+- `packs/<pack>/problems/<id>/CONTEXT.md`
+- `packs/<pack>/compute/<id>/*.yaml`
 
+Workspace-generated artifacts may live in:
 - `.erdos/scaffolds/<id>/`
-- `.erdos/pulls/<id>/`
+- `.erdos/pulls/<id>/artifacts/`
+- `.erdos/pulls/<id>/literature/`
 - `.erdos/upstream/erdosproblems/`
 
-## Canonical Truth Split
-
-### External public truth
-
-Tracked, not rewritten by us:
+## Canonical truth split
 
+External public truth:
+- tracked, not rewritten
 - upstream structured repo: `teorth/erdosproblems`
-- upstream data file: `data/problems.yaml`
 - public presentation site: `erdosproblems.com`
 
-### Local atlas truth
-
-Authored by this repo:
-
+Local atlas truth:
 - `problems/<id>/problem.yaml`
-- local dossier markdown files alongside it
-
-### Local research truth
-
-For active harnessed problems:
+- dossier markdown files beside it
 
+Local harness truth:
 - route state
-- evidence
-- formalization status
-- checkpoints and generated reports
+- evidence notes
+- formalization state
+- pack context
+- compute packets
+- workspace pull/scaffold artifacts
 
-## Example Canonical Problem YAML
+## Example canonical problem YAML
 
 ```yaml
 problem_id: "857"
@@ -111,7 +106,20 @@ research_state:
   problem_solved: false
 ```
 
-## Required Fields
+## Optional provenance block
+
+Maintainer-seeded dossiers may also include:
+
+```yaml
+provenance:
+  seeded_at: "2026-03-25T..."
+  seeded_from:
+    kind: "pull_bundle"
+    upstream_record_included: true
+    site_snapshot_included: false
+```
+
+## Required fields
 
 - `problem_id`
 - `display_name`
@@ -129,12 +137,11 @@ research_state:
 - `formalization_path`
 - `formalization.status`
 
-## Status Vocabulary
+## Status vocabulary
 
 ### `status.site_status`
 
 Allowed values:
-
 - `open`
 - `solved`
 - `partial`
@@ -143,7 +150,6 @@ Allowed values:
 ### `status.repo_status`
 
 Allowed values:
-
 - `cataloged`
 - `active`
 - `archived`
@@ -153,47 +159,46 @@ Allowed values:
 ### `harness.depth`
 
 Allowed values:
-
 - `deep`
 - `dossier`
 
 ### `formalization.status`
 
 Repo-local examples:
-
 - `active`
 - `planned`
 - `statement-formalized`
 - `site-proved-lean`
 - `unstarted`
 
-## Upstream Sync Artifacts
-
-The sync commands should produce:
-
-- raw upstream YAML snapshot
-- normalized JSON index keyed by problem number
-- sync manifest with commit SHA, timestamp, and hash
-- markdown diff report comparing locally seeded problems to upstream state
-
-## Scaffold Contract
+## Scaffold contract
 
 `erdos scaffold problem <id>` should create a workspace-ready bundle containing:
-
-- copied canonical local dossier files
-- canonical local `problem.yaml`
-- upstream record snapshot for that problem when available
+- copied canonical dossier files
+- `problem.yaml`
+- upstream record snapshot when available
+- pack README context when available
+- per-problem pack context when available
+- compute packets when available
 - generated artifact index for agent consumption
 
-This is the seeded-problem path.
-
-## Pull Contract
+## Pull contract
 
 `erdos pull problem <id>` should create a broader workspace-ready bundle containing:
-
-- upstream record snapshot for that problem when available
-- generated artifact index for agent consumption
-- seeded local dossier files too when the problem already exists in `problems/<id>/`
+- a root pull manifest
+- an `artifacts/` lane
+- a `literature/` lane
+- upstream record snapshot when available
+- local dossier artifacts when the problem is already seeded locally
 - optional live site snapshot and extracted text when `--include-site` is used
 
-This makes a fresh npm-installed CLI immediately useful to an agentic workflow even for problems that are not yet fully seeded as local dossiers.
+## Maintainer seed contract
+
+`erdos maintainer seed problem <id>` should be able to consume a pull bundle and generate:
+- `problem.yaml`
+- `STATEMENT.md`
+- `REFERENCES.md`
+- `EVIDENCE.md`
+- `FORMALIZATION.md`
+
+The resulting dossier should preserve upstream/site provenance and be safe for later manual curation.