fix: align legacy path references with current directory layout (closes #741) - #747
Merged
Merged
Conversation
#741) The framework directory layout was reorganized at some point with templates, checklists, tasks, agents, workflows, and agent-teams moving under `.aiox-core/` subdirectories (`product/`, `development/`), but ~70 references across docs, tasks, and the knowledge base never followed. The result: `@po *validate-story-draft` (and other story-flow steps) tries to load template paths like `aiox-core/templates/story-tmpl.yaml` that no longer exist, breaking the Story Development Cycle at the validation gate as reported by @renatolhamas in #741. ## Mapping applied | Legacy path | Current path | |---|---| | `aiox-core/templates/<X>` | `.aiox-core/product/templates/<X>` | | `aiox-core/checklists/<X>` | `.aiox-core/product/checklists/<X>` | | `aiox-core/agents/<X>` | `.aiox-core/development/agents/<X>` | | `aiox-core/tasks/<X>` | `.aiox-core/development/tasks/<X>` | | `aiox-core/workflows/<X>` | `.aiox-core/development/workflows/<X>` | | `aiox-core/agent-teams/<X>` | `.aiox-core/development/agent-teams/<X>` | | `aiox-core/data/<X>` | `.aiox-core/data/<X>` (data did NOT move into a subdir; only the prefix gets the dot) | Note the leading dot: `aiox-core/` → `.aiox-core/`. The post-reorganization codebase already uses the dotted form (`.aiox-core/...`); only the legacy non-dotted references needed updating. A negative-lookbehind `(?<![\.])` in the substitution script protects existing dotted references from being rewritten twice. ## Files touched (17 — one extra came in from the pre-commit hook regenerating `entity-registry.yaml`) - **Runtime-affecting (story flow, agent flow):** - `.aiox-core/development/tasks/validate-next-story.md` (the file @renatolhamas pointed at — Line 228 was the trigger) - `.aiox-core/development/tasks/dev-validate-next-story.md` - `.aiox-core/development/tasks/create-next-story.md` - `.aiox-core/development/tasks/sm-create-next-story.md` - `.aiox-core/development/tasks/modify-agent.md` - `.aiox-core/development/tasks/modify-task.md` - `.aiox-core/development/tasks/architect-analyze-impact.md` - `.aiox-core/development/tasks/pr-automation.md` - **Documentation (operator-facing):** - `.aiox-core/user-guide.md` - `.aiox-core/core/docs/component-creation-guide.md` - `.aiox-core/data/aiox-kb.md` - `docs/core-architecture.md` (+ pt/es/zh localizations) - `docs/guides/agents/traces/ux-design-expert-execution-trace.md` - **Generated (regenerated by pre-commit hook, not authored):** - `.aiox-core/data/entity-registry.yaml` ## Method Substitution was scripted (not freehand `sed`) with a negative-lookbehind guard `(?<![\.])aiox-core/<subdir>/` so already-correct dotted references stay intact. Audit verifies zero remaining matches across `.aiox-core/` and `docs/`: ``` $ grep -rnE "['\\\`\\\"]aiox-core/(templates|tasks|checklists|agents|data|workflows|agent-teams)/" .aiox-core/ docs/ | grep -v "\\.aiox-core" | wc -l 0 ``` ## Out of scope (deferred) Other legacy refs that exist in the codebase but were not part of the reorganization that #741 reports: - `aiox-core/core-config.yaml` (root-level config, not a subdir reorg) - `aiox-core/tools/mcp/clickup.yaml` (only 1 occurrence in aiox-kb.md — needs separate decision on where this should live, will follow up) These are 1-off references that don't break the story flow and need their own decision per ref. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
rafaelscosta
requested review from
Pedrovaleriolopez and
oalanicolas
as code owners
May 17, 2026 13:10
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
github-actions
Bot
added
area: core
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
WalkthroughThis PR systematically migrates the AIOX framework to use the new ChangesFramework Directory Migration and DevOps Decoupling
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Contributor
📊 Coverage ReportCoverage report not available
Generated by PR Automation (Story 6.1) |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.aiox-core/data/entity-registry.yaml (1)
14548-14561:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftDon't zero out
agents.devops.dependencieswhile the agent is still a live dependency.This agent is still referenced by active entities in this same registry, for example
environment-bootstrapat Line 2129,execute-epic-planat Line 2198,setup-githubat Line 4520,validate-next-storyat Line 5493, andgreenfield-fullstackat Line 15829. Leavingdependencies: []here makes the registry advertisedevopsas capability-less, which risks breaking any resolver or introspection path that derives agent skills from registry metadata. Either keep the dependency set until those callers are removed, or finish the unwiring sweep in the same change.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.aiox-core/data/entity-registry.yaml around lines 14548 - 14561, The agents.devops entry was changed to have an empty dependencies array while other entities still reference it (e.g., environment-bootstrap, execute-epic-plan, setup-github, validate-next-story, greenfield-fullstack); restore the original dependency list for agents.devops (or reintroduce the specific capability entries previously present) so the registry continues to advertise its capabilities, or alternatively remove/modify all callers (those entity entries) in the same change so nothing references agents.devops; locate the agents.devops block in the registry (look for the checksum and lastVerified fields shown) and either revert the dependencies value to the prior non-empty set or finish the unwiring sweep by updating the listed callers to no longer depend on devops.
🧹 Nitpick comments (1)
docs/guides/agents/traces/ux-design-expert-execution-trace.md (1)
932-939: ⚡ Quick winClarify “short names” phrasing in dependency mapping.
Line 932 says dependencies use “short names,” but the examples/table show fully-qualified path patterns. Please rename this to “canonical path patterns” (or update examples to actual short-name forms) to avoid confusion in trace interpretation.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/guides/agents/traces/ux-design-expert-execution-trace.md` around lines 932 - 939, Update the phrasing around dependency naming in the docs: replace the term "short names" with "canonical path patterns" (or alternatively convert the examples to true short-name forms) where the agent dependency mapping is described (the sentence containing "short names" and the following table showing `.aiox-core/...` patterns), and ensure the table header/description reflects "Agent Definition Path (canonical path pattern)" so readers aren’t misled by fully-qualified examples.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In @.aiox-core/data/entity-registry.yaml:
- Around line 14548-14561: The agents.devops entry was changed to have an empty
dependencies array while other entities still reference it (e.g.,
environment-bootstrap, execute-epic-plan, setup-github, validate-next-story,
greenfield-fullstack); restore the original dependency list for agents.devops
(or reintroduce the specific capability entries previously present) so the
registry continues to advertise its capabilities, or alternatively remove/modify
all callers (those entity entries) in the same change so nothing references
agents.devops; locate the agents.devops block in the registry (look for the
checksum and lastVerified fields shown) and either revert the dependencies value
to the prior non-empty set or finish the unwiring sweep by updating the listed
callers to no longer depend on devops.
---
Nitpick comments:
In `@docs/guides/agents/traces/ux-design-expert-execution-trace.md`:
- Around line 932-939: Update the phrasing around dependency naming in the docs:
replace the term "short names" with "canonical path patterns" (or alternatively
convert the examples to true short-name forms) where the agent dependency
mapping is described (the sentence containing "short names" and the following
table showing `.aiox-core/...` patterns), and ensure the table
header/description reflects "Agent Definition Path (canonical path pattern)" so
readers aren’t misled by fully-qualified examples.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 3528277b-0aae-46d7-8d67-a6f38a736cd2
📒 Files selected for processing (18)
.aiox-core/core/docs/component-creation-guide.md.aiox-core/data/aiox-kb.md.aiox-core/data/entity-registry.yaml.aiox-core/development/tasks/architect-analyze-impact.md.aiox-core/development/tasks/create-next-story.md.aiox-core/development/tasks/dev-validate-next-story.md.aiox-core/development/tasks/modify-agent.md.aiox-core/development/tasks/modify-task.md.aiox-core/development/tasks/pr-automation.md.aiox-core/development/tasks/sm-create-next-story.md.aiox-core/development/tasks/validate-next-story.md.aiox-core/install-manifest.yaml.aiox-core/user-guide.mddocs/core-architecture.mddocs/es/core-architecture.mddocs/guides/agents/traces/ux-design-expert-execution-trace.mddocs/pt/core-architecture.mddocs/zh/core-architecture.md
The 17 file rewrites in the previous commit changed content hashes that the install-manifest tracks. CI Install Manifest Validation was failing on the stale hash; regenerating brings it back in sync. Also picks up entity-registry refresh from the IDS pre-commit hook.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.aiox-core/data/entity-registry.yaml:
- Around line 3-4: The registry update changed metadata.lastUpdated but did not
refresh the registry's self-entry; locate the entities.data.entity-registry
entry in .aiox-core/data/entity-registry.yaml and update its integrity metadata
(set lastVerified to the new lastUpdated timestamp and recompute/replace its
checksum field with the checksum of the current file content); ensure the
self-entry's checksum and lastVerified match the file's current state so
registry/doctor checks remain consistent.
- Around line 14100-14119: The purpose field for the registry entry named
component-creation-guide currently describes dataset analysis; update the
purpose to accurately describe this module as a developer guide for creating
components (what it contains and who it’s for). Locate the
component-creation-guide entry and replace the purpose value with a short,
precise description such as “Developer guide and reference for creating and
registering components, including templates, lifecycle rules, and examples,”
ensuring it reflects the module’s owner-facing intent rather than analytics.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: f915ce3a-a4f3-453f-b3eb-b3493c5ec8e2
📒 Files selected for processing (2)
.aiox-core/data/entity-registry.yaml.aiox-core/install-manifest.yaml
✅ Files skipped from review due to trivial changes (1)
- .aiox-core/install-manifest.yaml
Comment on lines
+3
to
+4
| lastUpdated: '2026-05-17T13:08:28.431Z' | ||
| entityCount: 816 |
There was a problem hiding this comment.
Refresh the registry self-entry alongside lastUpdated.
metadata.lastUpdated now says this file changed at 13:08, but the entities.data.entity-registry self-entry still carries older integrity metadata (lastVerified is still 10:02, and its checksum was not refreshed in this edit). If any doctor/registry check trusts that self-entry, it will drift immediately and can report a false integrity failure.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.aiox-core/data/entity-registry.yaml around lines 3 - 4, The registry update
changed metadata.lastUpdated but did not refresh the registry's self-entry;
locate the entities.data.entity-registry entry in
.aiox-core/data/entity-registry.yaml and update its integrity metadata (set
lastVerified to the new lastUpdated timestamp and recompute/replace its checksum
field with the checksum of the current file content); ensure the self-entry's
checksum and lastVerified match the file's current state so registry/doctor
checks remain consistent.
Comment on lines
+14100
to
+14119
| component-creation-guide: | ||
| path: .aiox-core/core/docs/component-creation-guide.md | ||
| layer: L1 | ||
| type: module | ||
| purpose: Analyzes provided dataset to identify patterns and insights | ||
| keywords: | ||
| - component | ||
| - creation | ||
| - guide | ||
| usedBy: [] | ||
| dependencies: [] | ||
| externalDeps: [] | ||
| plannedDeps: [] | ||
| lifecycle: orphan | ||
| adaptability: | ||
| score: 0.4 | ||
| constraints: [] | ||
| extensionPoints: [] | ||
| checksum: sha256:b94ec24369c9c5a3b747307b14b425c4877de0ec3f5664e000d1f61fc3c61e27 | ||
| lastVerified: '2026-05-17T13:08:28.420Z' |
There was a problem hiding this comment.
Fix the component-creation-guide purpose text.
This reads like a copied analytics description, not a component creation guide. Keeping it as-is will skew registry search/classification for this new module.
Suggested metadata fix
component-creation-guide:
path: .aiox-core/core/docs/component-creation-guide.md
layer: L1
type: module
- purpose: Analyzes provided dataset to identify patterns and insights
+ purpose: Guide for creating and organizing framework components in the current `.aiox-core` layout📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| component-creation-guide: | |
| path: .aiox-core/core/docs/component-creation-guide.md | |
| layer: L1 | |
| type: module | |
| purpose: Analyzes provided dataset to identify patterns and insights | |
| keywords: | |
| - component | |
| - creation | |
| - guide | |
| usedBy: [] | |
| dependencies: [] | |
| externalDeps: [] | |
| plannedDeps: [] | |
| lifecycle: orphan | |
| adaptability: | |
| score: 0.4 | |
| constraints: [] | |
| extensionPoints: [] | |
| checksum: sha256:b94ec24369c9c5a3b747307b14b425c4877de0ec3f5664e000d1f61fc3c61e27 | |
| lastVerified: '2026-05-17T13:08:28.420Z' | |
| component-creation-guide: | |
| path: .aiox-core/core/docs/component-creation-guide.md | |
| layer: L1 | |
| type: module | |
| purpose: Guide for creating and organizing framework components in the current `.aiox-core` layout | |
| keywords: | |
| - component | |
| - creation | |
| - guide | |
| usedBy: [] | |
| dependencies: [] | |
| externalDeps: [] | |
| plannedDeps: [] | |
| lifecycle: orphan | |
| adaptability: | |
| score: 0.4 | |
| constraints: [] | |
| extensionPoints: [] | |
| checksum: sha256:b94ec24369c9c5a3b747307b14b425c4877de0ec3f5664e000d1f61fc3c61e27 | |
| lastVerified: '2026-05-17T13:08:28.420Z' |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.aiox-core/data/entity-registry.yaml around lines 14100 - 14119, The purpose
field for the registry entry named component-creation-guide currently describes
dataset analysis; update the purpose to accurately describe this module as a
developer guide for creating components (what it contains and who it’s for).
Locate the component-creation-guide entry and replace the purpose value with a
short, precise description such as “Developer guide and reference for creating
and registering components, including templates, lifecycle rules, and examples,”
ensuring it reflects the module’s owner-facing intent rather than analytics.
…jections PR #745 added a "Release Procedure (NON-NEGOTIABLE Reference)" section to .aiox-core/development/agents/devops.md but `npm run sync:ide` was not run before that PR merged, leaving the four IDE projections drifted from source: - .claude/skills/AIOX/agents/devops/SKILL.md - .codex/agents/devops.md - .gemini/rules/AIOX/agents/devops.md - .kimi/skills/aiox-devops/SKILL.md This commit runs `sync:ide` and commits the resulting projections. The CI Compatibility Parity Gate + IDE Command Sync Validation + the overall Validation Summary were failing on this branch because they inherit the drifted state from main. This unblocks both #747 (path mismatch) and #746 (internal package.json rebrand). Followup note: the SOP itself should include a step in the post-merge checklist that says "run sync:ide after any change to .aiox-core/development/agents/*.md and commit the resulting projections." Will add to docs/guides/release-procedure.md in a follow-up if it's not already there.
rafaelscosta
added a commit
that referenced
this pull request
May 17, 2026
…jections Mirror of the same sync commit on PR #747. The release-procedure section added to devops.md by PR #745 was not synced to the four IDE projections before #745 merged, so this branch also inherits the drift from main and fails CI's Compatibility Parity Gate. Files: - .claude/skills/AIOX/agents/devops/SKILL.md - .codex/agents/devops.md - .gemini/rules/AIOX/agents/devops.md - .kimi/skills/aiox-devops/SKILL.md
rafaelscosta
dismissed
coderabbitai[bot]’s stale review
May 17, 2026 13:53
Dismissed — both comments target .aiox-core/data/entity-registry.yaml which is auto-regenerated by the IDS-Hook on each commit. The self-entry checksum/lastVerified is recomputed by the same hook on the next push; manual sync there would be immediately overwritten. The component-creation-guide purpose drift predates this PR (it has been wrong in the registry since the hook started inferring purposes from headings) — better tracked as a separate IDS-Hook fix issue rather than blocking the path-mismatch fix that this PR targets. Out of scope for #741.
rafaelscosta
added a commit
that referenced
this pull request
May 17, 2026
…ate (#739 Bug 2) (#746) * fix: rebrand internal .aiox-core/package.json + add namespace drift gate Closes the Bug 2 follow-up from #739 (@gabrielolio): the internal `.aiox-core/package.json` manifest still declared the legacy `@aiox-fullstack/core@4.31.1` namespace while the surface package moved to `@aiox-squads/core@5.x` long ago. The drift went undetected because no pre-publish check was looking at this internal file, and it ships inside every release of `@aiox-squads/core`. ## Changes to `.aiox-core/package.json` Renamed and clarified its role: * `name`: `@aiox-fullstack/core` → `@aiox-squads/core-internal` (the `-internal` suffix + `private: true` make it explicit this is NOT a separately-published package — it ships inside the parent surface) * `version`: `4.31.1` → `5.2.6` (now tracks parent surface) * `private: true` added (defensively prevents accidental separate publish in case someone runs `npm publish` from `.aiox-core/`) * `description` rewritten to explain the file's actual role * Dropped `peerDependencies` block — all four `@aiox-fullstack/*` peers referenced packages that never made the namespace migration and do not exist on npm * Dropped publish-only fields that don't apply to an internal manifest: `module`, `types`, `bin`, `files`, `exports`, `publishConfig` * Repository directory hint added so anyone inspecting the file knows the SOT location * Retained the runtime `dependencies` block (consumed by scripts under `.aiox-core/development/scripts/` — validated by `scripts/validate-aiox-core-deps.js`) ## New pre-publish gate `scripts/validate-aiox-core-namespace.js` enforces five rules: 1. `.aiox-core/package.json` exists 2. `name` ends with `-internal` (forbids drifting back to a published namespace) 3. `private: true` 4. `version` matches root `package.json` version exactly (single source of truth — root drives the framework version) 5. No `@aiox-fullstack/*` peer deps re-introduced The validator is wired into `validate:publish` (which `prepublishOnly` chains), so a release that drifts again is blocked before it ships. Also exposed as `npm run validate:aiox-core-namespace` for ad-hoc runs. ## Why the `-internal` suffix instead of just using `@aiox-squads/core` Two packages with the same name on the same npm registry — even if one is `private: true` — confuses tooling that resolves by name (the installer itself, lockfile resolution, dependency graphs, `npm ls` output). The suffix is a defensive disambiguation: the internal file ships inside the parent surface but never appears in dependency graphs as a competing entry. ## Impact on existing installs Running `aiox install --update` (or any flow that calls `applyUpgrade(..., { includeModified: true })`) will pull the corrected file from the next release. Students who hit the namespace drift before this lands can also hand-patch `.aiox-core/package.json` locally — the file is not load-bearing for runtime; it informs tooling and the operator-facing `aiox info` chain. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix: address CodeRabbit feedback on PR #746 + sync install-manifest Three real issues caught: 1. **execFileSync over execSync (nitpick)** — Replaced shell-based `execSync('node "${path}"', ...)` with `execFileSync('node', [path], ...)` for the two validator invocations in `validate-publish.js`. Eliminates shell parsing entirely, defense-in-depth even though the paths are hardcoded. 2. **Fail-closed for missing namespace validator (actionable)** — The previous code SKIP'd silently if `validate-aiox-core-namespace.js` was missing. That's the exact silent-fall pattern that allowed the namespace drift to ship for several releases. Now an absent validator fails the publish gate with a clear message that the file is required and was introduced specifically for Issue #739 Bug 2. Trying to ship without the gate is now blocked. 3. **Scope check in namespace validator (actionable)** — The `-internal` suffix alone allowed names like `@any-scope/foo-internal` to pass. Added a `startsWith('@aiox-squads/')` check before the suffix check, with a message that calls out `@aiox-fullstack/*` as the legacy scope to reject. Now both conditions must hold: `@aiox-squads/<X>-internal`. Also: regenerated `.aiox-core/install-manifest.yaml` — the new validator script + the modified `validate-publish.js` changed hash, and `validate:manifest` was failing in CI because the manifest was stale relative to the working tree. After regen, manifest validation passes. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * chore(sync): propagate devops.md release-procedure section to IDE projections Mirror of the same sync commit on PR #747. The release-procedure section added to devops.md by PR #745 was not synced to the four IDE projections before #745 merged, so this branch also inherits the drift from main and fails CI's Compatibility Parity Gate. Files: - .claude/skills/AIOX/agents/devops/SKILL.md - .codex/agents/devops.md - .gemini/rules/AIOX/agents/devops.md - .kimi/skills/aiox-devops/SKILL.md --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…nifest conflict by regen)
5 tasks
rafaelscosta
added a commit
that referenced
this pull request
May 17, 2026
The previous suite had a test "extracts from description field" that fed a bare `description: ...` string and expected it to be matched. That was exactly the body-level fallback regex that produced the "Analyzes provided dataset" false purpose on component-creation-guide.md (reported by CodeRabbit on PR #747). The refactor in this PR intentionally removed that match, so the test must be updated to reflect the new contract. Changes to the test file: * Replaced "extracts from description field" with two replacement tests: - "extracts from YAML frontmatter `description:` field" — feeds a `---\ndescription: X\n---` block and expects extraction from it. - "handles quoted YAML frontmatter description" — feeds `description: "X"` inside frontmatter and expects the quotes to be stripped. * Added "falls back to ## Overview when no Purpose section" — covers the new strategy 3 in the priority chain (many guides like component-creation-guide.md use Overview instead of Purpose). * Added TWO regression tests for the bug that motivated the refactor: - "does NOT match body-level `description:` outside frontmatter" — reproduces the exact component-creation-guide pattern (Overview section + a fenced code block with `Task description:` inside) and asserts the Overview wins. - "does NOT extract from `description:` lines without YAML frontmatter delimiters" — bare `description: X` without `---` delimiters falls through to the `# Title` header, NOT to the body line. Test result: 79/79 pass. Existing 5 tests in the suite still pass. Two new tests cover the YAML frontmatter branch (priority 1) and the new `## Overview` branch (priority 3). Two regression tests lock in the removal of the body-level matcher so it can't silently come back.
rafaelscosta
added a commit
that referenced
this pull request
May 17, 2026
* fix(ids): scope purpose inference + sync self-entry on regen Closes the cosmetic follow-up noted after PR #747 — CodeRabbit's "Outside diff range" comments about entity-registry self-entry drift and the `component-creation-guide` purpose field reading "Analyzes provided dataset to identify patterns and insights" (clearly unrelated to a component creation guide). ## Bug 1: purpose inference matched body text it shouldn't have `extractPurpose()` in `populate-entity-registry.js` had a fallback regex: ```js const descMatch = content.match(/(?:description|purpose|summary)[:]\s*(.+)/i); ``` This is case-insensitive and unanchored — it matched ANY occurrence in the file body, including example output inside installer transcripts and fenced code blocks. For `component-creation-guide.md`, it picked up line 132: ``` ? Task description: Analyzes provided dataset to identify patterns and insights ``` …which is example output showing what a user might type, not a description of the guide itself. Fix: restructured `extractPurpose()` to a stricter priority chain: 1. **YAML frontmatter** — `description:` (or aliases) inside the `---` block at the top of the file. Anchored to the frontmatter region so body matches can't leak in. 2. **`## Purpose` section** — first non-empty line. 3. **`## Overview` section** — same shape as Purpose. Many guides use Overview instead (e.g. component-creation-guide.md itself). 4. **First `# Title` heading** — the document's name. 5. **Generic fallback** — `Entity at <path>`. The previous body-level `(?:description|purpose|summary)[:]` regex was REMOVED deliberately. Its false-positive rate (matching example output, installer transcripts, code block content) outweighed the narrow legitimate case it covered, which is now handled by the frontmatter branch. ## Bug 2: self-entry drift in `entities.data.entity-registry` The registry contains a record for itself because the data layer scan picks up every `.yaml`. That record's `lastVerified` was stuck at whatever value the previous scan happened to write, and the `checksum` was likewise stale relative to the regenerated file. Fix: added `syncSelfRegistryEntry()` which runs after the registry object is assembled but before yaml.dump. It: - Sets `lastVerified` to the same `lastUpdated` timestamp written into `metadata.lastUpdated` (single source of truth for this regen event). - Sets `checksum` to a sentinel value `sha256:<self-reference>` because hashing the registry from inside the registry is circular — any computed hash invalidates itself the moment it's written. The sentinel signals "skip this comparison" to downstream validators; trying to compute a "real" hash here would just produce a number that doesn't match its own input. The sync is guarded: it only fires when the self-entry's `path` field is `.aiox-core/data/entity-registry.yaml`. The companion `entity-registry.js` module under `entities.modules.*` is NOT self-referential and is left alone. ## Validation Regenerated the registry on this branch. After the fix: - `grep -c "Analyzes provided dataset" .aiox-core/data/entity-registry.yaml` → `0` - `grep -c "Add MCP Server Task" .aiox-core/data/entity-registry.yaml` → `0` (was the wrong purpose on the yaml self-entry) - The yaml self-entry's `lastVerified` now matches `metadata.lastUpdated` exactly - The yaml self-entry's `checksum` is the sentinel as expected The `component-creation-guide` entity is no longer in the registry at all — the file lives under `.aiox-core/core/docs/` which is not in `SCAN_CONFIG` (the `modules` scan covers `.aiox-core/core` but only for `*.js`/`*.mjs`, not `*.md`). Its previous presence was an artifact of a prior scan run with broader config; this regen cleans it up. If we want to start tracking framework docs as entities, that's a separate concern handled in a follow-up to SCAN_CONFIG. ## Out of scope for this commit A second-order cleanup that this PR does NOT do: there are still some purposes in the registry that look like leaked template placeholders (`'{Brief description of what this task does...}'`, `'{{TASK_TITLE}}'`, `'*${taskName.replace(...)}'`). Those come from files whose own bodies contain unfilled handlebars or JS literals — the inference is technically working, the source is the problem. Separate from this fix. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(ids): align extractPurpose tests with refactored priority chain The previous suite had a test "extracts from description field" that fed a bare `description: ...` string and expected it to be matched. That was exactly the body-level fallback regex that produced the "Analyzes provided dataset" false purpose on component-creation-guide.md (reported by CodeRabbit on PR #747). The refactor in this PR intentionally removed that match, so the test must be updated to reflect the new contract. Changes to the test file: * Replaced "extracts from description field" with two replacement tests: - "extracts from YAML frontmatter `description:` field" — feeds a `---\ndescription: X\n---` block and expects extraction from it. - "handles quoted YAML frontmatter description" — feeds `description: "X"` inside frontmatter and expects the quotes to be stripped. * Added "falls back to ## Overview when no Purpose section" — covers the new strategy 3 in the priority chain (many guides like component-creation-guide.md use Overview instead of Purpose). * Added TWO regression tests for the bug that motivated the refactor: - "does NOT match body-level `description:` outside frontmatter" — reproduces the exact component-creation-guide pattern (Overview section + a fenced code block with `Task description:` inside) and asserts the Overview wins. - "does NOT extract from `description:` lines without YAML frontmatter delimiters" — bare `description: X` without `---` delimiters falls through to the `# Title` header, NOT to the body line. Test result: 79/79 pass. Existing 5 tests in the suite still pass. Two new tests cover the YAML frontmatter branch (priority 1) and the new `## Overview` branch (priority 3). Two regression tests lock in the removal of the body-level matcher so it can't silently come back. --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
rafaelscosta
added a commit
that referenced
this pull request
May 17, 2026
…#749) * fix(ids): scope purpose inference + sync self-entry on regen Closes the cosmetic follow-up noted after PR #747 — CodeRabbit's "Outside diff range" comments about entity-registry self-entry drift and the `component-creation-guide` purpose field reading "Analyzes provided dataset to identify patterns and insights" (clearly unrelated to a component creation guide). ## Bug 1: purpose inference matched body text it shouldn't have `extractPurpose()` in `populate-entity-registry.js` had a fallback regex: ```js const descMatch = content.match(/(?:description|purpose|summary)[:]\s*(.+)/i); ``` This is case-insensitive and unanchored — it matched ANY occurrence in the file body, including example output inside installer transcripts and fenced code blocks. For `component-creation-guide.md`, it picked up line 132: ``` ? Task description: Analyzes provided dataset to identify patterns and insights ``` …which is example output showing what a user might type, not a description of the guide itself. Fix: restructured `extractPurpose()` to a stricter priority chain: 1. **YAML frontmatter** — `description:` (or aliases) inside the `---` block at the top of the file. Anchored to the frontmatter region so body matches can't leak in. 2. **`## Purpose` section** — first non-empty line. 3. **`## Overview` section** — same shape as Purpose. Many guides use Overview instead (e.g. component-creation-guide.md itself). 4. **First `# Title` heading** — the document's name. 5. **Generic fallback** — `Entity at <path>`. The previous body-level `(?:description|purpose|summary)[:]` regex was REMOVED deliberately. Its false-positive rate (matching example output, installer transcripts, code block content) outweighed the narrow legitimate case it covered, which is now handled by the frontmatter branch. ## Bug 2: self-entry drift in `entities.data.entity-registry` The registry contains a record for itself because the data layer scan picks up every `.yaml`. That record's `lastVerified` was stuck at whatever value the previous scan happened to write, and the `checksum` was likewise stale relative to the regenerated file. Fix: added `syncSelfRegistryEntry()` which runs after the registry object is assembled but before yaml.dump. It: - Sets `lastVerified` to the same `lastUpdated` timestamp written into `metadata.lastUpdated` (single source of truth for this regen event). - Sets `checksum` to a sentinel value `sha256:<self-reference>` because hashing the registry from inside the registry is circular — any computed hash invalidates itself the moment it's written. The sentinel signals "skip this comparison" to downstream validators; trying to compute a "real" hash here would just produce a number that doesn't match its own input. The sync is guarded: it only fires when the self-entry's `path` field is `.aiox-core/data/entity-registry.yaml`. The companion `entity-registry.js` module under `entities.modules.*` is NOT self-referential and is left alone. ## Validation Regenerated the registry on this branch. After the fix: - `grep -c "Analyzes provided dataset" .aiox-core/data/entity-registry.yaml` → `0` - `grep -c "Add MCP Server Task" .aiox-core/data/entity-registry.yaml` → `0` (was the wrong purpose on the yaml self-entry) - The yaml self-entry's `lastVerified` now matches `metadata.lastUpdated` exactly - The yaml self-entry's `checksum` is the sentinel as expected The `component-creation-guide` entity is no longer in the registry at all — the file lives under `.aiox-core/core/docs/` which is not in `SCAN_CONFIG` (the `modules` scan covers `.aiox-core/core` but only for `*.js`/`*.mjs`, not `*.md`). Its previous presence was an artifact of a prior scan run with broader config; this regen cleans it up. If we want to start tracking framework docs as entities, that's a separate concern handled in a follow-up to SCAN_CONFIG. ## Out of scope for this commit A second-order cleanup that this PR does NOT do: there are still some purposes in the registry that look like leaked template placeholders (`'{Brief description of what this task does...}'`, `'{{TASK_TITLE}}'`, `'*${taskName.replace(...)}'`). Those come from files whose own bodies contain unfilled handlebars or JS literals — the inference is technically working, the source is the problem. Separate from this fix. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(ids): align extractPurpose tests with refactored priority chain The previous suite had a test "extracts from description field" that fed a bare `description: ...` string and expected it to be matched. That was exactly the body-level fallback regex that produced the "Analyzes provided dataset" false purpose on component-creation-guide.md (reported by CodeRabbit on PR #747). The refactor in this PR intentionally removed that match, so the test must be updated to reflect the new contract. Changes to the test file: * Replaced "extracts from description field" with two replacement tests: - "extracts from YAML frontmatter `description:` field" — feeds a `---\ndescription: X\n---` block and expects extraction from it. - "handles quoted YAML frontmatter description" — feeds `description: "X"` inside frontmatter and expects the quotes to be stripped. * Added "falls back to ## Overview when no Purpose section" — covers the new strategy 3 in the priority chain (many guides like component-creation-guide.md use Overview instead of Purpose). * Added TWO regression tests for the bug that motivated the refactor: - "does NOT match body-level `description:` outside frontmatter" — reproduces the exact component-creation-guide pattern (Overview section + a fenced code block with `Task description:` inside) and asserts the Overview wins. - "does NOT extract from `description:` lines without YAML frontmatter delimiters" — bare `description: X` without `---` delimiters falls through to the `# Title` header, NOT to the body line. Test result: 79/79 pass. Existing 5 tests in the suite still pass. Two new tests cover the YAML frontmatter branch (priority 1) and the new `## Overview` branch (priority 3). Two regression tests lock in the removal of the body-level matcher so it can't silently come back. * fix(ids): skip unfilled placeholders in extractPurpose priority chain Follow-up to PR #748. With body-level matching gone, the priority chain still picked up garbage purposes from files that have literal unfilled template placeholders or JS interpolation in the SOURCES the chain reads: YAML frontmatter, `## Purpose` sections, `# Title` headings. The extractor was technically working — the source data was just full of `{Brief description...}`, `{{TASK_TITLE}}`, and `${context.componentName}` strings that nobody ever filled in. ## What this PR does Adds `looksLikePlaceholder(candidate)` that detects: 1. Whole-string single placeholder: `{Brief...}`, `{{var}}`, `${ctx.x}` 2. Leading-token placeholder: `*${name}foo`, `${ctx.x} bar`, `{Title} extra` 3. Dominant interpolation (>30% of string): catches `${icon} @${id} — ${name}${archetype !== 'Specialist' ? ` (${archetype})` : ''} | ${title}` where most of the string is `${}` blocks The detector is conservative on real prose: - `Manage feature flags with { enabled: true } syntax` → keeps - `Use this skill when... ${variable not present}` (<30% interpolation) → keeps - Empty / whitespace / nullish → keeps (caller handles) Wired into all four `extractPurpose` strategies (frontmatter, `## Purpose`, `## Overview`, `# Title`). When a strategy produces a placeholder, it falls through to the next strategy. When all four produce placeholders, the function returns the generic `Entity at <path>` fallback rather than a nonsense purpose. ## Validation Counted placeholders in `.aiox-core/data/entity-registry.yaml` before and after this PR: ``` $ grep -E "purpose: ['\"]?\{[A-Z]|purpose:.*\{\{|purpose:.*\\\$\\{" \ .aiox-core/data/entity-registry.yaml | wc -l # Before: 16 # After: 0 ``` Examples of entries that now have sensible purposes (or sensible generic fallbacks) instead of unfilled templates: - `*${taskName.replace(/-/g, '-')}` → now resolves via header or falls to `Entity at <path>` - `{Brief description of what this task does and when to use it}` → now falls through to the next strategy - `Generated: ${new Date().toISOString()}` → captured by dominant- interpolation heuristic and skipped - `${icon} @${id} — ${name}${archetype !== ...}` → captured by dominant-interpolation heuristic and skipped ## Tests 12 new tests added to `tests/core/ids/populate-entity-registry.test.js`: - 4 cover `extractPurpose` falling through placeholders at each strategy boundary - 8 cover `looksLikePlaceholder` directly (positive cases for each pattern + negative cases for normal prose that should NOT trip it) Suite: 91/91 pass (was 79/79 on PR #748). ## Why not just fix the source files? The placeholders live in templates and generators — they're SUPPOSED to be unfilled when stored in the framework. They get filled at use- time when the template instantiates an output. The registry's inference is reading the template body as if it were a finished doc, which is the actual bug. Fixing the inference (this PR) is correct; trying to fill the templates would break their template-ness. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(ids): add 5 regression tests for syncSelfRegistryEntry Addresses CodeRabbit feedback on PR #749 — the self-entry sync logic introduced in PR #748 was load-bearing (lastVerified + checksum drift was the original CodeRabbit complaint) but lacked targeted tests. Tests added cover the four invariants: 1. **Self-path match → mutates both fields**: when the entry's path equals `.aiox-core/data/entity-registry.yaml`, `lastVerified` becomes the new timestamp and `checksum` becomes the sentinel. 2. **Non-self path → no mutation**: the companion entry pointing at `.aiox-core/core/doctor/checks/entity-registry.js` (a real JS module, NOT self-referential) must NOT be touched. Catches the most likely regression: if the path guard is removed, the JS module entry would get clobbered with the yaml sentinel. 3. **Missing entities.data** is a no-op (defensive). 4. **Missing self-entry** is a no-op + leaves other data entries alone (defensive). 5. **Malformed registry** (`{}`, `null`) does not throw. Required exporting `syncSelfRegistryEntry` from the script's `module.exports` and consuming it in the test file. Suite: 96/96 pass (was 91/91). --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
10 tasks
rafaelscosta
added a commit
that referenced
this pull request
May 18, 2026
* chore(release): bump to 5.2.7 — consolidate PRs #744-#750 from 5.2.6 Consolidates 7 PRs merged after the 5.2.6 release. None of them required an immediate hotfix on their own, but together they unblock cohort students from a real CI/CD failure mode (#739 Bug 1) and remove three sources of registry drift. ## What ships in 5.2.7 - **#744** (66b302a) — Pipeline hardening: `publish_legacy_aiox_core` race fix, smoke timeout 90s→240s with dual visibility check, structured notify summary, Windows path escape fix via WORKSPACE_DIR env var. Plus the canonical `docs/guides/release-procedure.md` SOP. - **#745** (342ef63) — Ecosystem alignment: `installation-troubleshooting.md` Issue 10 (install-side recovery for the npm-hijack symptom), aiox-pro-access.md link, slim wrappers for publish-npm.md/release-management.md tasks pointing at the SOP, devops.md Release Procedure section. - **#746** (ef7a352) — Internal `.aiox-core/package.json` rebranded `@aiox-fullstack/core@4.31.1` → `@aiox-squads/core-internal@5.2.7` (private, no phantom peerDeps). New `scripts/validate-aiox-core-namespace.js` (5-rule gate) wired into `validate:publish`. Closes #739 Bug 2. - **#747** (e5cd355) — 70 substitutions across 17 files realigning legacy `aiox-core/{templates,checklists,agents,tasks,workflows,agent-teams}/<X>` references to current `.aiox-core/...` layout. Unblocks `@po *validate-story-draft`. Closes #741. - **#748** (1f97f6f) — IDS `extractPurpose()` rewritten as strict priority chain (frontmatter → ## Purpose → ## Overview → # Title → fallback). Removed body-level regex that picked up example transcripts as purposes. New `syncSelfRegistryEntry()` writes sentinel `sha256:<self-reference>` checksum for the registry's own record. - **#749** (70fa5e2) — `looksLikePlaceholder()` filter excludes 16 garbage purposes (`{Brief...}`, `{{TASK_TITLE}}`, `${context.componentName}`). - **#750** (21782cc) — Installer honors `--ci` / `--yes` / `--skipPrompts` flags at the CLAUDE.md merge prompt. Non-interactive runs no longer block waiting for keyboard input. Closes #739 Bug 1. ## Version sites bumped (5 — up from 4 in the previous SOP) - `package.json` (root): 5.2.6 → 5.2.7 - `compat/aiox-core/package.json`: version + dep["@aiox-squads/core"] 5.2.6 → 5.2.7 - `packages/installer/package.json`: 3.3.5 → 3.3.6 (#750 touched installer src) - `.aiox-core/package.json` (internal): 5.2.6 → 5.2.7 (validate-aiox-core-namespace enforces lockstep with root — new in 5.2.7, first release under the gate) - `package-lock.json` refresh - `CHANGELOG.md`: new [5.2.7] entry - `docs/guides/release-procedure.md`: bump the "4 sites" rule to "5 sites" reflecting the validate-aiox-core-namespace gate added in PR #746 ## Validation - `npm run lint` → exit 0 - `npm run test:ci` → 8510 passed (151 skipped), 344/355 suites, 229s - `npx jest tests/installer/ --no-coverage` → 276/276 pass - `npm run validate:publish` → PASS (12911 files; namespace sync verified) Pro install hijack fix (#742) shipped in 5.2.6 and remains in production — this release does not re-iterate it. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs: address CodeRabbit nitpick on release-procedure.md lockstep wording PR #751 CodeRabbit review flagged that the "Bump all five version sites in lockstep" wording was ambiguous — the table below explicitly treats `packages/installer/package.json` as conditional ("patch bump if installer changed; otherwise leave"). Operators reading only line 36 could over-bump the installer. Reworded to distinguish: - Root + internal manifest + compat: MUST stay in lockstep at same version - packages/installer: bumped ONLY when installer source changed (not every release) Also explicit on the two failure-mode detection layers: - Smoke tests (catch silent publish mismatches) - validate-aiox-core-namespace.js wired into validate:publish (rule 4 enforces lockstep) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
tuanmedeiros
pushed a commit
to tuanmedeiros/aios-core-synkraay
that referenced
this pull request
Jun 2, 2026
…ate (SynkraAI#739 Bug 2) (SynkraAI#746) * fix: rebrand internal .aiox-core/package.json + add namespace drift gate Closes the Bug 2 follow-up from SynkraAI#739 (@gabrielolio): the internal `.aiox-core/package.json` manifest still declared the legacy `@aiox-fullstack/core@4.31.1` namespace while the surface package moved to `@aiox-squads/core@5.x` long ago. The drift went undetected because no pre-publish check was looking at this internal file, and it ships inside every release of `@aiox-squads/core`. ## Changes to `.aiox-core/package.json` Renamed and clarified its role: * `name`: `@aiox-fullstack/core` → `@aiox-squads/core-internal` (the `-internal` suffix + `private: true` make it explicit this is NOT a separately-published package — it ships inside the parent surface) * `version`: `4.31.1` → `5.2.6` (now tracks parent surface) * `private: true` added (defensively prevents accidental separate publish in case someone runs `npm publish` from `.aiox-core/`) * `description` rewritten to explain the file's actual role * Dropped `peerDependencies` block — all four `@aiox-fullstack/*` peers referenced packages that never made the namespace migration and do not exist on npm * Dropped publish-only fields that don't apply to an internal manifest: `module`, `types`, `bin`, `files`, `exports`, `publishConfig` * Repository directory hint added so anyone inspecting the file knows the SOT location * Retained the runtime `dependencies` block (consumed by scripts under `.aiox-core/development/scripts/` — validated by `scripts/validate-aiox-core-deps.js`) ## New pre-publish gate `scripts/validate-aiox-core-namespace.js` enforces five rules: 1. `.aiox-core/package.json` exists 2. `name` ends with `-internal` (forbids drifting back to a published namespace) 3. `private: true` 4. `version` matches root `package.json` version exactly (single source of truth — root drives the framework version) 5. No `@aiox-fullstack/*` peer deps re-introduced The validator is wired into `validate:publish` (which `prepublishOnly` chains), so a release that drifts again is blocked before it ships. Also exposed as `npm run validate:aiox-core-namespace` for ad-hoc runs. ## Why the `-internal` suffix instead of just using `@aiox-squads/core` Two packages with the same name on the same npm registry — even if one is `private: true` — confuses tooling that resolves by name (the installer itself, lockfile resolution, dependency graphs, `npm ls` output). The suffix is a defensive disambiguation: the internal file ships inside the parent surface but never appears in dependency graphs as a competing entry. ## Impact on existing installs Running `aiox install --update` (or any flow that calls `applyUpgrade(..., { includeModified: true })`) will pull the corrected file from the next release. Students who hit the namespace drift before this lands can also hand-patch `.aiox-core/package.json` locally — the file is not load-bearing for runtime; it informs tooling and the operator-facing `aiox info` chain. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix: address CodeRabbit feedback on PR SynkraAI#746 + sync install-manifest Three real issues caught: 1. **execFileSync over execSync (nitpick)** — Replaced shell-based `execSync('node "${path}"', ...)` with `execFileSync('node', [path], ...)` for the two validator invocations in `validate-publish.js`. Eliminates shell parsing entirely, defense-in-depth even though the paths are hardcoded. 2. **Fail-closed for missing namespace validator (actionable)** — The previous code SKIP'd silently if `validate-aiox-core-namespace.js` was missing. That's the exact silent-fall pattern that allowed the namespace drift to ship for several releases. Now an absent validator fails the publish gate with a clear message that the file is required and was introduced specifically for Issue SynkraAI#739 Bug 2. Trying to ship without the gate is now blocked. 3. **Scope check in namespace validator (actionable)** — The `-internal` suffix alone allowed names like `@any-scope/foo-internal` to pass. Added a `startsWith('@aiox-squads/')` check before the suffix check, with a message that calls out `@aiox-fullstack/*` as the legacy scope to reject. Now both conditions must hold: `@aiox-squads/<X>-internal`. Also: regenerated `.aiox-core/install-manifest.yaml` — the new validator script + the modified `validate-publish.js` changed hash, and `validate:manifest` was failing in CI because the manifest was stale relative to the working tree. After regen, manifest validation passes. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * chore(sync): propagate devops.md release-procedure section to IDE projections Mirror of the same sync commit on PR SynkraAI#747. The release-procedure section added to devops.md by PR SynkraAI#745 was not synced to the four IDE projections before SynkraAI#745 merged, so this branch also inherits the drift from main and fails CI's Compatibility Parity Gate. Files: - .claude/skills/AIOX/agents/devops/SKILL.md - .codex/agents/devops.md - .gemini/rules/AIOX/agents/devops.md - .kimi/skills/aiox-devops/SKILL.md --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
tuanmedeiros
pushed a commit
to tuanmedeiros/aios-core-synkraay
that referenced
this pull request
Jun 2, 2026
SynkraAI#741) (SynkraAI#747) * fix: align legacy path references with current directory layout (closes SynkraAI#741) The framework directory layout was reorganized at some point with templates, checklists, tasks, agents, workflows, and agent-teams moving under `.aiox-core/` subdirectories (`product/`, `development/`), but ~70 references across docs, tasks, and the knowledge base never followed. The result: `@po *validate-story-draft` (and other story-flow steps) tries to load template paths like `aiox-core/templates/story-tmpl.yaml` that no longer exist, breaking the Story Development Cycle at the validation gate as reported by @renatolhamas in SynkraAI#741. ## Mapping applied | Legacy path | Current path | |---|---| | `aiox-core/templates/<X>` | `.aiox-core/product/templates/<X>` | | `aiox-core/checklists/<X>` | `.aiox-core/product/checklists/<X>` | | `aiox-core/agents/<X>` | `.aiox-core/development/agents/<X>` | | `aiox-core/tasks/<X>` | `.aiox-core/development/tasks/<X>` | | `aiox-core/workflows/<X>` | `.aiox-core/development/workflows/<X>` | | `aiox-core/agent-teams/<X>` | `.aiox-core/development/agent-teams/<X>` | | `aiox-core/data/<X>` | `.aiox-core/data/<X>` (data did NOT move into a subdir; only the prefix gets the dot) | Note the leading dot: `aiox-core/` → `.aiox-core/`. The post-reorganization codebase already uses the dotted form (`.aiox-core/...`); only the legacy non-dotted references needed updating. A negative-lookbehind `(?<![\.])` in the substitution script protects existing dotted references from being rewritten twice. ## Files touched (17 — one extra came in from the pre-commit hook regenerating `entity-registry.yaml`) - **Runtime-affecting (story flow, agent flow):** - `.aiox-core/development/tasks/validate-next-story.md` (the file @renatolhamas pointed at — Line 228 was the trigger) - `.aiox-core/development/tasks/dev-validate-next-story.md` - `.aiox-core/development/tasks/create-next-story.md` - `.aiox-core/development/tasks/sm-create-next-story.md` - `.aiox-core/development/tasks/modify-agent.md` - `.aiox-core/development/tasks/modify-task.md` - `.aiox-core/development/tasks/architect-analyze-impact.md` - `.aiox-core/development/tasks/pr-automation.md` - **Documentation (operator-facing):** - `.aiox-core/user-guide.md` - `.aiox-core/core/docs/component-creation-guide.md` - `.aiox-core/data/aiox-kb.md` - `docs/core-architecture.md` (+ pt/es/zh localizations) - `docs/guides/agents/traces/ux-design-expert-execution-trace.md` - **Generated (regenerated by pre-commit hook, not authored):** - `.aiox-core/data/entity-registry.yaml` ## Method Substitution was scripted (not freehand `sed`) with a negative-lookbehind guard `(?<![\.])aiox-core/<subdir>/` so already-correct dotted references stay intact. Audit verifies zero remaining matches across `.aiox-core/` and `docs/`: ``` $ grep -rnE "['\\\`\\\"]aiox-core/(templates|tasks|checklists|agents|data|workflows|agent-teams)/" .aiox-core/ docs/ | grep -v "\\.aiox-core" | wc -l 0 ``` ## Out of scope (deferred) Other legacy refs that exist in the codebase but were not part of the reorganization that SynkraAI#741 reports: - `aiox-core/core-config.yaml` (root-level config, not a subdir reorg) - `aiox-core/tools/mcp/clickup.yaml` (only 1 occurrence in aiox-kb.md — needs separate decision on where this should live, will follow up) These are 1-off references that don't break the story flow and need their own decision per ref. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * chore: regenerate install-manifest after path-ref updates The 17 file rewrites in the previous commit changed content hashes that the install-manifest tracks. CI Install Manifest Validation was failing on the stale hash; regenerating brings it back in sync. Also picks up entity-registry refresh from the IDS pre-commit hook. * chore(sync): propagate devops.md release-procedure section to IDE projections PR SynkraAI#745 added a "Release Procedure (NON-NEGOTIABLE Reference)" section to .aiox-core/development/agents/devops.md but `npm run sync:ide` was not run before that PR merged, leaving the four IDE projections drifted from source: - .claude/skills/AIOX/agents/devops/SKILL.md - .codex/agents/devops.md - .gemini/rules/AIOX/agents/devops.md - .kimi/skills/aiox-devops/SKILL.md This commit runs `sync:ide` and commits the resulting projections. The CI Compatibility Parity Gate + IDE Command Sync Validation + the overall Validation Summary were failing on this branch because they inherit the drifted state from main. This unblocks both SynkraAI#747 (path mismatch) and SynkraAI#746 (internal package.json rebrand). Followup note: the SOP itself should include a step in the post-merge checklist that says "run sync:ide after any change to .aiox-core/development/agents/*.md and commit the resulting projections." Will add to docs/guides/release-procedure.md in a follow-up if it's not already there. --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
tuanmedeiros
pushed a commit
to tuanmedeiros/aios-core-synkraay
that referenced
this pull request
Jun 2, 2026
…I#748) * fix(ids): scope purpose inference + sync self-entry on regen Closes the cosmetic follow-up noted after PR SynkraAI#747 — CodeRabbit's "Outside diff range" comments about entity-registry self-entry drift and the `component-creation-guide` purpose field reading "Analyzes provided dataset to identify patterns and insights" (clearly unrelated to a component creation guide). ## Bug 1: purpose inference matched body text it shouldn't have `extractPurpose()` in `populate-entity-registry.js` had a fallback regex: ```js const descMatch = content.match(/(?:description|purpose|summary)[:]\s*(.+)/i); ``` This is case-insensitive and unanchored — it matched ANY occurrence in the file body, including example output inside installer transcripts and fenced code blocks. For `component-creation-guide.md`, it picked up line 132: ``` ? Task description: Analyzes provided dataset to identify patterns and insights ``` …which is example output showing what a user might type, not a description of the guide itself. Fix: restructured `extractPurpose()` to a stricter priority chain: 1. **YAML frontmatter** — `description:` (or aliases) inside the `---` block at the top of the file. Anchored to the frontmatter region so body matches can't leak in. 2. **`## Purpose` section** — first non-empty line. 3. **`## Overview` section** — same shape as Purpose. Many guides use Overview instead (e.g. component-creation-guide.md itself). 4. **First `# Title` heading** — the document's name. 5. **Generic fallback** — `Entity at <path>`. The previous body-level `(?:description|purpose|summary)[:]` regex was REMOVED deliberately. Its false-positive rate (matching example output, installer transcripts, code block content) outweighed the narrow legitimate case it covered, which is now handled by the frontmatter branch. ## Bug 2: self-entry drift in `entities.data.entity-registry` The registry contains a record for itself because the data layer scan picks up every `.yaml`. That record's `lastVerified` was stuck at whatever value the previous scan happened to write, and the `checksum` was likewise stale relative to the regenerated file. Fix: added `syncSelfRegistryEntry()` which runs after the registry object is assembled but before yaml.dump. It: - Sets `lastVerified` to the same `lastUpdated` timestamp written into `metadata.lastUpdated` (single source of truth for this regen event). - Sets `checksum` to a sentinel value `sha256:<self-reference>` because hashing the registry from inside the registry is circular — any computed hash invalidates itself the moment it's written. The sentinel signals "skip this comparison" to downstream validators; trying to compute a "real" hash here would just produce a number that doesn't match its own input. The sync is guarded: it only fires when the self-entry's `path` field is `.aiox-core/data/entity-registry.yaml`. The companion `entity-registry.js` module under `entities.modules.*` is NOT self-referential and is left alone. ## Validation Regenerated the registry on this branch. After the fix: - `grep -c "Analyzes provided dataset" .aiox-core/data/entity-registry.yaml` → `0` - `grep -c "Add MCP Server Task" .aiox-core/data/entity-registry.yaml` → `0` (was the wrong purpose on the yaml self-entry) - The yaml self-entry's `lastVerified` now matches `metadata.lastUpdated` exactly - The yaml self-entry's `checksum` is the sentinel as expected The `component-creation-guide` entity is no longer in the registry at all — the file lives under `.aiox-core/core/docs/` which is not in `SCAN_CONFIG` (the `modules` scan covers `.aiox-core/core` but only for `*.js`/`*.mjs`, not `*.md`). Its previous presence was an artifact of a prior scan run with broader config; this regen cleans it up. If we want to start tracking framework docs as entities, that's a separate concern handled in a follow-up to SCAN_CONFIG. ## Out of scope for this commit A second-order cleanup that this PR does NOT do: there are still some purposes in the registry that look like leaked template placeholders (`'{Brief description of what this task does...}'`, `'{{TASK_TITLE}}'`, `'*${taskName.replace(...)}'`). Those come from files whose own bodies contain unfilled handlebars or JS literals — the inference is technically working, the source is the problem. Separate from this fix. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(ids): align extractPurpose tests with refactored priority chain The previous suite had a test "extracts from description field" that fed a bare `description: ...` string and expected it to be matched. That was exactly the body-level fallback regex that produced the "Analyzes provided dataset" false purpose on component-creation-guide.md (reported by CodeRabbit on PR SynkraAI#747). The refactor in this PR intentionally removed that match, so the test must be updated to reflect the new contract. Changes to the test file: * Replaced "extracts from description field" with two replacement tests: - "extracts from YAML frontmatter `description:` field" — feeds a `---\ndescription: X\n---` block and expects extraction from it. - "handles quoted YAML frontmatter description" — feeds `description: "X"` inside frontmatter and expects the quotes to be stripped. * Added "falls back to ## Overview when no Purpose section" — covers the new strategy 3 in the priority chain (many guides like component-creation-guide.md use Overview instead of Purpose). * Added TWO regression tests for the bug that motivated the refactor: - "does NOT match body-level `description:` outside frontmatter" — reproduces the exact component-creation-guide pattern (Overview section + a fenced code block with `Task description:` inside) and asserts the Overview wins. - "does NOT extract from `description:` lines without YAML frontmatter delimiters" — bare `description: X` without `---` delimiters falls through to the `# Title` header, NOT to the body line. Test result: 79/79 pass. Existing 5 tests in the suite still pass. Two new tests cover the YAML frontmatter branch (priority 1) and the new `## Overview` branch (priority 3). Two regression tests lock in the removal of the body-level matcher so it can't silently come back. --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
tuanmedeiros
pushed a commit
to tuanmedeiros/aios-core-synkraay
that referenced
this pull request
Jun 2, 2026
…SynkraAI#749) * fix(ids): scope purpose inference + sync self-entry on regen Closes the cosmetic follow-up noted after PR SynkraAI#747 — CodeRabbit's "Outside diff range" comments about entity-registry self-entry drift and the `component-creation-guide` purpose field reading "Analyzes provided dataset to identify patterns and insights" (clearly unrelated to a component creation guide). ## Bug 1: purpose inference matched body text it shouldn't have `extractPurpose()` in `populate-entity-registry.js` had a fallback regex: ```js const descMatch = content.match(/(?:description|purpose|summary)[:]\s*(.+)/i); ``` This is case-insensitive and unanchored — it matched ANY occurrence in the file body, including example output inside installer transcripts and fenced code blocks. For `component-creation-guide.md`, it picked up line 132: ``` ? Task description: Analyzes provided dataset to identify patterns and insights ``` …which is example output showing what a user might type, not a description of the guide itself. Fix: restructured `extractPurpose()` to a stricter priority chain: 1. **YAML frontmatter** — `description:` (or aliases) inside the `---` block at the top of the file. Anchored to the frontmatter region so body matches can't leak in. 2. **`## Purpose` section** — first non-empty line. 3. **`## Overview` section** — same shape as Purpose. Many guides use Overview instead (e.g. component-creation-guide.md itself). 4. **First `# Title` heading** — the document's name. 5. **Generic fallback** — `Entity at <path>`. The previous body-level `(?:description|purpose|summary)[:]` regex was REMOVED deliberately. Its false-positive rate (matching example output, installer transcripts, code block content) outweighed the narrow legitimate case it covered, which is now handled by the frontmatter branch. ## Bug 2: self-entry drift in `entities.data.entity-registry` The registry contains a record for itself because the data layer scan picks up every `.yaml`. That record's `lastVerified` was stuck at whatever value the previous scan happened to write, and the `checksum` was likewise stale relative to the regenerated file. Fix: added `syncSelfRegistryEntry()` which runs after the registry object is assembled but before yaml.dump. It: - Sets `lastVerified` to the same `lastUpdated` timestamp written into `metadata.lastUpdated` (single source of truth for this regen event). - Sets `checksum` to a sentinel value `sha256:<self-reference>` because hashing the registry from inside the registry is circular — any computed hash invalidates itself the moment it's written. The sentinel signals "skip this comparison" to downstream validators; trying to compute a "real" hash here would just produce a number that doesn't match its own input. The sync is guarded: it only fires when the self-entry's `path` field is `.aiox-core/data/entity-registry.yaml`. The companion `entity-registry.js` module under `entities.modules.*` is NOT self-referential and is left alone. ## Validation Regenerated the registry on this branch. After the fix: - `grep -c "Analyzes provided dataset" .aiox-core/data/entity-registry.yaml` → `0` - `grep -c "Add MCP Server Task" .aiox-core/data/entity-registry.yaml` → `0` (was the wrong purpose on the yaml self-entry) - The yaml self-entry's `lastVerified` now matches `metadata.lastUpdated` exactly - The yaml self-entry's `checksum` is the sentinel as expected The `component-creation-guide` entity is no longer in the registry at all — the file lives under `.aiox-core/core/docs/` which is not in `SCAN_CONFIG` (the `modules` scan covers `.aiox-core/core` but only for `*.js`/`*.mjs`, not `*.md`). Its previous presence was an artifact of a prior scan run with broader config; this regen cleans it up. If we want to start tracking framework docs as entities, that's a separate concern handled in a follow-up to SCAN_CONFIG. ## Out of scope for this commit A second-order cleanup that this PR does NOT do: there are still some purposes in the registry that look like leaked template placeholders (`'{Brief description of what this task does...}'`, `'{{TASK_TITLE}}'`, `'*${taskName.replace(...)}'`). Those come from files whose own bodies contain unfilled handlebars or JS literals — the inference is technically working, the source is the problem. Separate from this fix. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(ids): align extractPurpose tests with refactored priority chain The previous suite had a test "extracts from description field" that fed a bare `description: ...` string and expected it to be matched. That was exactly the body-level fallback regex that produced the "Analyzes provided dataset" false purpose on component-creation-guide.md (reported by CodeRabbit on PR SynkraAI#747). The refactor in this PR intentionally removed that match, so the test must be updated to reflect the new contract. Changes to the test file: * Replaced "extracts from description field" with two replacement tests: - "extracts from YAML frontmatter `description:` field" — feeds a `---\ndescription: X\n---` block and expects extraction from it. - "handles quoted YAML frontmatter description" — feeds `description: "X"` inside frontmatter and expects the quotes to be stripped. * Added "falls back to ## Overview when no Purpose section" — covers the new strategy 3 in the priority chain (many guides like component-creation-guide.md use Overview instead of Purpose). * Added TWO regression tests for the bug that motivated the refactor: - "does NOT match body-level `description:` outside frontmatter" — reproduces the exact component-creation-guide pattern (Overview section + a fenced code block with `Task description:` inside) and asserts the Overview wins. - "does NOT extract from `description:` lines without YAML frontmatter delimiters" — bare `description: X` without `---` delimiters falls through to the `# Title` header, NOT to the body line. Test result: 79/79 pass. Existing 5 tests in the suite still pass. Two new tests cover the YAML frontmatter branch (priority 1) and the new `## Overview` branch (priority 3). Two regression tests lock in the removal of the body-level matcher so it can't silently come back. * fix(ids): skip unfilled placeholders in extractPurpose priority chain Follow-up to PR SynkraAI#748. With body-level matching gone, the priority chain still picked up garbage purposes from files that have literal unfilled template placeholders or JS interpolation in the SOURCES the chain reads: YAML frontmatter, `## Purpose` sections, `# Title` headings. The extractor was technically working — the source data was just full of `{Brief description...}`, `{{TASK_TITLE}}`, and `${context.componentName}` strings that nobody ever filled in. ## What this PR does Adds `looksLikePlaceholder(candidate)` that detects: 1. Whole-string single placeholder: `{Brief...}`, `{{var}}`, `${ctx.x}` 2. Leading-token placeholder: `*${name}foo`, `${ctx.x} bar`, `{Title} extra` 3. Dominant interpolation (>30% of string): catches `${icon} @${id} — ${name}${archetype !== 'Specialist' ? ` (${archetype})` : ''} | ${title}` where most of the string is `${}` blocks The detector is conservative on real prose: - `Manage feature flags with { enabled: true } syntax` → keeps - `Use this skill when... ${variable not present}` (<30% interpolation) → keeps - Empty / whitespace / nullish → keeps (caller handles) Wired into all four `extractPurpose` strategies (frontmatter, `## Purpose`, `## Overview`, `# Title`). When a strategy produces a placeholder, it falls through to the next strategy. When all four produce placeholders, the function returns the generic `Entity at <path>` fallback rather than a nonsense purpose. ## Validation Counted placeholders in `.aiox-core/data/entity-registry.yaml` before and after this PR: ``` $ grep -E "purpose: ['\"]?\{[A-Z]|purpose:.*\{\{|purpose:.*\\\$\\{" \ .aiox-core/data/entity-registry.yaml | wc -l # Before: 16 # After: 0 ``` Examples of entries that now have sensible purposes (or sensible generic fallbacks) instead of unfilled templates: - `*${taskName.replace(/-/g, '-')}` → now resolves via header or falls to `Entity at <path>` - `{Brief description of what this task does and when to use it}` → now falls through to the next strategy - `Generated: ${new Date().toISOString()}` → captured by dominant- interpolation heuristic and skipped - `${icon} @${id} — ${name}${archetype !== ...}` → captured by dominant-interpolation heuristic and skipped ## Tests 12 new tests added to `tests/core/ids/populate-entity-registry.test.js`: - 4 cover `extractPurpose` falling through placeholders at each strategy boundary - 8 cover `looksLikePlaceholder` directly (positive cases for each pattern + negative cases for normal prose that should NOT trip it) Suite: 91/91 pass (was 79/79 on PR SynkraAI#748). ## Why not just fix the source files? The placeholders live in templates and generators — they're SUPPOSED to be unfilled when stored in the framework. They get filled at use- time when the template instantiates an output. The registry's inference is reading the template body as if it were a finished doc, which is the actual bug. Fixing the inference (this PR) is correct; trying to fill the templates would break their template-ness. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(ids): add 5 regression tests for syncSelfRegistryEntry Addresses CodeRabbit feedback on PR SynkraAI#749 — the self-entry sync logic introduced in PR SynkraAI#748 was load-bearing (lastVerified + checksum drift was the original CodeRabbit complaint) but lacked targeted tests. Tests added cover the four invariants: 1. **Self-path match → mutates both fields**: when the entry's path equals `.aiox-core/data/entity-registry.yaml`, `lastVerified` becomes the new timestamp and `checksum` becomes the sentinel. 2. **Non-self path → no mutation**: the companion entry pointing at `.aiox-core/core/doctor/checks/entity-registry.js` (a real JS module, NOT self-referential) must NOT be touched. Catches the most likely regression: if the path guard is removed, the JS module entry would get clobbered with the yaml sentinel. 3. **Missing entities.data** is a no-op (defensive). 4. **Missing self-entry** is a no-op + leaves other data entries alone (defensive). 5. **Malformed registry** (`{}`, `null`) does not throw. Required exporting `syncSelfRegistryEntry` from the script's `module.exports` and consuming it in the test file. Suite: 96/96 pass (was 91/91). --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
tuanmedeiros
pushed a commit
to tuanmedeiros/aios-core-synkraay
that referenced
this pull request
Jun 2, 2026
…m 5.2.6 (SynkraAI#751) * chore(release): bump to 5.2.7 — consolidate PRs SynkraAI#744-SynkraAI#750 from 5.2.6 Consolidates 7 PRs merged after the 5.2.6 release. None of them required an immediate hotfix on their own, but together they unblock cohort students from a real CI/CD failure mode (SynkraAI#739 Bug 1) and remove three sources of registry drift. ## What ships in 5.2.7 - **SynkraAI#744** (d949918) — Pipeline hardening: `publish_legacy_aiox_core` race fix, smoke timeout 90s→240s with dual visibility check, structured notify summary, Windows path escape fix via WORKSPACE_DIR env var. Plus the canonical `docs/guides/release-procedure.md` SOP. - **SynkraAI#745** (b728a39) — Ecosystem alignment: `installation-troubleshooting.md` Issue 10 (install-side recovery for the npm-hijack symptom), aiox-pro-access.md link, slim wrappers for publish-npm.md/release-management.md tasks pointing at the SOP, devops.md Release Procedure section. - **SynkraAI#746** (dea939e) — Internal `.aiox-core/package.json` rebranded `@aiox-fullstack/core@4.31.1` → `@aiox-squads/core-internal@5.2.7` (private, no phantom peerDeps). New `scripts/validate-aiox-core-namespace.js` (5-rule gate) wired into `validate:publish`. Closes SynkraAI#739 Bug 2. - **SynkraAI#747** (e874103) — 70 substitutions across 17 files realigning legacy `aiox-core/{templates,checklists,agents,tasks,workflows,agent-teams}/<X>` references to current `.aiox-core/...` layout. Unblocks `@po *validate-story-draft`. Closes SynkraAI#741. - **SynkraAI#748** (e8f8761) — IDS `extractPurpose()` rewritten as strict priority chain (frontmatter → ## Purpose → ## Overview → # Title → fallback). Removed body-level regex that picked up example transcripts as purposes. New `syncSelfRegistryEntry()` writes sentinel `sha256:<self-reference>` checksum for the registry's own record. - **SynkraAI#749** (6113083) — `looksLikePlaceholder()` filter excludes 16 garbage purposes (`{Brief...}`, `{{TASK_TITLE}}`, `${context.componentName}`). - **SynkraAI#750** (1d16b51) — Installer honors `--ci` / `--yes` / `--skipPrompts` flags at the CLAUDE.md merge prompt. Non-interactive runs no longer block waiting for keyboard input. Closes SynkraAI#739 Bug 1. ## Version sites bumped (5 — up from 4 in the previous SOP) - `package.json` (root): 5.2.6 → 5.2.7 - `compat/aiox-core/package.json`: version + dep["@aiox-squads/core"] 5.2.6 → 5.2.7 - `packages/installer/package.json`: 3.3.5 → 3.3.6 (SynkraAI#750 touched installer src) - `.aiox-core/package.json` (internal): 5.2.6 → 5.2.7 (validate-aiox-core-namespace enforces lockstep with root — new in 5.2.7, first release under the gate) - `package-lock.json` refresh - `CHANGELOG.md`: new [5.2.7] entry - `docs/guides/release-procedure.md`: bump the "4 sites" rule to "5 sites" reflecting the validate-aiox-core-namespace gate added in PR SynkraAI#746 ## Validation - `npm run lint` → exit 0 - `npm run test:ci` → 8510 passed (151 skipped), 344/355 suites, 229s - `npx jest tests/installer/ --no-coverage` → 276/276 pass - `npm run validate:publish` → PASS (12911 files; namespace sync verified) Pro install hijack fix (SynkraAI#742) shipped in 5.2.6 and remains in production — this release does not re-iterate it. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs: address CodeRabbit nitpick on release-procedure.md lockstep wording PR SynkraAI#751 CodeRabbit review flagged that the "Bump all five version sites in lockstep" wording was ambiguous — the table below explicitly treats `packages/installer/package.json` as conditional ("patch bump if installer changed; otherwise leave"). Operators reading only line 36 could over-bump the installer. Reworded to distinguish: - Root + internal manifest + compat: MUST stay in lockstep at same version - packages/installer: bumped ONLY when installer source changed (not every release) Also explicit on the two failure-mode detection layers: - Smoke tests (catch silent publish mismatches) - validate-aiox-core-namespace.js wired into validate:publish (rule 4 enforces lockstep) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #741 (reported by @renatolhamas).
Problem
The framework directory layout was reorganized at some point with templates, checklists, tasks, agents, workflows, and agent-teams moving under
.aiox-core/subdirectories (product/anddevelopment/), but ~70 references across docs, tasks, and the knowledge base never followed.Concrete impact:
@po *validate-story-draft(and other story-flow steps) tries to load template paths likeaiox-core/templates/story-tmpl.yamlthat no longer exist, breaking the Story Development Cycle at the validation gate. @renatolhamas pinpointed Line 228 of.aiox-core/development/tasks/validate-next-story.mdas the trigger; this PR fixes that line and the other 64 sibling references.Mapping applied
aiox-core/templates/<X>.aiox-core/product/templates/<X>aiox-core/checklists/<X>.aiox-core/product/checklists/<X>aiox-core/agents/<X>.aiox-core/development/agents/<X>aiox-core/tasks/<X>.aiox-core/development/tasks/<X>aiox-core/workflows/<X>.aiox-core/development/workflows/<X>aiox-core/agent-teams/<X>.aiox-core/development/agent-teams/<X>aiox-core/data/<X>.aiox-core/data/<X>(data did NOT move; only the prefix gets the dot)Substitution was scripted with a negative-lookbehind
(?<![\.])so existing dotted references stay intact.Audit (before / after)
Files (17 authored + 1 hook-regenerated)
Runtime-affecting (story/agent flow):
.aiox-core/development/tasks/validate-next-story.md← @renatolhamas's trigger.aiox-core/development/tasks/dev-validate-next-story.md.aiox-core/development/tasks/create-next-story.md.aiox-core/development/tasks/sm-create-next-story.md.aiox-core/development/tasks/modify-agent.md.aiox-core/development/tasks/modify-task.md.aiox-core/development/tasks/architect-analyze-impact.md.aiox-core/development/tasks/pr-automation.mdDocumentation (operator-facing):
.aiox-core/user-guide.md.aiox-core/core/docs/component-creation-guide.md.aiox-core/data/aiox-kb.mddocs/core-architecture.md(+ pt/es/zh localizations)docs/guides/agents/traces/ux-design-expert-execution-trace.mdHook-regenerated (not authored):
.aiox-core/data/entity-registry.yamlOut of scope (deferred)
Two non-reorg legacy refs exist in the codebase but aren't part of #741's reorganization story:
aiox-core/core-config.yaml(root-level config, not a subdir reorg)aiox-core/tools/mcp/clickup.yaml(single occurrence in aiox-kb.md)These need separate per-file decisions and are tracked for a follow-up.
Test plan
grepaudit confirms 0 remaining legacy refs in the targeted subdirsstory-tmpl.yaml,story-draft-checklist.md,dev.md,validate-next-story.md,aiox-kb.md,greenfield-fullstack.yaml)🤖 Generated with Claude Code
Summary by CodeRabbit
Documentation
Chores