face-up 0.0.0 → 0.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.
Files changed (46) hide show
  1. package/.gitmodules +3 -0
  2. package/.kiro/steering/project-context.md +17 -0
  3. package/.vscode/settings.json +3 -0
  4. package/FaceUp.js +305 -0
  5. package/README.md +162 -2
  6. package/imports.html +8 -0
  7. package/package.json +30 -20
  8. package/tests/test1.html +115 -0
  9. package/types/.kiro/specs/conversion-template/README.md +128 -0
  10. package/types/.kiro/specs/conversion-template/design.md +360 -0
  11. package/types/.kiro/specs/conversion-template/requirements.md +191 -0
  12. package/types/.kiro/specs/conversion-template/tasks.md +174 -0
  13. package/types/.kiro/steering/coding-standards.md +17 -0
  14. package/types/.kiro/steering/conversion-guide.md +103 -0
  15. package/types/.kiro/steering/declarative-configuration.md +108 -0
  16. package/types/.kiro/steering/emc-json-serializability.md +306 -0
  17. package/types/EnhancementConversionInstructions.md +1626 -0
  18. package/types/LICENSE +21 -0
  19. package/types/NewCustomElementFeature.md +673 -0
  20. package/types/NewEnhancementInstructions.md +395 -0
  21. package/types/README.md +2 -0
  22. package/types/agrace/types.d.ts +11 -0
  23. package/types/assign-gingerly/types.d.ts +328 -0
  24. package/types/be-a-beacon/types.d.ts +17 -0
  25. package/types/be-bound/types.d.ts +61 -0
  26. package/types/be-buttoned-up/types.d.ts +19 -0
  27. package/types/be-clonable/types.d.ts +36 -0
  28. package/types/be-committed/types.d.ts +22 -0
  29. package/types/be-decked-with/types.d.ts +26 -0
  30. package/types/be-delible/types.d.ts +25 -0
  31. package/types/be-reflective/types.d.ts +80 -0
  32. package/types/be-render-neutral/types.d.ts +29 -0
  33. package/types/be-typed/types.d.ts +31 -0
  34. package/types/do-inc/types.d.ts +56 -0
  35. package/types/do-invoke/types.d.ts +38 -0
  36. package/types/do-merge/types.d.ts +28 -0
  37. package/types/do-toggle/types.d.ts +31 -0
  38. package/types/face-up/types.d.ts +104 -0
  39. package/types/global.d.ts +29 -0
  40. package/types/id-generation/types.d.ts +26 -0
  41. package/types/inferencer/types.d.ts +46 -0
  42. package/types/mount-observer/types.d.ts +363 -0
  43. package/types/nested-regex-groups/types.d.ts +101 -0
  44. package/types/roundabout/types.d.ts +255 -0
  45. package/types/time-ticker/types.d.ts +66 -0
  46. package/types/truth-sourcer/types.d.ts +46 -0
@@ -0,0 +1,128 @@
1
+ # Conversion Template
2
+
3
+ This spec template provides a structured approach to converting legacy be-* enhancement projects to the modern architecture.
4
+
5
+ ## When to Use This Template
6
+
7
+ Use this template when:
8
+ - You want to track conversion progress step-by-step
9
+ - You're converting a be-* project for the first time
10
+ - You want to review each step before proceeding
11
+ - Multiple people are involved in the conversion
12
+ - You want a record of the conversion process
13
+
14
+ ## How to Use This Template
15
+
16
+ ### Option 1: Copy to Project (Recommended)
17
+
18
+ 1. Copy this entire folder to your project's `.kiro/specs/` directory:
19
+ ```bash
20
+ cp -r types/.kiro/specs/conversion-template .kiro/specs/conversion-[project-name]
21
+ ```
22
+
23
+ 2. Update placeholders in all files:
24
+ - Replace `[PROJECT_NAME]` with your project name (e.g., "be-clonable")
25
+ - Replace `[project-name]` with kebab-case name (e.g., "be-clonable")
26
+ - Replace `[ClassName]` with PascalCase name (e.g., "BeClonable")
27
+ - Replace `[emoji]` with actual emoji if applicable (e.g., "⿻")
28
+
29
+ 3. Work through the tasks in `tasks.md` sequentially
30
+
31
+ 4. Use Kiro to execute tasks: "execute task 1", "execute task 2", etc.
32
+
33
+ ### Option 2: Use as Reference
34
+
35
+ Simply reference this template while doing a manual conversion:
36
+ - Follow the requirements in `requirements.md`
37
+ - Understand the architecture from `design.md`
38
+ - Use `tasks.md` as a checklist
39
+
40
+ ## Template Structure
41
+
42
+ ### requirements.md
43
+ - User stories for each conversion step
44
+ - Correctness properties to verify
45
+ - Success criteria
46
+ - Non-functional requirements
47
+
48
+ ### design.md
49
+ - Architecture overview with diagrams
50
+ - Component design for each file type
51
+ - Data flow explanations
52
+ - Design decisions and rationale
53
+ - Alternatives considered
54
+
55
+ ### tasks.md
56
+ - Detailed task breakdown (11 major tasks, 60+ subtasks)
57
+ - Task dependencies
58
+ - Execution notes for each step
59
+ - Reference to ConversionInstructions.md
60
+
61
+ ## Key Features
62
+
63
+ ### Comprehensive Coverage
64
+ All 10 conversion steps from ConversionInstructions.md are covered with detailed subtasks
65
+
66
+ ### Verification Built-in
67
+ Task 11 provides comprehensive verification steps to ensure conversion success
68
+
69
+ ### Reference Integration
70
+ All files reference ConversionInstructions.md for detailed step-by-step instructions
71
+
72
+ ### Kiro-Optimized
73
+ - Uses file references: `#[[file:../../ConversionInstructions.md]]`
74
+ - Task format compatible with Kiro's task execution
75
+ - Structured for spec-driven development workflow
76
+
77
+ ## Example Usage with Kiro
78
+
79
+ ```
80
+ User: "I want to convert be-clonable to the modern architecture"
81
+
82
+ Kiro: "I can help you with that. Would you like to:
83
+ 1. Create a tracked conversion spec (recommended for first-time conversions)
84
+ 2. Do a direct conversion (faster, for experienced users)
85
+
86
+ User: "Create a spec"
87
+
88
+ Kiro: [Creates spec from template, updates placeholders]
89
+ "I've created a conversion spec at .kiro/specs/conversion-be-clonable/
90
+ Let's start with Task 1: Migrate Type Definitions. Ready to begin?"
91
+
92
+ User: "Yes"
93
+
94
+ Kiro: [Executes Task 1, marks subtasks complete]
95
+ "Task 1 complete. Type definitions migrated to types/be-clonable/.
96
+ Ready for Task 2: Archive Legacy Implementation?"
97
+ ```
98
+
99
+ ## Success Criteria
100
+
101
+ A successful conversion using this template should result in:
102
+ - ✅ All tasks marked complete
103
+ - ✅ `npm run build` succeeds
104
+ - ✅ `npm test` passes
105
+ - ✅ No TypeScript errors
106
+ - ✅ Legacy code preserved in legacy/ folder
107
+ - ✅ Modern architecture verified
108
+
109
+ ## Related Files
110
+
111
+ - `../../ConversionInstructions.md` - Detailed step-by-step instructions
112
+ - `../../.kiro/steering/conversion-guide.md` - Kiro steering guidance
113
+ - Reference implementations:
114
+ - [be-a-beacon](https://github.com/bahrus/be-a-beacon)
115
+ - [be-committed](https://github.com/bahrus/be-committed)
116
+ - [be-decked-with](https://github.com/bahrus/be-decked-with)
117
+
118
+ ## Customization
119
+
120
+ Feel free to customize this template for your specific needs:
121
+ - Add project-specific tasks
122
+ - Modify verification steps
123
+ - Add additional correctness properties
124
+ - Extend design documentation
125
+
126
+ ## Feedback
127
+
128
+ If you find issues with this template or have suggestions for improvement, please update the template in the types repository so all projects benefit.
@@ -0,0 +1,360 @@
1
+ # Design: Convert [PROJECT_NAME] to Modern Architecture
2
+
3
+ ## Architecture Overview
4
+
5
+ This conversion transforms a legacy be-enhanced project to the modern be-hive + roundabout architecture. The design follows a systematic 10-step process that preserves the original implementation while building the new architecture.
6
+
7
+ ## System Context
8
+
9
+ ```
10
+ ┌─────────────────────────────────────────────────────────────┐
11
+ │ Legacy Architecture │
12
+ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
13
+ │ │ emc.js │ │ be-*.js │ │ ts-refs/ │ │
14
+ │ │ (runtime) │ │ extends BE │ │ (types) │ │
15
+ │ └──────────────┘ └──────────────┘ └──────────────┘ │
16
+ │ │ │ │ │
17
+ │ └──────────────────┴──────────────────┘ │
18
+ │ │ │
19
+ │ be-enhanced │
20
+ │ trans-render │
21
+ └─────────────────────────────────────────────────────────────┘
22
+
23
+ [CONVERSION]
24
+
25
+
26
+ ┌─────────────────────────────────────────────────────────────┐
27
+ │ Modern Architecture │
28
+ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
29
+ │ │ emc.mjs │ │ be-*.js │ │ types/ │ │
30
+ │ │ (build) │ │ standalone │ │ (types) │ │
31
+ │ └──────────────┘ └──────────────┘ └──────────────┘ │
32
+ │ │ │ │ │
33
+ │ ▼ │ │ │
34
+ │ emc.json └──────────────────┘ │
35
+ │ │ │ │
36
+ │ └───────────────────────────┘ │
37
+ │ │ │
38
+ │ be-hive │
39
+ │ roundabout-lib │
40
+ │ assign-gingerly │
41
+ └─────────────────────────────────────────────────────────────┘
42
+ ```
43
+
44
+ ## Component Design
45
+
46
+ ### 1. Type Definitions (types/[project-name]/types.d.ts)
47
+
48
+ **Purpose:** Standalone type definitions without external dependencies
49
+
50
+ **Structure:**
51
+ ```typescript
52
+ // EndUserProps: Properties exposed to HTML attributes
53
+ export interface EndUserProps {
54
+ // User-facing properties
55
+ }
56
+
57
+ // AllProps: Internal properties + EndUserProps
58
+ export interface AllProps extends EndUserProps {
59
+ enhancedElement: Element; // Required
60
+ // Internal properties
61
+ }
62
+
63
+ // Type aliases for convenience
64
+ export type AP = AllProps;
65
+ export type PAP = Partial<AP>;
66
+ export type ProPAP = Promise<PAP>;
67
+
68
+ // Actions: Methods that implement behavior
69
+ export interface Actions {
70
+ methodName(self: AP): ProPAP | void;
71
+ }
72
+ ```
73
+
74
+ **Key Design Decisions:**
75
+ - No external imports (standalone)
76
+ - `enhancedElement` is explicit in AllProps
77
+ - BAP removed (was AP & BEAllProps)
78
+ - All action methods use AP instead of BAP
79
+
80
+ ### 2. Build Configuration (emc.mjs)
81
+
82
+ **Purpose:** Generate static JSON configuration at build time
83
+
84
+ **Structure:**
85
+ ```javascript
86
+ //@ts-check
87
+ import {emc} from './emc.mjs';
88
+
89
+ /** @import {EMC} from './types/mount-observer/types' */;
90
+ /** @import {AllProps, Actions} from './types/[project-name]/types' */
91
+ /** @import {RAConfig} from './types/roundabout/types' */
92
+
93
+ export const emc = {
94
+ enhConfig: {
95
+ enhKey: 'EnhancementKey',
96
+ spawn: '[project-name]/[project-name].js',
97
+ withAttrs: {
98
+ base: '[project-name]',
99
+ // Attribute mappings using ${base} template
100
+ }
101
+ },
102
+ customData: {
103
+ weakRef: {
104
+ properties: ['enhancedElement']
105
+ },
106
+ actions: { /* reactive action triggers */ },
107
+ handlers: { /* event handlers */ },
108
+ compacts: { /* compact syntax mappings */ }
109
+ }
110
+ }
111
+
112
+ export function render(){
113
+ return JSON.stringify(emc, null, 4);
114
+ }
115
+
116
+ console.log(render());
117
+ ```
118
+
119
+ **Key Design Decisions:**
120
+ - withAttrs replaces base/branches/map (cleaner syntax)
121
+ - customData contains reactive configuration
122
+ - weakRef configuration tells roundabout which properties to store as weak references
123
+ - No propDefaults/propInfo (inferred by roundabout)
124
+ - Build-time only (not loaded in browser)
125
+
126
+ ### 3. Enhancement Class (be-[project-name].js)
127
+
128
+ **Purpose:** Implement enhancement behavior using modern patterns
129
+
130
+ **Structure:**
131
+ ```javascript
132
+ // @ts-check
133
+ /**
134
+ * @type {EMC<any, AllProps, Element, RAConfig<AllProps, Actions>>}
135
+ */
136
+ import emc from './emc.json' with {type: 'json'};
137
+
138
+ class Be[ClassName] {
139
+
140
+ // Constructor: Initialize and setup
141
+ constructor(enhancedElement, ctx, initVals) {
142
+ // Call init with enhancedElement
143
+ }
144
+
145
+ // Init: Setup roundabout and defaults
146
+ async init(self, enhancedElement, initVals) {
147
+ // Configure roundabout with weakRef support
148
+ // Set defaults via assignGingerly (including enhancedElement)
149
+ }
150
+
151
+ // Action methods (copied from legacy)
152
+ async actionMethod(self) { /* ... */ }
153
+ }
154
+
155
+ export { Be[ClassName] }
156
+ ```
157
+
158
+ **Key Design Decisions:**
159
+ - No base class (standalone)
160
+ - No WeakRef boilerplate - roundabout handles it via customData.weakRef
161
+ - Constructor pattern (enhancedElement, ctx, initVals)
162
+ - Init receives enhancedElement as parameter
163
+ - Roundabout integration in init
164
+ - assignGingerly for property assignment (including enhancedElement)
165
+ - No static config (moved to emc.mjs)
166
+
167
+ ### 4. Emoji Shorthand ([emoji].mjs)
168
+
169
+ **Purpose:** Generate variant configuration for emoji syntax
170
+
171
+ **Structure:**
172
+ ```javascript
173
+ import myJSON from './emc.json' with {type: 'json'};
174
+
175
+ const emc = {
176
+ enhConfig: {
177
+ ...myJSON.enhConfig,
178
+ enhKey: '[emoji]',
179
+ withAttrs: {
180
+ ...myJSON.enhConfig.withAttrs,
181
+ base: '[emoji]'
182
+ }
183
+ }
184
+ }
185
+
186
+ export function render(){
187
+ return JSON.stringify(emc, null, 4);
188
+ }
189
+
190
+ console.log(render());
191
+ ```
192
+
193
+ **Key Design Decisions:**
194
+ - Extends base configuration
195
+ - Only overrides enhKey and base
196
+ - Minimal duplication
197
+
198
+ ## Data Flow
199
+
200
+ ### Build Time
201
+ ```
202
+ emc.mjs ──[node]──> emc.json
203
+
204
+ └──> [emoji].mjs ──[node]──> [emoji].json
205
+ ```
206
+
207
+ ### Runtime
208
+ ```
209
+ HTML Attribute
210
+
211
+
212
+ be-hive (mount observer)
213
+
214
+
215
+ emc.json (configuration)
216
+
217
+
218
+ Enhancement Class Constructor
219
+
220
+
221
+ init() method
222
+
223
+ ├──> roundabout (reactive properties)
224
+
225
+ └──> assignGingerly (property assignment)
226
+
227
+
228
+ Action Methods
229
+ ```
230
+
231
+ ## Conversion Process Design
232
+
233
+ ### Phase 1: Preparation (Steps 1-2)
234
+ - Migrate types to new submodule
235
+ - Archive legacy implementation
236
+ - **Rationale:** Preserve original, establish clean slate
237
+
238
+ ### Phase 2: Configuration (Steps 3-5)
239
+ - Update package.json
240
+ - Configure imports.html
241
+ - Establish coding standards
242
+ - **Rationale:** Set up infrastructure before code changes
243
+
244
+ ### Phase 3: Types (Step 6)
245
+ - Modernize type definitions
246
+ - **Rationale:** Types inform implementation
247
+
248
+ ### Phase 4: Build System (Steps 7-8)
249
+ - Create emc.mjs
250
+ - Configure VS Code
251
+ - **Rationale:** Build system generates runtime config
252
+
253
+ ### Phase 5: Implementation (Steps 9-10)
254
+ - Create modern enhancement class
255
+ - Create emoji shorthand (optional)
256
+ - **Rationale:** Implement using new architecture
257
+
258
+ ## Error Handling
259
+
260
+ ### Build Errors
261
+ - Validate JSON output from .mjs files
262
+ - Check for missing required fields
263
+ - Verify TypeScript types
264
+
265
+ ### Runtime Errors
266
+ - Missing properties → roundabout handles reactivity
267
+ - WeakRef.deref() returns undefined → roundabout throws appropriate error
268
+ - Action method errors → propagate naturally
269
+
270
+ ## Testing Strategy
271
+
272
+ ### Unit Tests
273
+ - Test action methods in isolation
274
+ - Verify property reactivity
275
+ - Check event handlers
276
+
277
+ ### Integration Tests
278
+ - Test full enhancement lifecycle
279
+ - Verify attribute parsing
280
+ - Check emoji shorthand equivalence
281
+
282
+ ### Build Tests
283
+ - Verify JSON generation
284
+ - Check TypeScript compilation
285
+ - Validate configuration structure
286
+
287
+ ## Performance Considerations
288
+
289
+ ### Build Time
290
+ - JSON generation is fast (< 1s per file)
291
+ - No complex transformations
292
+
293
+ ### Runtime
294
+ - WeakRef allows garbage collection
295
+ - Roundabout provides efficient reactivity
296
+ - No unnecessary object creation
297
+
298
+ ### Memory
299
+ - WeakRef handled automatically by roundabout for configured properties
300
+ - No circular references
301
+ - Clean teardown
302
+
303
+ ## Security Considerations
304
+
305
+ - No eval or dynamic code execution
306
+ - Trusted types support (TODO in some methods)
307
+ - Attribute values sanitized by browser
308
+
309
+ ## Compatibility
310
+
311
+ ### Browser Support
312
+ - Modern ES modules required
313
+ - Import maps required
314
+ - WeakRef required (modern browsers) - handled by roundabout
315
+
316
+ ### Backward Compatibility
317
+ - HTML usage unchanged
318
+ - Same attribute names
319
+ - Same behavior
320
+
321
+ ## Migration Path
322
+
323
+ ### For Users
324
+ - No changes required to HTML
325
+ - Can use either full name or emoji
326
+ - Behavior identical to legacy
327
+
328
+ ### For Developers
329
+ - Follow 10-step process
330
+ - Reference ConversionInstructions.md
331
+ - Use this spec for tracking
332
+
333
+ ## Alternatives Considered
334
+
335
+ ### Alternative 1: Keep be-enhanced
336
+ **Rejected:** Legacy architecture has limitations, not actively maintained
337
+
338
+ ### Alternative 2: Complete Rewrite
339
+ **Rejected:** Too risky, loses proven behavior
340
+
341
+ ### Alternative 3: Gradual Migration
342
+ **Rejected:** Creates hybrid state, more complex
343
+
344
+ ### Selected: Systematic Conversion
345
+ **Rationale:** Preserves legacy, clear process, proven pattern
346
+
347
+ ## Open Questions
348
+
349
+ - Should we automate any steps?
350
+ - Should we create a CLI tool for conversion?
351
+ - How do we handle edge cases in static config?
352
+
353
+ ## References
354
+
355
+ - ConversionInstructions.md (detailed steps)
356
+ - be-a-beacon (reference implementation)
357
+ - be-committed (reference implementation)
358
+ - be-decked-with (reference implementation)
359
+ - assign-gingerly README (withAttrs documentation)
360
+ - roundabout-lib (reactive properties)
@@ -0,0 +1,191 @@
1
+ # Requirements: Convert [PROJECT_NAME] to Modern Architecture
2
+
3
+ ## Overview
4
+
5
+ Convert the legacy [PROJECT_NAME] enhancement project from the be-enhanced architecture to the modern be-hive + roundabout architecture.
6
+
7
+ ## Reference Documentation
8
+
9
+ Complete conversion instructions: `#[[file:../../ConversionInstructions.md]]`
10
+
11
+ ## User Stories
12
+
13
+ ### US-1: Migrate Type Definitions
14
+ **As a** developer
15
+ **I want** type definitions in the modern `types` submodule
16
+ **So that** the project uses the clearer naming convention
17
+
18
+ **Acceptance Criteria:**
19
+ - Type definitions exist at `types/[project-name]/types.d.ts`
20
+ - `ts-refs` submodule is removed
21
+ - Types are accessible from the new location
22
+
23
+ ### US-2: Preserve Legacy Implementation
24
+ **As a** developer
25
+ **I want** the original implementation preserved in a `legacy` folder
26
+ **So that** I can reference it during and after conversion
27
+
28
+ **Acceptance Criteria:**
29
+ - All `.js`, `.mjs`, and `.json` files (except package*.json) are moved to `legacy/`
30
+ - Legacy folder contains complete working implementation
31
+ - Root directory is ready for new implementation
32
+
33
+ ### US-3: Update Dependencies
34
+ **As a** developer
35
+ **I want** modern dependencies (be-hive, roundabout-lib)
36
+ **So that** the project uses the new architecture
37
+
38
+ **Acceptance Criteria:**
39
+ - package.json has be-hive, mount-observer, and roundabout-lib dependencies
40
+ - Legacy dependencies (be-enhanced, trans-render) are removed
41
+ - Build scripts use the new pattern (node emc.mjs > emc.json)
42
+ - `npm run update` successfully updates to latest versions
43
+
44
+ ### US-4: Configure Import Maps
45
+ **As a** developer
46
+ **I want** a proper imports.html file
47
+ **So that** browser-based ES modules work correctly
48
+
49
+ **Acceptance Criteria:**
50
+ - imports.html exists with correct import map structure
51
+ - Project maps to "/" root
52
+ - Dependencies map to /node_modules/[package]/
53
+
54
+ ### US-5: Establish Coding Standards
55
+ **As a** developer
56
+ **I want** documented coding standards
57
+ **So that** the codebase follows consistent conventions
58
+
59
+ **Acceptance Criteria:**
60
+ - `.kiro/steering/coding-standards.md` exists
61
+ - Standards cover import maps, file extensions, and TypeScript support
62
+ - Standards are automatically included in Kiro context
63
+
64
+ ### US-6: Modernize Type Definitions
65
+ **As a** developer
66
+ **I want** standalone type definitions without external dependencies
67
+ **So that** types are portable and self-contained
68
+
69
+ **Acceptance Criteria:**
70
+ - No imports from trans-render or be-enhanced in types
71
+ - `EndUserProps` doesn't extend IEnhancement
72
+ - `AllProps` includes `enhancedElement: Element`
73
+ - `BAP` type is removed, replaced with `AP`
74
+
75
+ ### US-7: Create Build Configuration
76
+ **As a** developer
77
+ **I want** an emc.mjs build script
78
+ **So that** configuration is generated at build time
79
+
80
+ **Acceptance Criteria:**
81
+ - emc.mjs exists with proper structure
82
+ - Uses withAttrs pattern for attribute mapping
83
+ - customData contains actions, handlers, compacts from legacy config
84
+ - No propDefaults or propInfo (inferred by roundabout)
85
+ - `npm run build` generates valid emc.json
86
+
87
+ ### US-8: Configure VS Code
88
+ **As a** developer
89
+ **I want** VS Code file nesting configured
90
+ **So that** generated JSON files are organized under their source .mjs files
91
+
92
+ **Acceptance Criteria:**
93
+ - `.vscode/settings.json` exists
94
+ - File nesting patterns configured for *.mjs -> *.json
95
+ - File nesting is enabled
96
+
97
+ ### US-8a: Configure Auto-Build Hook (Optional)
98
+ **As a** developer
99
+ **I want** automatic rebuilding when .mjs files are saved
100
+ **So that** JSON files stay in sync without manual build commands
101
+
102
+ **Acceptance Criteria:**
103
+ - Kiro hook exists for fileEdited event
104
+ - Hook watches emc.mjs and emoji .mjs files
105
+ - Hook runs npm run build on save
106
+ - JSON files regenerate automatically
107
+
108
+ ### US-9: Create Modern Enhancement Class
109
+ **As a** developer
110
+ **I want** a modern enhancement class using roundabout
111
+ **So that** the implementation uses the new architecture
112
+
113
+ **Acceptance Criteria:**
114
+ - be-[project-name].js exists
115
+ - Class doesn't extend anything
116
+ - Uses constructor with enhancedElement, ctx, initVals
117
+ - Uses WeakRef for element storage
118
+ - init method integrates roundabout
119
+ - Default values set via assignGingerly in init
120
+ - All action methods copied with BAP replaced by AP
121
+ - No bootUp or legacy imports
122
+
123
+ ### US-10: Create Emoji Shorthand (Optional)
124
+ **As a** developer
125
+ **I want** an emoji shorthand configuration
126
+ **So that** users can use the shorter emoji syntax
127
+
128
+ **Acceptance Criteria:**
129
+ - [emoji].mjs exists (if emoji in README title)
130
+ - Imports and extends emc.json
131
+ - Overrides enhKey and base to use emoji
132
+ - `npm run build` generates [emoji].json
133
+
134
+ ## Correctness Properties
135
+
136
+ ### CP-1: Build Success
137
+ **Property:** The project builds without errors
138
+ **Test:** Run `npm run build` and verify exit code 0
139
+
140
+ ### CP-2: Test Compatibility
141
+ **Property:** All existing tests pass with the new implementation
142
+ **Test:** Run `npm test` and verify all tests pass
143
+
144
+ ### CP-3: Configuration Validity
145
+ **Property:** Generated JSON configuration is valid and complete
146
+ **Test:** Parse emc.json and verify all required fields exist
147
+
148
+ ### CP-4: Type Safety
149
+ **Property:** TypeScript checking passes with @ts-check
150
+ **Test:** No TypeScript errors in be-[project-name].js
151
+
152
+ ### CP-5: Legacy Preservation
153
+ **Property:** Legacy implementation is complete and unchanged
154
+ **Test:** Verify all original files exist in legacy/ folder
155
+
156
+ ## Non-Functional Requirements
157
+
158
+ ### Performance
159
+ - Build time should be under 5 seconds
160
+ - No runtime performance degradation vs legacy
161
+
162
+ ### Maintainability
163
+ - Code follows documented standards
164
+ - Clear separation between configuration and implementation
165
+ - Consistent with other converted projects
166
+
167
+ ### Documentation
168
+ - ConversionInstructions.md is the source of truth
169
+ - Each step is clearly documented
170
+ - Examples provided for complex transformations
171
+
172
+ ## Dependencies
173
+
174
+ - Node.js and npm installed
175
+ - Access to types submodule
176
+ - Original project in working state
177
+
178
+ ## Constraints
179
+
180
+ - Must maintain backward compatibility with existing HTML usage
181
+ - Must preserve all existing functionality
182
+ - Must follow the 10-step conversion process in order
183
+
184
+ ## Success Metrics
185
+
186
+ - ✅ All 10 conversion steps completed
187
+ - ✅ `npm run build` succeeds
188
+ - ✅ `npm test` passes
189
+ - ✅ No TypeScript errors
190
+ - ✅ Legacy code preserved
191
+ - ✅ Modern architecture verified