erdos-problems 0.1.4 → 0.1.5

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -18,8 +18,9 @@ Official binary:
18
18
 
19
19
  - atlas layer with canonical local `problems/<id>/problem.yaml` records
20
20
  - bundled upstream snapshot from `teorth/erdosproblems`
21
- - workspace `.erdos/` state for active-problem selection, upstream refreshes, reports, scaffolds, and pull bundles
21
+ - workspace `.erdos/` state for active-problem selection, upstream refreshes, scaffolds, and pull bundles
22
22
  - sunflower cluster as the first deep harness pack
23
+ - quartet-aware sunflower context for `20`, `536`, `856`, and `857`
23
24
  - packaged compute-lane metadata for deep sunflower problems, surfaced directly in the CLI
24
25
  - seeded atlas now includes open and solved problems beyond sunflower
25
26
  - unseeded problems can still be pulled into a workspace from the bundled upstream snapshot
@@ -33,6 +34,7 @@ Seeded problems:
33
34
  erdos problem list --cluster sunflower
34
35
  erdos bootstrap problem 857
35
36
  erdos problem artifacts 857 --json
37
+ erdos sunflower status 857
36
38
  erdos dossier show 857
37
39
  ```
38
40
 
@@ -40,23 +42,77 @@ What `bootstrap` does:
40
42
  - sets the active workspace problem
41
43
  - scaffolds the canonical dossier files into `.erdos/scaffolds/<id>/`
42
44
  - includes the upstream record when a bundled or workspace snapshot is available
45
+ - copies pack-specific context and compute packets when the problem has them
43
46
  - gives an agent a ready-to-read local artifact bundle immediately after install
44
47
 
45
- ## Pull bundles
48
+ ## Pull lanes
46
49
 
47
50
  For any problem number in the upstream snapshot, you can create a workspace bundle even if the problem is not yet seeded locally:
48
51
 
49
52
  ```bash
50
53
  erdos pull problem 857
54
+ erdos pull artifacts 857
55
+ erdos pull literature 857
51
56
  erdos pull problem 999 --include-site
52
57
  erdos pull problem 999 --refresh-upstream
53
58
  ```
54
59
 
55
- What `pull` does:
56
- - creates `.erdos/pulls/<id>/`
57
- - includes the upstream record when available
58
- - includes the local canonical dossier too when the problem is seeded locally
59
- - can optionally add a live site snapshot and plain-text extract
60
+ What the pull lanes do:
61
+ - `erdos pull problem <id>` creates `.erdos/pulls/<id>/` with:
62
+ - a root pull manifest
63
+ - `artifacts/`
64
+ - `literature/`
65
+ - `erdos pull artifacts <id>` creates only the artifact lane
66
+ - `erdos pull literature <id>` creates only the literature lane
67
+ - when a problem is locally seeded, the artifact lane includes the canonical dossier, pack context, and compute packets
68
+ - when `--include-site` is used, the literature lane can include a live site snapshot and plain-text extract
69
+
70
+ ## Maintainer seeding
71
+
72
+ To turn a pulled bundle into a new canonical dossier in the repo:
73
+
74
+ ```bash
75
+ erdos maintainer seed problem 1 \
76
+ --from-pull .erdos/pulls/1 \
77
+ --cluster number-theory \
78
+ --family-tag additive-combinatorics
79
+ ```
80
+
81
+ What maintainer seeding does:
82
+ - reads the pull bundle provenance
83
+ - generates a canonical `problems/<id>/` dossier
84
+ - writes:
85
+ - `problem.yaml`
86
+ - `STATEMENT.md`
87
+ - `REFERENCES.md`
88
+ - `EVIDENCE.md`
89
+ - `FORMALIZATION.md`
90
+ - preserves upstream/site provenance in the local record
91
+
92
+ ## Sunflower pack
93
+
94
+ The first deep pack is the sunflower quartet:
95
+ - `20`: strong / uniform sunflower core
96
+ - `857`: weak / non-uniform sunflower core
97
+ - `536`: natural-density LCM analogue
98
+ - `856`: harmonic-density LCM analogue
99
+
100
+ Useful sunflower commands:
101
+
102
+ ```bash
103
+ erdos cluster show sunflower
104
+ erdos sunflower status 20
105
+ erdos sunflower status 536
106
+ erdos sunflower status 857 --json
107
+ ```
108
+
109
+ `erdos sunflower status` surfaces:
110
+ - family role
111
+ - harness profile
112
+ - active route
113
+ - route breakthrough state
114
+ - problem-solved distinction
115
+ - compute posture when a packet exists
60
116
 
61
117
  ## CLI
62
118
 
@@ -83,10 +139,12 @@ erdos scaffold problem 857
83
139
  erdos bootstrap problem 857
84
140
  erdos bootstrap problem 857 --sync-upstream
85
141
  erdos pull problem 857
86
- erdos pull problem 857 --include-site
142
+ erdos pull artifacts 857
143
+ erdos pull literature 857
144
+ erdos maintainer seed problem 1 --from-pull .erdos/pulls/1 --cluster number-theory
87
145
  ```
88
146
 
89
- ## Canonical Sources
147
+ ## Canonical sources
90
148
 
91
149
  - local atlas truth: `problems/<id>/problem.yaml`
92
150
  - bundled upstream snapshot: `data/upstream/erdosproblems/`
@@ -109,11 +167,12 @@ The CLI can surface these directly:
109
167
  - `erdos scaffold problem <id>` copies the seeded dossier into the active workspace
110
168
  - `erdos bootstrap problem <id>` selects the problem and creates the scaffold in one step
111
169
  - `erdos pull problem <id>` creates a workspace bundle for any problem in the upstream snapshot
170
+ - `erdos maintainer seed problem <id>` promotes a pull bundle into a canonical local dossier
112
171
 
113
- For deep sunflower problems, the CLI also surfaces packaged compute lanes:
114
- - `erdos sunflower status <id>` shows route + compute posture together
115
- - `erdos workspace show` includes the active sunflower compute summary when applicable
116
- - `erdos scaffold problem <id>` copies packaged compute packets into `.erdos/scaffolds/<id>/COMPUTE/`
172
+ For sunflower problems, the CLI also surfaces pack-specific artifacts:
173
+ - pack README context
174
+ - per-problem context files under `packs/sunflower/problems/<id>/`
175
+ - compute packets under `packs/sunflower/compute/<id>/` when available
117
176
 
118
177
  ## Notes
119
178
 
@@ -4,20 +4,17 @@ Last updated: 2026-03-25
4
4
 
5
5
  ## Purpose
6
6
 
7
- This schema defines the minimum metadata for each problem entry in `erdos-problems`.
7
+ This schema defines the canonical local dossier record for each seeded problem in `erdos-problems`.
8
8
 
9
- The goal is:
9
+ Goals:
10
+ - every Erdős problem has a consistent local home
11
+ - local dossier truth stays separate from upstream public truth
12
+ - agents can bootstrap from canonical artifacts immediately after install
13
+ - pulled upstream/site bundles can be promoted into canonical dossiers without losing provenance
10
14
 
11
- - every Erdős problem has a consistent home
12
- - open and solved problems use the same shape
13
- - local dossier truth and upstream public truth stay explicitly separated
14
- - packaged CLI installs can scaffold problem workspaces from canonical artifacts immediately
15
- - unseeded problems can still be pulled into a workspace bundle from upstream truth
16
-
17
- ## Canonical Files
15
+ ## Canonical files
18
16
 
19
17
  Each seeded problem should have:
20
-
21
18
  - `problems/<id>/problem.yaml`
22
19
  - `problems/<id>/STATEMENT.md`
23
20
  - `problems/<id>/REFERENCES.md`
@@ -25,44 +22,42 @@ Each seeded problem should have:
25
22
  - `problems/<id>/FORMALIZATION.md`
26
23
 
27
24
  Bundled upstream snapshot artifacts live in:
28
-
29
25
  - `data/upstream/erdosproblems/problems.yaml`
30
26
  - `data/upstream/erdosproblems/PROBLEMS_INDEX.json`
31
27
  - `data/upstream/erdosproblems/SYNC_MANIFEST.json`
32
28
 
33
- Workspace-generated artifacts may live in:
29
+ Pack-specific context may live in:
30
+ - `packs/<pack>/README.md`
31
+ - `packs/<pack>/problems/<id>/context.yaml`
32
+ - `packs/<pack>/problems/<id>/CONTEXT.md`
33
+ - `packs/<pack>/compute/<id>/*.yaml`
34
34
 
35
+ Workspace-generated artifacts may live in:
35
36
  - `.erdos/scaffolds/<id>/`
36
- - `.erdos/pulls/<id>/`
37
+ - `.erdos/pulls/<id>/artifacts/`
38
+ - `.erdos/pulls/<id>/literature/`
37
39
  - `.erdos/upstream/erdosproblems/`
38
40
 
39
- ## Canonical Truth Split
40
-
41
- ### External public truth
42
-
43
- Tracked, not rewritten by us:
41
+ ## Canonical truth split
44
42
 
43
+ External public truth:
44
+ - tracked, not rewritten
45
45
  - upstream structured repo: `teorth/erdosproblems`
46
- - upstream data file: `data/problems.yaml`
47
46
  - public presentation site: `erdosproblems.com`
48
47
 
49
- ### Local atlas truth
50
-
51
- Authored by this repo:
52
-
48
+ Local atlas truth:
53
49
  - `problems/<id>/problem.yaml`
54
- - local dossier markdown files alongside it
55
-
56
- ### Local research truth
57
-
58
- For active harnessed problems:
50
+ - dossier markdown files beside it
59
51
 
52
+ Local harness truth:
60
53
  - route state
61
- - evidence
62
- - formalization status
63
- - checkpoints and generated reports
54
+ - evidence notes
55
+ - formalization state
56
+ - pack context
57
+ - compute packets
58
+ - workspace pull/scaffold artifacts
64
59
 
65
- ## Example Canonical Problem YAML
60
+ ## Example canonical problem YAML
66
61
 
67
62
  ```yaml
68
63
  problem_id: "857"
@@ -111,7 +106,20 @@ research_state:
111
106
  problem_solved: false
112
107
  ```
113
108
 
114
- ## Required Fields
109
+ ## Optional provenance block
110
+
111
+ Maintainer-seeded dossiers may also include:
112
+
113
+ ```yaml
114
+ provenance:
115
+ seeded_at: "2026-03-25T..."
116
+ seeded_from:
117
+ kind: "pull_bundle"
118
+ upstream_record_included: true
119
+ site_snapshot_included: false
120
+ ```
121
+
122
+ ## Required fields
115
123
 
116
124
  - `problem_id`
117
125
  - `display_name`
@@ -129,12 +137,11 @@ research_state:
129
137
  - `formalization_path`
130
138
  - `formalization.status`
131
139
 
132
- ## Status Vocabulary
140
+ ## Status vocabulary
133
141
 
134
142
  ### `status.site_status`
135
143
 
136
144
  Allowed values:
137
-
138
145
  - `open`
139
146
  - `solved`
140
147
  - `partial`
@@ -143,7 +150,6 @@ Allowed values:
143
150
  ### `status.repo_status`
144
151
 
145
152
  Allowed values:
146
-
147
153
  - `cataloged`
148
154
  - `active`
149
155
  - `archived`
@@ -153,47 +159,46 @@ Allowed values:
153
159
  ### `harness.depth`
154
160
 
155
161
  Allowed values:
156
-
157
162
  - `deep`
158
163
  - `dossier`
159
164
 
160
165
  ### `formalization.status`
161
166
 
162
167
  Repo-local examples:
163
-
164
168
  - `active`
165
169
  - `planned`
166
170
  - `statement-formalized`
167
171
  - `site-proved-lean`
168
172
  - `unstarted`
169
173
 
170
- ## Upstream Sync Artifacts
171
-
172
- The sync commands should produce:
173
-
174
- - raw upstream YAML snapshot
175
- - normalized JSON index keyed by problem number
176
- - sync manifest with commit SHA, timestamp, and hash
177
- - markdown diff report comparing locally seeded problems to upstream state
178
-
179
- ## Scaffold Contract
174
+ ## Scaffold contract
180
175
 
181
176
  `erdos scaffold problem <id>` should create a workspace-ready bundle containing:
182
-
183
- - copied canonical local dossier files
184
- - canonical local `problem.yaml`
185
- - upstream record snapshot for that problem when available
177
+ - copied canonical dossier files
178
+ - `problem.yaml`
179
+ - upstream record snapshot when available
180
+ - pack README context when available
181
+ - per-problem pack context when available
182
+ - compute packets when available
186
183
  - generated artifact index for agent consumption
187
184
 
188
- This is the seeded-problem path.
189
-
190
- ## Pull Contract
185
+ ## Pull contract
191
186
 
192
187
  `erdos pull problem <id>` should create a broader workspace-ready bundle containing:
193
-
194
- - upstream record snapshot for that problem when available
195
- - generated artifact index for agent consumption
196
- - seeded local dossier files too when the problem already exists in `problems/<id>/`
188
+ - a root pull manifest
189
+ - an `artifacts/` lane
190
+ - a `literature/` lane
191
+ - upstream record snapshot when available
192
+ - local dossier artifacts when the problem is already seeded locally
197
193
  - optional live site snapshot and extracted text when `--include-site` is used
198
194
 
199
- 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.
195
+ ## Maintainer seed contract
196
+
197
+ `erdos maintainer seed problem <id>` should be able to consume a pull bundle and generate:
198
+ - `problem.yaml`
199
+ - `STATEMENT.md`
200
+ - `REFERENCES.md`
201
+ - `EVIDENCE.md`
202
+ - `FORMALIZATION.md`
203
+
204
+ The resulting dossier should preserve upstream/site provenance and be safe for later manual curation.