[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) |
3 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