@specverse/engines 6.0.1 → 6.0.2
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.
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
name: analyse
|
|
2
|
-
version: "9.
|
|
2
|
+
version: "9.3.0"
|
|
3
3
|
description: Extract SpecVerse specifications from existing code with deployment policy recognition
|
|
4
4
|
author: SpecVerse Team
|
|
5
5
|
tags: [analysis, reverse-engineering, implementation, v9, deployment-policies, validate-fix-loop]
|
|
@@ -46,6 +46,32 @@ system:
|
|
|
46
46
|
7. Controllers should focus on CURVED operations, models on business behaviors, services on orchestration
|
|
47
47
|
8. Do NOT include implementation details like HTTP paths or routes in controllers
|
|
48
48
|
|
|
49
|
+
LIFECYCLE EXTRACTION RULES (critical — common mistake area):
|
|
50
|
+
- A lifecycle attaches to the MODEL where the source code DECLARES the
|
|
51
|
+
status / state field. Look for: a Prisma `status` column or similar;
|
|
52
|
+
a TypeScript enum used as a column type; a status / state field in
|
|
53
|
+
a CREATE TABLE statement; an explicit state-machine implementation
|
|
54
|
+
(XState, etc.). The lifecycle owner is the model that has the field,
|
|
55
|
+
not a related model.
|
|
56
|
+
- The states are the LITERAL values that field accepts in the source
|
|
57
|
+
— do not reword them, pluralise / depluralise, or reorder for
|
|
58
|
+
narrative effect. Preserve casing if it is snake_case; if the
|
|
59
|
+
source uses kebab-case or PascalCase, snake_case-ify (per the
|
|
60
|
+
schema's snake_case requirement) but keep the value identifiers.
|
|
61
|
+
- If multiple models have status fields, extract one lifecycle per
|
|
62
|
+
model. Do NOT collapse them into a single "the status of the
|
|
63
|
+
system" lifecycle.
|
|
64
|
+
- Do NOT INVENT a lifecycle on a model that has no status field
|
|
65
|
+
declared in code, even if the domain (e.g. "an Order goes through
|
|
66
|
+
stages") strongly suggests one. If you can't point at the source
|
|
67
|
+
line that declares the field, do not emit a lifecycle there.
|
|
68
|
+
- Worked example of correct attribution:
|
|
69
|
+
|
|
70
|
+
Source: `model Room { status RoomStatus }` plus
|
|
71
|
+
`enum RoomStatus { free booked checkin checkout }`
|
|
72
|
+
→ Room.lifecycles.status: { flow: "free -> booked -> checkin -> checkout" }
|
|
73
|
+
NOT a Booking.lifecycles (Booking has dates but no status field).
|
|
74
|
+
|
|
49
75
|
DEPLOYMENT PRINCIPLES:
|
|
50
76
|
1. Capture ALL deployment details - environments, instances, scaling, operational policies
|
|
51
77
|
2. Extract operational policies from code decorators, annotations, and middleware
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
name: analyse
|
|
2
|
-
version: "9.
|
|
2
|
+
version: "9.3.0"
|
|
3
3
|
description: Extract SpecVerse specifications from existing code with deployment policy recognition
|
|
4
4
|
author: SpecVerse Team
|
|
5
5
|
tags: [analysis, reverse-engineering, implementation, v9, deployment-policies, validate-fix-loop]
|
|
@@ -46,6 +46,32 @@ system:
|
|
|
46
46
|
7. Controllers should focus on CURVED operations, models on business behaviors, services on orchestration
|
|
47
47
|
8. Do NOT include implementation details like HTTP paths or routes in controllers
|
|
48
48
|
|
|
49
|
+
LIFECYCLE EXTRACTION RULES (critical — common mistake area):
|
|
50
|
+
- A lifecycle attaches to the MODEL where the source code DECLARES the
|
|
51
|
+
status / state field. Look for: a Prisma `status` column or similar;
|
|
52
|
+
a TypeScript enum used as a column type; a status / state field in
|
|
53
|
+
a CREATE TABLE statement; an explicit state-machine implementation
|
|
54
|
+
(XState, etc.). The lifecycle owner is the model that has the field,
|
|
55
|
+
not a related model.
|
|
56
|
+
- The states are the LITERAL values that field accepts in the source
|
|
57
|
+
— do not reword them, pluralise / depluralise, or reorder for
|
|
58
|
+
narrative effect. Preserve casing if it is snake_case; if the
|
|
59
|
+
source uses kebab-case or PascalCase, snake_case-ify (per the
|
|
60
|
+
schema's snake_case requirement) but keep the value identifiers.
|
|
61
|
+
- If multiple models have status fields, extract one lifecycle per
|
|
62
|
+
model. Do NOT collapse them into a single "the status of the
|
|
63
|
+
system" lifecycle.
|
|
64
|
+
- Do NOT INVENT a lifecycle on a model that has no status field
|
|
65
|
+
declared in code, even if the domain (e.g. "an Order goes through
|
|
66
|
+
stages") strongly suggests one. If you can't point at the source
|
|
67
|
+
line that declares the field, do not emit a lifecycle there.
|
|
68
|
+
- Worked example of correct attribution:
|
|
69
|
+
|
|
70
|
+
Source: `model Room { status RoomStatus }` plus
|
|
71
|
+
`enum RoomStatus { free booked checkin checkout }`
|
|
72
|
+
→ Room.lifecycles.status: { flow: "free -> booked -> checkin -> checkout" }
|
|
73
|
+
NOT a Booking.lifecycles (Booking has dates but no status field).
|
|
74
|
+
|
|
49
75
|
DEPLOYMENT PRINCIPLES:
|
|
50
76
|
1. Capture ALL deployment details - environments, instances, scaling, operational policies
|
|
51
77
|
2. Extract operational policies from code decorators, annotations, and middleware
|