mosaic-headless 1.32.0 → 1.32.1

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/SKILL.md CHANGED
@@ -5,7 +5,7 @@ description: |
5
5
  license: "MIT"
6
6
  metadata:
7
7
  author: "moksa (https://moksaweb.com)"
8
- version: "1.32.0"
8
+ version: "1.32.1"
9
9
  homepage: "https://github.com/Moksa1123/mosaic-headless"
10
10
  ---
11
11
 
@@ -20,7 +20,7 @@
20
20
  "description": "Build and modify Mosaic Pro (Nextend) sites by writing the underlying data model directly - no visual editor, no DOM. Query the real surface (122 node types, 181 node properties, 98 style properties, 53 style states, 151 element classes, 74 dynamic variables, 114 REST routes, 23 tables) instead of guessing, with every node type placed on a live site one at a time and asserted against the delivered HTML, every style and node property swept against the compiled CSS and markup, and 569 responsive declarations checked against the stylesheet the site actually served.",
21
21
  "license": "MIT",
22
22
  "author": "moksa (https://moksaweb.com)",
23
- "version": "1.32.0"
23
+ "version": "1.32.1"
24
24
  },
25
25
  "loaderBehaviour": "Upload via Settings -> Skills -> Upload. Claude.ai parses SKILL.md frontmatter and surfaces the skill in your library. The extraction tool (extract-block-schema.php) needs a live WP-CLI connection and won't run in the sandbox; use it from a local terminal against your own site instead.",
26
26
  "uploadSteps": [
@@ -20,7 +20,7 @@
20
20
  "description": "Build and modify Mosaic Pro (Nextend) sites by writing the underlying data model directly - no visual editor, no DOM. Query the real surface (122 node types, 181 node properties, 98 style properties, 53 style states, 151 element classes, 74 dynamic variables, 114 REST routes, 23 tables) instead of guessing, with every node type placed on a live site one at a time and asserted against the delivered HTML, every style and node property swept against the compiled CSS and markup, and 569 responsive declarations checked against the stylesheet the site actually served.",
21
21
  "license": "MIT",
22
22
  "author": "moksa (https://moksaweb.com)",
23
- "version": "1.32.0"
23
+ "version": "1.32.1"
24
24
  },
25
25
  "loaderBehaviour": "Auto-loads on session start when SKILL.md frontmatter parses successfully.",
26
26
  "verified": true,
@@ -20,7 +20,7 @@
20
20
  "description": "Build and modify Mosaic Pro (Nextend) sites by writing the underlying data model directly - no visual editor, no DOM. Query the real surface (122 node types, 181 node properties, 98 style properties, 53 style states, 151 element classes, 74 dynamic variables, 114 REST routes, 23 tables) instead of guessing, with every node type placed on a live site one at a time and asserted against the delivered HTML, every style and node property swept against the compiled CSS and markup, and 569 responsive declarations checked against the stylesheet the site actually served.",
21
21
  "license": "MIT",
22
22
  "author": "moksa (https://moksaweb.com)",
23
- "version": "1.32.0"
23
+ "version": "1.32.1"
24
24
  },
25
25
  "loaderBehaviour": "Confirmed (2026-07-11): Codex CLI natively supports the SKILL.md spec. Place SKILL.md under .codex/skills/<name>/ (project) or ~/.codex/skills/<name>/ (personal) and Codex loads the name+description at session start, then the full body on demand. A parallel, broader convention .agents/skills/ (searched from cwd up to repo root, then ~/.agents/skills/) also exists across multiple tools - if your Codex CLI version prioritizes that path instead, mirror the same SKILL.md there.",
26
26
  "verified": true,
@@ -20,7 +20,7 @@
20
20
  "description": "Build and modify Mosaic Pro (Nextend) sites by writing the underlying data model directly - no visual editor, no DOM. Query the real surface (122 node types, 181 node properties, 98 style properties, 53 style states, 151 element classes, 74 dynamic variables, 114 REST routes, 23 tables) instead of guessing, with every node type placed on a live site one at a time and asserted against the delivered HTML, every style and node property swept against the compiled CSS and markup, and 569 responsive declarations checked against the stylesheet the site actually served.",
21
21
  "license": "MIT",
22
22
  "author": "moksa (https://moksaweb.com)",
23
- "version": "1.32.0"
23
+ "version": "1.32.1"
24
24
  },
25
25
  "loaderBehaviour": "CHANGED as of 2026-07-11: GitHub Copilot added a proper '.github/skills/' Agent Skills directory (December 2025), alongside the older single-file .github/copilot-instructions.md convention. This config targets the new skills-directory form. If your Copilot version predates this (pre Dec 2025), use the instructions-append fallback instead (see fallback below).",
26
26
  "fallback": {
@@ -20,7 +20,7 @@
20
20
  "description": "Build and modify Mosaic Pro (Nextend) sites by writing the underlying data model directly - no visual editor, no DOM. Query the real surface (122 node types, 181 node properties, 98 style properties, 53 style states, 151 element classes, 74 dynamic variables, 114 REST routes, 23 tables) instead of guessing, with every node type placed on a live site one at a time and asserted against the delivered HTML, every style and node property swept against the compiled CSS and markup, and 569 responsive declarations checked against the stylesheet the site actually served.",
21
21
  "license": "MIT",
22
22
  "author": "moksa (https://moksaweb.com)",
23
- "version": "1.32.0"
23
+ "version": "1.32.1"
24
24
  },
25
25
  "loaderBehaviour": "CHANGED as of 2026-07-11: Gemini CLI now natively supports the same SKILL.md standard as Claude Code and Codex CLI - the same directory-based skill works unmodified. Gemini CLI discovers skills in this precedence order: built-in, extension skills, ~/.gemini/skills/ (personal), .gemini/skills/ (project, shared via version control). At session start Gemini injects each discovered skill's name+description into the system prompt and calls activate_skill when a task matches.",
26
26
  "verified": true,
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "mosaic-headless",
3
- "version": "1.32.0",
3
+ "version": "1.32.1",
4
4
  "description": "AI-agent skill: build Mosaic Pro (Nextend) WordPress sites by writing the underlying data model directly - 23 custom tables, no visual editor, no DOM. Every node type, style property and node property swept against a live install and asserted on the delivered HTML and compiled CSS. Installs into Claude Code, Cursor, Codex CLI, Gemini CLI, Copilot, Continue, Windsurf and Claude.ai.",
5
5
  "keywords": [
6
6
  "wordpress",
@@ -213,18 +213,34 @@ only the slots that differ:
213
213
  "cs-name": {"text": "…"}}}
214
214
  ```
215
215
 
216
- **An instance's ids are prefixed with the instance's own attrID.** The definition's
217
- `cs-card` becomes `cs-0-cs-card`, `cs-1-cs-card`, and so on, so the definition's
218
- attrID is a SUFFIX in the delivered page and `getElementById` on it finds nothing.
219
- Address instances with `[id$="-cs-card"]`.
216
+ **Mosaic copies the definition's ids into every instance verbatim; `build_site.py`
217
+ is what makes them unique.** Mosaic has no id-prefixing of its own - an element's
218
+ id is its `attrID` (`ElementAttrID.php`), and every instance renders the
219
+ definition's nodes with the definition's attrIDs, so two instances put every id
220
+ into the document twice. `build_site.py`'s override pass writes an `attrID` of
221
+ `<instance attrID>-<definition attrID>` into each instance's override node: the
222
+ definition's `cs-card` becomes `cs-0-cs-card`, `cs-1-cs-card`, and so on, so the
223
+ definition's attrID is a SUFFIX in the delivered page and `getElementById` on it
224
+ finds nothing. Address instances with `[id$="-cs-card"]`.
225
+
226
+ Until 1.32.1 that pass ran only for instances that HAD overrides, so an instance
227
+ written with none - a contact block placed as-is in a footer and in a page body -
228
+ kept the definition's ids, and a client build found every one of them twice. It runs
229
+ for every instance now; measured on the demo, two override-less instances gave
230
+ `ft-a-cs-card` and `ft-b-cs-card` and no duplicates. A tool other than
231
+ `build_site.py` that writes instances has to do the same, or accept duplicate ids.
220
232
 
221
233
  Four more things a build that leans on components runs into:
222
234
 
223
- - **The instance element itself carries no id.** Its `attrID` exists only as that
224
- prefix, so a selector aimed at the instance's own attrID finds nothing - aim at
225
- `<instance>-<definition id>`. Two instances given the SAME attrID (or none) get
226
- the same prefix and so duplicate every id inside; give each a distinct attrID. A
227
- page with two `case-card` instances, `cs-0` and `cs-1`, measured zero duplicates.
235
+ - **The instance element itself carries no id.** Its `attrID` exists only as the
236
+ prefix `build_site.py` writes, so a selector aimed at the instance's own attrID
237
+ finds nothing - aim at `<instance>-<definition id>`. Two instances given the SAME
238
+ attrID (or none) get the same prefix and so duplicate every id inside; give each a
239
+ distinct attrID.
240
+ - **A loop repeats ids too, and that one is Mosaic's.** Every `loop-item` renders
241
+ the same attrIDs, so a list of six cards carries six of each id (reported from a
242
+ client build). `ElementAttrID.php` evaluates an attrID per loop item, which is the
243
+ hook for making them unique; that has not been measured here.
228
244
  - **A component's id is its name.** `build_site.py` derives it with
229
245
  `uuid5(COMPONENT_NAMESPACE, name)` so rebuilds update the same row; renaming the
230
246
  key in `site["components"]` therefore creates a new component and leaves the old
@@ -262,7 +262,11 @@ def apply_overrides(client, instance, key, uses, comps, envelope="templateDocume
262
262
  `strpos($type, 'component-instance')`, and strpos returns 0 for a needle at
263
263
  offset 0, so the condition is false for every instance there will ever be.
264
264
  """
265
- wanted = [u for u in uses if u.get("overrides")]
265
+ # EVERY instance, not only the ones with overrides: this pass is also what gives
266
+ # each instance's inner nodes their own ids (below). Filtering on overrides left
267
+ # an instance without any as a verbatim copy of the definition's ids - a client
268
+ # build put the same component in a footer and a page body and got every id twice.
269
+ wanted = list(uses)
266
270
  if not wanted:
267
271
  return 0
268
272
  doc = unwrap(client.get(instance), envelope)