@xn-intenton-z2a/agentic-lib 7.1.88 → 7.1.90
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/.github/workflows/agentic-lib-init.yml +47 -0
- package/.github/workflows/agentic-lib-schedule.yml +25 -2
- package/.github/workflows/agentic-lib-workflow.yml +36 -0
- package/package.json +1 -1
- package/src/agents/agent-apply-fix.md +17 -5
- package/src/agents/agent-discussion-bot.md +1 -1
- package/src/agents/agent-issue-resolution.md +36 -4
- package/src/agents/agent-maintain-features.md +6 -1
- package/src/agents/agent-ready-issue.md +13 -1
- package/src/agents/agent-review-issue.md +14 -7
- package/src/seeds/missions/markdown-compiler.md +33 -0
- package/src/seeds/missions/ray-tracer.md +31 -0
- package/src/seeds/zero-package.json +1 -1
|
@@ -39,6 +39,10 @@ on:
|
|
|
39
39
|
type: string
|
|
40
40
|
required: false
|
|
41
41
|
default: ""
|
|
42
|
+
profile:
|
|
43
|
+
type: string
|
|
44
|
+
required: false
|
|
45
|
+
default: ""
|
|
42
46
|
workflow_dispatch:
|
|
43
47
|
inputs:
|
|
44
48
|
mode:
|
|
@@ -71,6 +75,9 @@ on:
|
|
|
71
75
|
- cron-engine
|
|
72
76
|
- owl-ontology
|
|
73
77
|
- time-series-lab
|
|
78
|
+
- c64-emulator
|
|
79
|
+
- ray-tracer
|
|
80
|
+
- markdown-compiler
|
|
74
81
|
- empty
|
|
75
82
|
mission-text:
|
|
76
83
|
description: "Freeform mission text for MISSION.md (overrides mission-seed if provided)"
|
|
@@ -99,6 +106,16 @@ on:
|
|
|
99
106
|
- gpt-5-mini
|
|
100
107
|
- claude-sonnet-4
|
|
101
108
|
- gpt-4.1
|
|
109
|
+
profile:
|
|
110
|
+
description: "Tuning profile (leave empty to keep current)"
|
|
111
|
+
type: choice
|
|
112
|
+
required: false
|
|
113
|
+
default: ""
|
|
114
|
+
options:
|
|
115
|
+
- ""
|
|
116
|
+
- min
|
|
117
|
+
- recommended
|
|
118
|
+
- max
|
|
102
119
|
|
|
103
120
|
permissions: write-all
|
|
104
121
|
|
|
@@ -122,6 +139,8 @@ jobs:
|
|
|
122
139
|
echo "schedule=${SCHEDULE}" >> $GITHUB_OUTPUT
|
|
123
140
|
MODEL='${{ inputs.model }}'
|
|
124
141
|
echo "model=${MODEL:-gpt-5-mini}" >> $GITHUB_OUTPUT
|
|
142
|
+
PROFILE='${{ inputs.profile }}'
|
|
143
|
+
echo "profile=${PROFILE}" >> $GITHUB_OUTPUT
|
|
125
144
|
outputs:
|
|
126
145
|
mode: ${{ steps.normalise.outputs.mode }}
|
|
127
146
|
dry-run: ${{ steps.normalise.outputs.dry-run }}
|
|
@@ -129,6 +148,7 @@ jobs:
|
|
|
129
148
|
mission-text: ${{ steps.normalise.outputs.mission-text }}
|
|
130
149
|
schedule: ${{ steps.normalise.outputs.schedule }}
|
|
131
150
|
model: ${{ steps.normalise.outputs.model }}
|
|
151
|
+
profile: ${{ steps.normalise.outputs.profile }}
|
|
132
152
|
|
|
133
153
|
init:
|
|
134
154
|
needs: params
|
|
@@ -200,6 +220,33 @@ jobs:
|
|
|
200
220
|
|
|
201
221
|
- run: npm test
|
|
202
222
|
|
|
223
|
+
- name: Update model and profile (if requested)
|
|
224
|
+
if: github.repository != 'xn-intenton-z2a/agentic-lib' && needs.params.outputs.dry-run != 'true' && (needs.params.outputs.model != '' || needs.params.outputs.profile != '')
|
|
225
|
+
uses: actions/github-script@v8
|
|
226
|
+
with:
|
|
227
|
+
script: |
|
|
228
|
+
const fs = require('fs');
|
|
229
|
+
const model = '${{ needs.params.outputs.model }}';
|
|
230
|
+
const profile = '${{ needs.params.outputs.profile }}';
|
|
231
|
+
const tomlPath = 'agentic-lib.toml';
|
|
232
|
+
if (!fs.existsSync(tomlPath)) return;
|
|
233
|
+
let toml = fs.readFileSync(tomlPath, 'utf8');
|
|
234
|
+
if (model) {
|
|
235
|
+
const modelRegex = /(\[tuning\][^\[]*?)(^\s*model\s*=\s*"[^"]*")/m;
|
|
236
|
+
if (modelRegex.test(toml)) {
|
|
237
|
+
toml = toml.replace(modelRegex, `$1model = "${model}"`);
|
|
238
|
+
core.info(`Updated [tuning].model to: ${model}`);
|
|
239
|
+
}
|
|
240
|
+
}
|
|
241
|
+
if (profile) {
|
|
242
|
+
const profileRegex = /(\[tuning\][^\[]*?)(^\s*profile\s*=\s*"[^"]*")/m;
|
|
243
|
+
if (profileRegex.test(toml)) {
|
|
244
|
+
toml = toml.replace(profileRegex, `$1profile = "${profile}"`);
|
|
245
|
+
core.info(`Updated [tuning].profile to: ${profile}`);
|
|
246
|
+
}
|
|
247
|
+
}
|
|
248
|
+
fs.writeFileSync(tomlPath, toml);
|
|
249
|
+
|
|
203
250
|
- name: Update schedule (if requested)
|
|
204
251
|
if: github.repository != 'xn-intenton-z2a/agentic-lib' && needs.params.outputs.schedule != '' && needs.params.outputs.dry-run != 'true'
|
|
205
252
|
uses: actions/github-script@v8
|
|
@@ -8,7 +8,7 @@
|
|
|
8
8
|
# No trigger changes needed — uses workflow_call and workflow_dispatch only.
|
|
9
9
|
|
|
10
10
|
name: agentic-lib-schedule
|
|
11
|
-
run-name: "agentic-lib-schedule -> ${{ inputs.frequency }} (${{ inputs.model }})"
|
|
11
|
+
run-name: "agentic-lib-schedule -> ${{ inputs.frequency }} (${{ inputs.model }}${{ inputs.profile && format(', profile={0}', inputs.profile) || '' }})"
|
|
12
12
|
|
|
13
13
|
on:
|
|
14
14
|
workflow_call:
|
|
@@ -22,6 +22,11 @@ on:
|
|
|
22
22
|
required: false
|
|
23
23
|
type: string
|
|
24
24
|
default: "gpt-5-mini"
|
|
25
|
+
profile:
|
|
26
|
+
description: "Tuning profile"
|
|
27
|
+
required: false
|
|
28
|
+
type: string
|
|
29
|
+
default: ""
|
|
25
30
|
dry-run:
|
|
26
31
|
description: "Skip commit and push"
|
|
27
32
|
required: false
|
|
@@ -48,6 +53,16 @@ on:
|
|
|
48
53
|
- gpt-5-mini
|
|
49
54
|
- claude-sonnet-4
|
|
50
55
|
- gpt-4.1
|
|
56
|
+
profile:
|
|
57
|
+
description: "Tuning profile"
|
|
58
|
+
required: false
|
|
59
|
+
type: choice
|
|
60
|
+
default: ""
|
|
61
|
+
options:
|
|
62
|
+
- ""
|
|
63
|
+
- min
|
|
64
|
+
- recommended
|
|
65
|
+
- max
|
|
51
66
|
dry-run:
|
|
52
67
|
description: "Skip commit and push"
|
|
53
68
|
type: boolean
|
|
@@ -76,6 +91,7 @@ jobs:
|
|
|
76
91
|
const fs = require('fs');
|
|
77
92
|
const frequency = '${{ inputs.frequency }}';
|
|
78
93
|
const model = '${{ inputs.model || 'gpt-5-mini' }}';
|
|
94
|
+
const profile = '${{ inputs.profile }}';
|
|
79
95
|
const workflowPath = '.github/workflows/agentic-lib-workflow.yml';
|
|
80
96
|
const tomlPath = 'agentic-lib.toml';
|
|
81
97
|
|
|
@@ -139,8 +155,15 @@ jobs:
|
|
|
139
155
|
toml = toml.replace(scheduleSupervisorRegex, `$1supervisor = "${frequency}"`);
|
|
140
156
|
}
|
|
141
157
|
|
|
158
|
+
if (profile) {
|
|
159
|
+
const profileRegex = /(\[tuning\][^\[]*?)(^\s*profile\s*=\s*"[^"]*")/m;
|
|
160
|
+
if (profileRegex.test(toml)) {
|
|
161
|
+
toml = toml.replace(profileRegex, `$1profile = "${profile}"`);
|
|
162
|
+
}
|
|
163
|
+
}
|
|
164
|
+
|
|
142
165
|
fs.writeFileSync(tomlPath, toml);
|
|
143
|
-
core.info(`Updated agentic-lib.toml: model=${model}, supervisor=${frequency}`);
|
|
166
|
+
core.info(`Updated agentic-lib.toml: model=${model}, supervisor=${frequency}${profile ? ', profile=' + profile : ''}`);
|
|
144
167
|
} else {
|
|
145
168
|
core.warning('agentic-lib.toml not found — skipping config update');
|
|
146
169
|
}
|
|
@@ -24,6 +24,10 @@ on:
|
|
|
24
24
|
type: string
|
|
25
25
|
required: false
|
|
26
26
|
default: "gpt-5-mini"
|
|
27
|
+
profile:
|
|
28
|
+
type: string
|
|
29
|
+
required: false
|
|
30
|
+
default: ""
|
|
27
31
|
mode:
|
|
28
32
|
type: string
|
|
29
33
|
required: false
|
|
@@ -47,6 +51,16 @@ on:
|
|
|
47
51
|
- gpt-5-mini
|
|
48
52
|
- claude-sonnet-4
|
|
49
53
|
- gpt-4.1
|
|
54
|
+
profile:
|
|
55
|
+
description: "Tuning profile"
|
|
56
|
+
type: choice
|
|
57
|
+
required: false
|
|
58
|
+
default: ""
|
|
59
|
+
options:
|
|
60
|
+
- ""
|
|
61
|
+
- min
|
|
62
|
+
- recommended
|
|
63
|
+
- max
|
|
50
64
|
mode:
|
|
51
65
|
description: "Run mode"
|
|
52
66
|
type: choice
|
|
@@ -115,6 +129,8 @@ jobs:
|
|
|
115
129
|
run: |
|
|
116
130
|
MODEL='${{ inputs.model }}'
|
|
117
131
|
echo "model=${MODEL:-gpt-5-mini}" >> $GITHUB_OUTPUT
|
|
132
|
+
PROFILE='${{ inputs.profile }}'
|
|
133
|
+
echo "profile=${PROFILE}" >> $GITHUB_OUTPUT
|
|
118
134
|
MODE='${{ inputs.mode }}'
|
|
119
135
|
echo "mode=${MODE:-full}" >> $GITHUB_OUTPUT
|
|
120
136
|
echo "message=${{ inputs.message }}" >> $GITHUB_OUTPUT
|
|
@@ -137,6 +153,7 @@ jobs:
|
|
|
137
153
|
echo "config-path=${CONFIG:-${{ env.configPath }}}" >> $GITHUB_OUTPUT
|
|
138
154
|
outputs:
|
|
139
155
|
model: ${{ steps.normalise.outputs.model }}
|
|
156
|
+
profile: ${{ steps.normalise.outputs.profile }}
|
|
140
157
|
mode: ${{ steps.normalise.outputs.mode }}
|
|
141
158
|
message: ${{ steps.normalise.outputs.message }}
|
|
142
159
|
issue-number: ${{ steps.normalise.outputs.issue-number }}
|
|
@@ -330,6 +347,23 @@ jobs:
|
|
|
330
347
|
working-directory: .github/agentic-lib/actions/agentic-step
|
|
331
348
|
run: npm ci
|
|
332
349
|
|
|
350
|
+
- name: Apply profile and model to config
|
|
351
|
+
if: needs.params.outputs.profile != '' || needs.params.outputs.model != 'gpt-5-mini'
|
|
352
|
+
run: |
|
|
353
|
+
CONFIG="${{ needs.params.outputs.config-path }}"
|
|
354
|
+
PROFILE="${{ needs.params.outputs.profile }}"
|
|
355
|
+
MODEL="${{ needs.params.outputs.model }}"
|
|
356
|
+
if [ -f "$CONFIG" ]; then
|
|
357
|
+
if [ -n "$PROFILE" ]; then
|
|
358
|
+
sed -i "s/^profile = \"[^\"]*\"/profile = \"${PROFILE}\"/" "$CONFIG"
|
|
359
|
+
echo "Updated [tuning].profile to: ${PROFILE}"
|
|
360
|
+
fi
|
|
361
|
+
if [ -n "$MODEL" ] && [ "$MODEL" != "gpt-5-mini" ]; then
|
|
362
|
+
sed -i "s/^model = \"[^\"]*\"/model = \"${MODEL}\"/" "$CONFIG"
|
|
363
|
+
echo "Updated [tuning].model to: ${MODEL}"
|
|
364
|
+
fi
|
|
365
|
+
fi
|
|
366
|
+
|
|
333
367
|
- name: Load config
|
|
334
368
|
id: config
|
|
335
369
|
run: |
|
|
@@ -961,6 +995,7 @@ jobs:
|
|
|
961
995
|
echo "## agentic-lib-workflow run summary" >> $GITHUB_STEP_SUMMARY
|
|
962
996
|
echo "- Mode: ${{ needs.params.outputs.mode }}" >> $GITHUB_STEP_SUMMARY
|
|
963
997
|
echo "- Model: ${{ needs.params.outputs.model }}" >> $GITHUB_STEP_SUMMARY
|
|
998
|
+
echo "- Profile: ${{ needs.params.outputs.profile || '(from config)' }}" >> $GITHUB_STEP_SUMMARY
|
|
964
999
|
echo "- Dry-run: ${{ needs.params.outputs.dry-run }}" >> $GITHUB_STEP_SUMMARY
|
|
965
1000
|
echo "- Website: [${SITE_URL}](${SITE_URL})" >> $GITHUB_STEP_SUMMARY
|
|
966
1001
|
|
|
@@ -972,4 +1007,5 @@ jobs:
|
|
|
972
1007
|
with:
|
|
973
1008
|
frequency: ${{ needs.params.outputs.schedule }}
|
|
974
1009
|
model: ${{ needs.params.outputs.model }}
|
|
1010
|
+
profile: ${{ needs.params.outputs.profile }}
|
|
975
1011
|
secrets: inherit
|
package/package.json
CHANGED
|
@@ -12,12 +12,24 @@ to build) and the tests pass and the main at least doesn't output an error.
|
|
|
12
12
|
Your goal is mission complete — if the mission can be fully accomplished while fixing this issue,
|
|
13
13
|
do it. Don't limit yourself to the minimal fix when you can deliver the whole mission in one pass.
|
|
14
14
|
|
|
15
|
-
|
|
16
|
-
exports or behaviour, also update the website files to stay in sync.
|
|
15
|
+
## All Code Must Change Together
|
|
17
16
|
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
17
|
+
A fix is never just one file. These layers form a single unit — if you change one, check all the others:
|
|
18
|
+
|
|
19
|
+
- **Library source** (`src/lib/main.js`) — the core implementation
|
|
20
|
+
- **Unit tests** (`tests/unit/`) — test every function at the API level with exact values and edge cases
|
|
21
|
+
- **Website** (`src/web/index.html` and related files) — imports and calls the library to demonstrate features
|
|
22
|
+
- **Website unit tests** (`tests/unit/web.test.js`) — verify HTML structure and library wiring
|
|
23
|
+
- **Behaviour tests** (`tests/behaviour/`) — Playwright tests that load the website in a real browser
|
|
24
|
+
and verify features work at a high navigational level (demo output visible, interactive elements work)
|
|
25
|
+
|
|
26
|
+
If the failure is in one layer, the fix often requires coordinating changes across multiple layers.
|
|
27
|
+
For example, if a unit test fails because a function signature changed, the website and behaviour tests
|
|
28
|
+
that use that function also need updating. A full test suite (unit + behaviour) runs after your fix
|
|
29
|
+
regardless — each failed attempt consumes transformation budget, so get it right in one pass.
|
|
30
|
+
|
|
31
|
+
**Both unit tests AND behaviour tests must pass.** The project runs `npm test` (unit tests) and
|
|
32
|
+
`npm run test:behaviour` (Playwright). Both are gated — your fix must pass both.
|
|
21
33
|
|
|
22
34
|
## Merge Conflict Resolution
|
|
23
35
|
|
|
@@ -56,7 +56,7 @@ When relaying supervisor responses back to the user, present them naturally as y
|
|
|
56
56
|
Users can ask for new features or mission changes through this discussion thread:
|
|
57
57
|
|
|
58
58
|
- **Feature requests** — When a user says "add feature X" or "I want Y", acknowledge the request and pass it to the supervisor to create a GitHub issue. The pipeline will pick it up and implement it.
|
|
59
|
-
- **Re-seed requests** — When a user says "change the mission to Z" or "re-seed with plot-code-lib", explain that this requires running `npx @xn-intenton-z2a/agentic-lib init --purge --mission <name>`. List the available missions if asked: hamming-distance, fizz-buzz, roman-numerals, string-utils, dense-encoding, cron-engine, owl-ontology, plot-code-lib, time-series-lab, lunar-lander, empty. Note that re-seeding resets all source code, issues, and discussions.
|
|
59
|
+
- **Re-seed requests** — When a user says "change the mission to Z" or "re-seed with plot-code-lib", explain that this requires running `npx @xn-intenton-z2a/agentic-lib init --purge --mission <name>`. List the available missions if asked: hamming-distance, fizz-buzz, roman-numerals, string-utils, dense-encoding, cron-engine, owl-ontology, plot-code-lib, time-series-lab, lunar-lander, c64-emulator, ray-tracer, markdown-compiler, empty. Note that re-seeding resets all source code, issues, and discussions.
|
|
60
60
|
- **Website feedback** — The project has a website that uses the JS library, published via GitHub Pages. If a user comments on the website, pass feedback to the supervisor to create an issue for the pipeline to address.
|
|
61
61
|
|
|
62
62
|
## Website Awareness
|
|
@@ -9,6 +9,27 @@ Do as much as you can all at once. Your goal is mission complete — if the miss
|
|
|
9
9
|
accomplished in this single transform, it should be. Deliver all acceptance criteria, tests, website,
|
|
10
10
|
docs, and README in one pass. Only leave work for a follow-up if it genuinely cannot fit.
|
|
11
11
|
|
|
12
|
+
## All Code Must Change Together
|
|
13
|
+
|
|
14
|
+
Every transform produces a coordinated set of changes across all layers. These are NOT independent —
|
|
15
|
+
they form a single unit that must be internally consistent:
|
|
16
|
+
|
|
17
|
+
- **Library source** (`src/lib/main.js`) — the core implementation. All exported functions, types, constants.
|
|
18
|
+
- **Unit tests** (`tests/unit/`) — test every function and edge case at the API level. These bind to the
|
|
19
|
+
detail: exact return values, error types, boundary conditions, parameter validation.
|
|
20
|
+
- **Website** (`src/web/index.html` and related files) — a working demo that imports and calls the library.
|
|
21
|
+
The website is the public face of the library and should show its features in action.
|
|
22
|
+
- **Website unit tests** (`tests/unit/web.test.js`) — verify the website HTML structure and library wiring.
|
|
23
|
+
- **Behaviour tests** (`tests/behaviour/`) — Playwright tests that load the website in a real browser and
|
|
24
|
+
verify it works end-to-end. These test at a high navigational level: can a user see the demo output?
|
|
25
|
+
Do the interactive elements work? Is the library identity displayed?
|
|
26
|
+
- **Documentation** (`docs/`, `README.md`) — evidence, examples, and user-facing docs.
|
|
27
|
+
|
|
28
|
+
If you change a function signature in the library, you MUST also update: the unit tests that call it,
|
|
29
|
+
the website code that uses it, the web tests that check for its output, and any behaviour test assertions
|
|
30
|
+
that depend on it. A partial change that updates the library but not the tests will fail — and there will
|
|
31
|
+
be a full test run after your changes regardless, consuming budget on each failure.
|
|
32
|
+
|
|
12
33
|
## Tests Must Pass
|
|
13
34
|
|
|
14
35
|
Your changes MUST leave all existing tests passing. If you change function signatures, return values, or
|
|
@@ -21,10 +42,19 @@ When writing both tests and implementation:
|
|
|
21
42
|
- Ensure the implementation passes those tests before delivering
|
|
22
43
|
- Do not write tests with different expectations than the implementation produces
|
|
23
44
|
|
|
24
|
-
**Both unit tests AND behaviour tests must pass.**
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
45
|
+
**Both unit tests AND behaviour tests must pass.** The project runs `npm test` (unit tests) and
|
|
46
|
+
`npm run test:behaviour` (Playwright). Both are gated — your changes must pass both.
|
|
47
|
+
|
|
48
|
+
### Test philosophy
|
|
49
|
+
|
|
50
|
+
- **Unit tests** bind to the detail: exact return values, error types, edge cases, parameter validation.
|
|
51
|
+
Every exported function should have unit test coverage.
|
|
52
|
+
- **Behaviour tests** demonstrate features at a high navigational level through the website. They verify
|
|
53
|
+
that a user visiting the site can see the library working: demo output appears, interactive elements
|
|
54
|
+
respond, the library identity is displayed. Aim to show features through behaviour tests rather than
|
|
55
|
+
just testing internal APIs — if a feature is worth building, it's worth demonstrating on the website.
|
|
56
|
+
- **Web unit tests** verify the HTML structure: expected elements exist (`#demo-output`, `#lib-name`,
|
|
57
|
+
`#lib-version`), scripts load, and the library is wired in correctly.
|
|
28
58
|
|
|
29
59
|
Follow the linting guidelines and the formatting guidelines from the included config.
|
|
30
60
|
|
|
@@ -55,6 +85,8 @@ automatically (from `docs/` via `npm run build:web`).
|
|
|
55
85
|
- **Use the library**: Import the library (or its browser-compatible parts) and call its functions on the page
|
|
56
86
|
- **Show real results**: Display actual output from library functions, not placeholder text
|
|
57
87
|
- When you add or change library functions, update the website to reflect them
|
|
88
|
+
- **Demonstrate features**: Each significant library feature should be visible and usable on the website.
|
|
89
|
+
Behaviour tests will verify these demonstrations work, so make them testable (use IDs, structured output).
|
|
58
90
|
|
|
59
91
|
### Guidelines
|
|
60
92
|
|
|
@@ -27,4 +27,9 @@ Features must be achievable in a single software repository not part of a corpor
|
|
|
27
27
|
The feature spec should be a multiline markdown with a few level 1 headings.
|
|
28
28
|
The feature must be compatible with the mission statement in MISSION.md and ideally realise part of the value in the mission.
|
|
29
29
|
The feature must be something that can be realised in a single source file (as below), ideally just as a library, CLI tool or possibly an HTTP API in combination with infrastructure as code deployment.
|
|
30
|
-
The repository also has a website in `src/web/` that uses the JS library. When proposing features, consider
|
|
30
|
+
The repository also has a website in `src/web/` that uses the JS library. When proposing features, consider:
|
|
31
|
+
- The library API (`src/lib/main.js`) and its exports
|
|
32
|
+
- How the feature could be demonstrated on the website — features should be visible and interactive
|
|
33
|
+
- Unit tests (`tests/unit/`) that verify exact behaviour at the API level
|
|
34
|
+
- Behaviour tests (`tests/behaviour/`) that verify features work at a high navigational level through the website
|
|
35
|
+
- All layers (library, tests, website, web tests, behaviour tests) must change together in a single transform
|
|
@@ -3,7 +3,19 @@ Please review the GitHub issue and determine if it should be enhanced, closed or
|
|
|
3
3
|
If the issue is relevant to the mission statement and features:
|
|
4
4
|
|
|
5
5
|
1. Decide if the issue should be refined, closed or if no operation is needed.
|
|
6
|
-
2. Update the issue description with testable acceptance criteria derived from MISSION.md. Include ALL of:
|
|
6
|
+
2. Update the issue description with testable acceptance criteria derived from MISSION.md. Include ALL of:
|
|
7
|
+
- **Library implementation** (`src/lib/main.js`) — the core functions and exports
|
|
8
|
+
- **Unit tests** (`tests/unit/`) — tests that bind to the detail: exact return values, error types, edge cases
|
|
9
|
+
- **Website updates** (`src/web/`) — demonstrate the feature on the website so users can see it working
|
|
10
|
+
- **Behaviour tests** (`tests/behaviour/`) — Playwright tests that verify the feature works at a high
|
|
11
|
+
navigational level through the website (e.g. demo output is visible, interactive elements respond).
|
|
12
|
+
Prefer demonstrating features through behaviour tests rather than only testing internal APIs.
|
|
13
|
+
- **Web tests** (`tests/unit/web.test.js`) — verify HTML structure and library wiring
|
|
14
|
+
- **Docs/evidence** (`docs/`) and **README** updates
|
|
15
|
+
The issue should ask for mission complete — if the entire mission can be accomplished in a single
|
|
16
|
+
transform, the acceptance criteria should cover everything. Only scope down if the mission is
|
|
17
|
+
genuinely too large for one pass. Emphasise that all layers must change together because a full
|
|
18
|
+
test suite runs after the transform.
|
|
7
19
|
3. Enhance the issue by adding relevant library documents as issue comments that support implementation.
|
|
8
20
|
|
|
9
21
|
If the issue is irrelevant to the mission statement or features:
|
|
@@ -1,16 +1,23 @@
|
|
|
1
|
-
Does the combination source
|
|
1
|
+
Does the combination of library source, unit tests, website, web tests, behaviour tests, README,
|
|
2
|
+
and dependencies resolve the following issue? Check that the solution satisfies the issue's
|
|
3
|
+
acceptance criteria and moves the mission toward complete.
|
|
2
4
|
|
|
3
5
|
An issue is NOT resolved unless ALL of the following are true:
|
|
4
|
-
1. The implementation
|
|
5
|
-
2.
|
|
6
|
+
1. The **library source** (`src/lib/main.js`) has the implementation and matches what the issue asks for
|
|
7
|
+
2. **Unit tests** (`tests/unit/`) exist that specifically test the implemented functionality
|
|
8
|
+
(seed-only identity tests do NOT count). Tests bind to the detail: exact return values, error types, edge cases.
|
|
6
9
|
3. Tests match the acceptance criteria in MISSION.md — the mission is the source of truth
|
|
7
10
|
4. Tests and implementation are consistent — test expectations must match what the code actually returns (casing, types, formats)
|
|
11
|
+
5. The **website** (`src/web/`) has been updated to demonstrate the new/changed library features
|
|
12
|
+
6. **Web tests** (`tests/unit/web.test.js`) verify the website structure and library wiring
|
|
13
|
+
7. **Behaviour tests** (`tests/behaviour/`) demonstrate features at a high navigational level through the
|
|
14
|
+
website — a user visiting the site can see the feature working (not just that the API exists internally)
|
|
8
15
|
|
|
9
|
-
If any of these are missing, the issue is NOT resolved — keep it open or create a follow-up issue for the gap.
|
|
16
|
+
If any of these are missing, the issue is NOT resolved — keep it open or create a follow-up issue for the gap.
|
|
17
|
+
Do not close an issue just because implementation code exists without matching tests and website updates.
|
|
10
18
|
|
|
11
|
-
If the mission could have been fully accomplished in this transform but the solution only partially addresses it,
|
|
12
|
-
|
|
13
|
-
Note: The repository has a website in `src/web/` that uses the JS library. When reviewing, check that website files are updated alongside library changes.
|
|
19
|
+
If the mission could have been fully accomplished in this transform but the solution only partially addresses it,
|
|
20
|
+
note this gap and suggest a follow-up issue for the remaining work.
|
|
14
21
|
|
|
15
22
|
When reviewing, also check that evidence artifacts exist under `docs/` for implemented features.
|
|
16
23
|
If a feature works but has no evidence (no example outputs, test results, or walkthroughs in `docs/`),
|
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
# Mission
|
|
2
|
+
|
|
3
|
+
Build a Markdown-to-HTML compiler library that converts GitHub Flavored Markdown (GFM) to
|
|
4
|
+
semantic HTML.
|
|
5
|
+
|
|
6
|
+
The library should progressively implement parsing and rendering for:
|
|
7
|
+
1. Headings (h1-h6 via `#` markers) and paragraphs
|
|
8
|
+
2. Inline formatting: bold (`**`), italic (`*`), code (`` ` ``), strikethrough (`~~`)
|
|
9
|
+
3. Links `[text](url)` and images ``
|
|
10
|
+
4. Ordered and unordered lists (including nested lists)
|
|
11
|
+
5. Code blocks (fenced with ``` and language annotation)
|
|
12
|
+
6. Blockquotes (nested `>`)
|
|
13
|
+
7. Tables (GFM pipe syntax with alignment)
|
|
14
|
+
8. Horizontal rules (`---`, `***`, `___`)
|
|
15
|
+
9. Task lists (`- [ ]`, `- [x]`)
|
|
16
|
+
10. Auto-linked URLs and HTML entity escaping
|
|
17
|
+
|
|
18
|
+
## Technical Requirements
|
|
19
|
+
|
|
20
|
+
- Pure JavaScript, no external Markdown parsing libraries
|
|
21
|
+
- Two-pass architecture: tokeniser/lexer pass, then renderer pass
|
|
22
|
+
- XSS-safe: all user content must be HTML-escaped before insertion
|
|
23
|
+
- Exported as both CommonJS and ESM
|
|
24
|
+
|
|
25
|
+
## Acceptance Criteria
|
|
26
|
+
|
|
27
|
+
- `compile(markdown)` returns an HTML string
|
|
28
|
+
- `tokenize(markdown)` returns an array of token objects (for inspection/testing)
|
|
29
|
+
- Handles all 10 feature areas listed above
|
|
30
|
+
- Passes a test suite of at least 30 input/output pairs covering edge cases
|
|
31
|
+
- Nested constructs work: bold inside links, links inside lists, code inside blockquotes
|
|
32
|
+
- A sample document is compiled and saved to `docs/examples/sample.html`
|
|
33
|
+
- Output validates as well-formed HTML (no unclosed tags)
|
|
@@ -0,0 +1,31 @@
|
|
|
1
|
+
# Mission
|
|
2
|
+
|
|
3
|
+
Build a ray tracer library that renders 3D scenes to PPM image files.
|
|
4
|
+
|
|
5
|
+
The library should progressively implement:
|
|
6
|
+
1. Ray-sphere intersection and basic shading
|
|
7
|
+
2. Multiple objects (spheres, planes) with diffuse lighting
|
|
8
|
+
3. Shadows and ambient occlusion
|
|
9
|
+
4. Reflective surfaces with recursive ray bouncing
|
|
10
|
+
5. Refractive materials (glass, water) with Snell's law
|
|
11
|
+
6. A scene description format (JSON) for defining cameras, lights, and objects
|
|
12
|
+
7. Anti-aliasing via supersampling
|
|
13
|
+
8. Texture mapping (checkerboard, procedural noise)
|
|
14
|
+
|
|
15
|
+
## Technical Requirements
|
|
16
|
+
|
|
17
|
+
- Pure JavaScript, no native dependencies
|
|
18
|
+
- Output PPM (P3) format — simple text-based image format
|
|
19
|
+
- Vector3 class for all geometric operations
|
|
20
|
+
- Configurable resolution and ray depth
|
|
21
|
+
- Deterministic output (no random sampling unless seeded)
|
|
22
|
+
|
|
23
|
+
## Acceptance Criteria
|
|
24
|
+
|
|
25
|
+
- `renderScene(scene)` returns a PPM string for a given scene description
|
|
26
|
+
- `parseScene(json)` loads a scene from a JSON string
|
|
27
|
+
- Renders a scene with 3+ spheres, a plane, and a point light in under 10 seconds (640x480)
|
|
28
|
+
- At least one sphere is reflective and one is refractive
|
|
29
|
+
- Unit tests verify ray-sphere intersection, reflection vectors, and Snell's law
|
|
30
|
+
- A sample scene JSON file is included in `docs/examples/`
|
|
31
|
+
- Output PPM can be viewed in any image viewer (validated by checking header format)
|