@lazyingart/agintiflow 0.20.150 → 0.20.151
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.
|
@@ -23,7 +23,7 @@ The validator promotes candidates only after schema and project-specific checks
|
|
|
23
23
|
|
|
24
24
|
The reviewer inspects valid-looking artifacts for missing source units, source drift, repeated filler, malformed annotations, suspicious all-one-style output, and other known quality failures. It writes candidate fixes or failed-only repair requests.
|
|
25
25
|
|
|
26
|
-
The repairer runs independently of the writer. It can wake from status files, handle failed or quarantined chunks, retry with exact validator errors, reduce chunk size, or escalate to a stronger model when the project allows it.
|
|
26
|
+
The repairer runs independently of the writer. It can wake from status files, handle failed or quarantined chunks, retry with exact validator errors, reduce chunk size, or escalate to a stronger model when the project allows it. If the error is mechanical, it should repair locally first: punctuation restoration from source text, token splitting, default metadata, schema migration, and renderer wrapping should not consume model calls.
|
|
27
27
|
|
|
28
28
|
The monitor is gentle. It waits through healthy progress and provider limits, restarts only on hard evidence of stall or crash, and records each decision.
|
|
29
29
|
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@lazyingart/agintiflow",
|
|
3
|
-
"version": "0.20.
|
|
3
|
+
"version": "0.20.151",
|
|
4
4
|
"type": "module",
|
|
5
5
|
"description": "AgInTiFlow is a project-aware agent workspace for hybrid wet-dry R&D, hardware-aware intelligence, software automation, and industrial workflows.",
|
|
6
6
|
"license": "Apache-2.0",
|
|
@@ -48,6 +48,7 @@ Project-specific schemas, prompts, layouts, and compilers belong in the target r
|
|
|
48
48
|
- Convert raw files into durable intermediate inputs before asking a model to generate downstream artifacts.
|
|
49
49
|
- Split work into deterministic chunks that survive reruns. If chunk policy changes, map old outputs by stable source IDs instead of restarting from zero.
|
|
50
50
|
- Use isolated structured-data calls for repetitive JSON units. Keep prompts focused on the chunk, schema, source references, and validation errors.
|
|
51
|
+
- Add deterministic canonicalizers before model retry when failures are representational, such as punctuation normalization, stable token splitting, missing metadata backfill, schema version migration, or renderer-specific wrapping. Do not spend provider calls on repairs a local script can prove.
|
|
51
52
|
- Run writers in tmux or another observable background process. Each worker must have disjoint claims, atomic output writes, and shard-local logs.
|
|
52
53
|
- Keep review and repair asynchronous but safe. Reviewers may produce candidate fixes while writers continue; only validators or merge scripts promote candidates.
|
|
53
54
|
- Compile or export checkpoint previews after successful merge batches and always at final completion.
|
|
@@ -60,6 +61,7 @@ A robust pipeline has an independent repair path that is not blocked by the main
|
|
|
60
61
|
- Heartbeats record active worker, current chunk, last success, last failure, and provider wait state.
|
|
61
62
|
- Provider/rate-limit failures wait with backoff and retry at long intervals.
|
|
62
63
|
- Schema/parse failures are repaired with the exact validator error and the smallest useful input.
|
|
64
|
+
- Mechanical validation failures are repaired locally first when the canonical form is derivable from source text or schema rules.
|
|
63
65
|
- Semantic/source-drift failures are retried with smaller chunks or stronger source references.
|
|
64
66
|
- Repeated failures are quarantined with reasons, then handled by a bounded failed-only repair pass.
|
|
65
67
|
- Monitor intervention is gentle: observe healthy progress, restart only on hard error, stale claim, repeated no-progress window, or missing child process.
|
|
@@ -38,6 +38,7 @@ Use this skill when the user needs reliable JSON that follows an explicit schema
|
|
|
38
38
|
- On validation failure, retry with the exact schema errors and only the smallest relevant source text.
|
|
39
39
|
- For batch work, write candidate JSON per chunk first; promote it only after schema and semantic validators pass.
|
|
40
40
|
- Keep schema versions in the artifact metadata so old reviewed outputs can be reused or selectively regenerated when prompts change.
|
|
41
|
+
- Before retrying the provider, classify whether the failure is semantic or mechanical. Use local canonicalization for deterministic fixes such as token splitting, punctuation restoration from source text, missing default fields, role aliases, or renderer wrappers.
|
|
41
42
|
|
|
42
43
|
## Boundaries
|
|
43
44
|
|