[DRAFT] Integrate spec-driven development workflow#2213
Conversation
|
|
||
| ## API Guards | ||
|
|
||
| - ALWAYS check `actionValue.canExecute` before calling `execute()` |
There was a problem hiding this comment.
We have a utility function that does this, maybe we could refer that too.
iobuhov
left a comment
iobuhov
left a comment
There was a problem hiding this comment.
Main question - how openspec going to work per package?
There was a problem hiding this comment.
I think we should use default schema for now. This context is very widget specific and we probably should make a skill out of it.
There was a problem hiding this comment.
I think this file needs splitting. We probably should create ~/.agents/conventions as conventions is subject to change. We can use this spec as a pointer to our conventions files.
| /opsx:archive | ||
| ``` | ||
|
|
||
| ## Structure |
There was a problem hiding this comment.
Probably not final structure, so I would avoid this section for now.
|
I like the idea of mendix-widget schema |
We can use openspec cii to init each widget with (--tools none) |
| - ALWAYS check `actionValue.canExecute` before calling `execute()` | ||
| - NEVER render widget content while value status is `"loading"` — show loading/placeholder state instead | ||
| - Use `editableValue.setValue()` for two-way binding, never mutate the value directly | ||
| - Handle all three `EditableValue` states: `"available"`, `"loading"`, `"unavailable"` |
There was a problem hiding this comment.
Sounds like a skill candidate - how to work with Mendix PW API.
| - XML property keys MUST be lowerCamelCase and MUST match TypeScript prop names exactly | ||
| - When adding an XML property: update `<Widget>.xml`, rebuild to regenerate `typings/<Widget>Props.d.ts`, update `editorConfig.ts`, and `editorPreview.tsx` | ||
| - Each widget MUST have a unique widget ID in `package.xml` — never duplicate across widgets |
There was a problem hiding this comment.
Sounds like a skill candidate - how to work with Properties XML
gjulivan
force-pushed
the
chore/openspec-v1
branch
from
da0b198 to
1593240
Compare
| #### Scenario: XML property renamed | ||
|
|
||
| - GIVEN a developer renames an existing XML property | ||
| - WHEN the change is merged | ||
| - THEN the TypeScript prop name MUST be updated to match the new XML key | ||
| - AND all usages of the old prop name in `.tsx` and `editorConfig.ts` MUST be updated | ||
|
|
There was a problem hiding this comment.
We almost never rename properties, because it is a breaking change.
- We change captions sometimes, but this doesn't change their typings.
- We rarely change property types, this needs a really special case.
| #### Scenario: New XML property added | ||
|
|
||
| - GIVEN a developer adds a new property to `<WidgetName>.xml` | ||
| - WHEN the property has any supported Mendix type (string, integer, boolean, action, attribute, datasource, etc.) |
There was a problem hiding this comment.
Adding unsupported types should not be even an option 🤔
| Widget XML property keys SHALL use lowerCamelCase and MUST match the corresponding | ||
| TypeScript prop names exactly. |
There was a problem hiding this comment.
xml leads, typings is a compilation byproduct, we probably should not mention this. Flow should be simple: adjust XML -> compile typings, done.
| - GIVEN a widget has an `ActionValue` prop | ||
| - WHEN a user triggers the action (click, keypress, programmatic trigger) | ||
| - THEN the widget MUST verify `canExecute === true` before calling `execute()` | ||
| - AND if `canExecute` is false, the interaction SHALL be silently ignored or the trigger element disabled |
There was a problem hiding this comment.
This reads that it should be disabled after user clicks it once, should be the opposite: If and action is tied to a UI element directly (most of the cases it is not, I believe), then UI element should be disabled in the first place.
|
|
||
| context: | | ||
| Widget: combobox-web (Combo Box) | ||
| Version: 2.8.0 | Min Mendix: 10.22.0 |
There was a problem hiding this comment.
Do we need to mention version here? It is readable from package.json and we will forget to update it here on new releases.
4 participants
Pull request type
No code changes (changes to documentation, CI, metadata, etc.)
Description
Sets up OpenSpec for spec-driven widget development. Introduces per-widget openspec directories alongside a custom mendix-widget schema and tool-agnostic agent rules.
What's included:
config.yaml— monorepo-level context (Mendix API patterns, tech stack, per-artifact rules)mendix-widget— custom schema with 4 Mendix-aware artifact templates (proposal, spec, design, tasks) and correct dependency orderspec.md— shared widget development conventions as a formal spec (ActionValue guard, XML alignment, semver, Atlas UI, testing)mendix-widget.md— concise, tool-agnostic coding rules for any AI coding assistantconfig.yaml, brownfield baseline specs/spec.md, and per-widgetAGENTS.mdAgent files updated:
AGENTS.md— OpenSpec workflow section with per-widget init conventionCLAUDE.md—spec.md+ schema auto-loaded