omnius 1.0.567 → 1.0.569
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/npm-shrinkwrap.json
CHANGED
|
@@ -1,12 +1,12 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "omnius",
|
|
3
|
-
"version": "1.0.
|
|
3
|
+
"version": "1.0.569",
|
|
4
4
|
"lockfileVersion": 3,
|
|
5
5
|
"requires": true,
|
|
6
6
|
"packages": {
|
|
7
7
|
"": {
|
|
8
8
|
"name": "omnius",
|
|
9
|
-
"version": "1.0.
|
|
9
|
+
"version": "1.0.569",
|
|
10
10
|
"bundleDependencies": [
|
|
11
11
|
"image-to-ascii"
|
|
12
12
|
],
|
package/package.json
CHANGED
|
@@ -36,6 +36,8 @@ to abandon the active objective.
|
|
|
36
36
|
- Use the smallest safe action that moves the task forward.
|
|
37
37
|
- Do not ask for clarification when the answer can be discovered safely or a
|
|
38
38
|
reasonable local assumption is low risk.
|
|
39
|
+
- For product, transport, firmware, or hardware claims, trace the real
|
|
40
|
+
boundary; label simulation as simulation and never guess a missing contract.
|
|
39
41
|
- Do ask when the missing choice changes scope, irreversible behavior, cost,
|
|
40
42
|
external coordination, or user intent.
|
|
41
43
|
|
|
@@ -0,0 +1,80 @@
|
|
|
1
|
+
# Delivery Surface and Claim Contract
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
Make the actual delivery boundary visible before an agent makes a capability
|
|
6
|
+
claim. A simulation, catalog, UI, protocol encoder, firmware build, transport,
|
|
7
|
+
and physical device are different surfaces. Passing evidence on one surface
|
|
8
|
+
does not silently promote a claim on another.
|
|
9
|
+
|
|
10
|
+
## Discover the real path
|
|
11
|
+
|
|
12
|
+
When a task includes a product catalog, UI, simulator, serial/network/CAN
|
|
13
|
+
transport, firmware, hardware, protocol, or documentation claim, trace the
|
|
14
|
+
relevant path using the source currently in the workspace:
|
|
15
|
+
|
|
16
|
+
```text
|
|
17
|
+
user action or public API
|
|
18
|
+
-> local simulation/mock (if present)
|
|
19
|
+
-> browser/client transport
|
|
20
|
+
-> framing/parser/bridge
|
|
21
|
+
-> firmware or service dispatch
|
|
22
|
+
-> destination protocol/device
|
|
23
|
+
-> returned status/error
|
|
24
|
+
-> documentation and public claim
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
Inspect both sides of every claimed boundary. In particular, check whether a
|
|
28
|
+
parser can accept consecutive frames and resynchronize after non-frame bytes;
|
|
29
|
+
whether UI controls route to transport rather than only local state; whether a
|
|
30
|
+
firmware dispatcher implements the advertised command family; and whether a
|
|
31
|
+
read/unsupported command produces the documented response rather than a
|
|
32
|
+
generic acknowledgement.
|
|
33
|
+
|
|
34
|
+
## Claim states
|
|
35
|
+
|
|
36
|
+
Use the narrowest true state for each material deliverable:
|
|
37
|
+
|
|
38
|
+
- `simulation_only`: behavior is proved in mock/simulator only.
|
|
39
|
+
- `hardware_integrated`: the client-to-firmware/protocol path is exercised,
|
|
40
|
+
but physical-device behavior is not yet proved.
|
|
41
|
+
- `hardware_verified`: a real-device or hardware-in-loop check passed with
|
|
42
|
+
an explicit safety interlock.
|
|
43
|
+
- `blocked`: a required contract, source, device, permission, or acceptance
|
|
44
|
+
layer is absent; name the missing prerequisite.
|
|
45
|
+
|
|
46
|
+
Never call a simulation-only result real control, hardware-ready, or a full
|
|
47
|
+
product implementation. A successful compile proves compilation, not parser
|
|
48
|
+
correctness, transport routing, CAN fragmentation, or actuator behavior.
|
|
49
|
+
|
|
50
|
+
## Product and provenance coverage
|
|
51
|
+
|
|
52
|
+
If `.omnius/delivery-coverage.json` is present, it is the structured claim
|
|
53
|
+
contract. Read its gaps and keep final wording within the declared state.
|
|
54
|
+
Every product series, command, parameter, and model format claimed as
|
|
55
|
+
supported must map to exactly one source-backed contract and provenance record.
|
|
56
|
+
Each selected acceptance layer must also name its canonical verification
|
|
57
|
+
command and have a successful receipt for that exact command in the current
|
|
58
|
+
run. Listing a test in the manifest does not mean it ran.
|
|
59
|
+
Do not fill an absent contract with guessed values, a wildcard, or a claim that
|
|
60
|
+
a neighboring product family probably behaves the same way. Mark it blocked or
|
|
61
|
+
unsupported instead.
|
|
62
|
+
|
|
63
|
+
When external/vendor material is inaccessible, distinguish local contract,
|
|
64
|
+
third-party guide, official vendor source, and inference. Do not describe an
|
|
65
|
+
unreachable source as independently verified.
|
|
66
|
+
|
|
67
|
+
## Acceptance layers
|
|
68
|
+
|
|
69
|
+
Select the smallest relevant executable checks, and retain their exact receipts:
|
|
70
|
+
|
|
71
|
+
- golden cross-language frame vectors for each framing implementation;
|
|
72
|
+
- serial noise/resynchronization and consecutive-frame parsing;
|
|
73
|
+
- browser E2E with a fake/real transport that proves UI controls emit frames;
|
|
74
|
+
- CAN fragmentation/reassembly where classic CAN is used;
|
|
75
|
+
- firmware/PlatformIO build and dispatch-path test;
|
|
76
|
+
- hardware-in-loop only with a stated safety interlock; and
|
|
77
|
+
- documentation consistency between public README, feature docs, and code.
|
|
78
|
+
|
|
79
|
+
These are evidence-selection prompts, not a standing tool order. Skip an
|
|
80
|
+
inapplicable layer explicitly; do not fabricate a passing result.
|