feat: Epic NOGIC Code Intelligence + Installation Health + Token Optimization

[Pedrovaleriolopez]

Summary

• Epic NOGIC (Code Intelligence): Full code-intel pipeline — RegistryProvider (native T1), CodeGraphProvider (MCP T3), entity registry, graph dashboard (15 stories), SYNAPSE native-first migration, agent native greetings, hook-runtime
• Epic INS-4 (Installation Health): Doctor rewrite with 15 modular checks, artifact copy pipeline, boundary protection (settings.json deny rules generator), CLAUDE.md template v5, IDE sync, hooks registration, v4.3.0 post-release installer fixes (Story INS-4.11)
• Epic Token Optimization: Unified tool registry (34 tools, 3 tiers), capability-aware deferred loading, PTC batch templates, agent handoff compaction (65% reduction), input examples registry, dynamic filtering engine, tool usage analytics
• Epic Boundary Mapping: L1-L4 layer classification, pre-commit framework guard, permission deny rules, agent memory lifecycle, config schema enrichment
• Open-source audit (AC9): SynapseMemoryProvider moved from pro/ to .aios-core/, feature gate removed

Key Changes

• 66+ files in latest commit (INS-4.11), 80+ commits total on branch
• 12 agent source files migrated to native greeting (zero JS execution)
• IDE command files synced for claude-code, codex, gemini (36 files)
• copyExtraCommandFiles allowlist prevents private content leak
• core-config-template includes boundary section
• Doctor code-intel test rewritten for RegistryProvider compatibility
• 522/522 tests passing

Test plan

• npm test — 522 tests pass (0 failures)
• aios doctor — validates all 15 checks
• QA review by @qa — PASS with documented concerns
• Fresh install E2E validation (deferred to post-publish)
• CodeRabbit automated review on PR

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features

  • Native registry-based code intelligence now chosen by default; hook returns XML-formatted context for assistants.
  • Open-source memory provider enabled; memory retrieval no longer behind a feature gate.
  • Native, zero-JS agent greetings with workflow-driven suggested next steps and handoff consumption.

• Documentation

  • Large additions: architecture, flowcharts, QA gate, and workflow-chains docs.

• Installer

  • Distribution now uses an allowlist to avoid copying private command files.

• Tests

  • Expanded unit and integration test coverage for code-intel, memory, hooks, and workflow chains.

[coderabbitai]

🧹 Nitpick comments (1)

.aios-core/install-manifest.yaml (1)

215-218: Two hook-runtime.js modules now coexist in the manifest — potential developer confusion.

The new core/code-intel/hook-runtime.js (Line 215, 5240 bytes) joins the existing core/synapse/runtime/hook-runtime.js (Line 1163, 3030 bytes). Identical basenames in sibling module trees can cause incorrect imports (e.g., wrong relative path in a require()) that pass a basic test but wire to the wrong implementation at runtime.

Consider a more disambiguating name for the new module, such as code-intel-hook-runtime.js or hook-runtime.js → code-intel-runtime.js.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.aios-core/install-manifest.yaml around lines 215 - 218, Rename the new
module core/code-intel/hook-runtime.js to a disambiguated filename (e.g.,
core/code-intel/code-intel-hook-runtime.js or
core/code-intel/code-intel-runtime.js) and update the install manifest entry for
the new path, its hash, and size accordingly; also search the repo for any
imports/requires referencing core/code-intel/hook-runtime.js and update them to
the new filename so they point to the correct implementation (this prevents
collision with core/synapse/runtime/hook-runtime.js).

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In @.aios-core/install-manifest.yaml:
- Around line 215-218: Rename the new module core/code-intel/hook-runtime.js to
a disambiguated filename (e.g., core/code-intel/code-intel-hook-runtime.js or
core/code-intel/code-intel-runtime.js) and update the install manifest entry for
the new path, its hash, and size accordingly; also search the repo for any
imports/requires referencing core/code-intel/hook-runtime.js and update them to
the new filename so they point to the correct implementation (this prevents
collision with core/synapse/runtime/hook-runtime.js).

---

ℹ️ Review info

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ac62c2b and b2eaa63.

📒 Files selected for processing (1)

• .aios-core/install-manifest.yaml

[coderabbitai]

Actionable comments posted: 10

Note

Due to the large number of review comments, Critical, Major severity comments were prioritized as inline comments.

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (6)

.codex/agents/architect.md (1)

10-33: ⚠️ Potential issue | 🟠 Major

Align handoff lookup with dependency resolution rules.

STEP 3 reads .aios-core/data/workflow-chains.yaml, but dependency resolution constrains files to .aios-core/development/{type}/{name} and the dependencies.data list doesn’t include this file. This is a consistency gap that could break automated resolution or violate the “only load dependency files” rule. Consider adding the file to dependencies and explicitly allowing this read during activation (or move the file under .aios-core/development/data/).

🔧 Possible fix

 dependencies:
   data:
     - technical-preferences.md
+    - workflow-chains.yaml

-  - ONLY load dependency files when user selects them for execution via command or request of a task
+  - ONLY load dependency files when user selects them for execution via command or request of a task,
+    except for activation-time handoff lookup in STEP 3.5

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.codex/agents/architect.md around lines 10 - 33, The activation step (STEP
3) reads `.aios-core/data/workflow-chains.yaml` but the dependency rules
constrain files to `.aios-core/development/{type}/{name}`, causing a resolution
mismatch; fix by either adding `workflow-chains.yaml` to the dependencies list
(e.g., dependencies.data -> workflow-chains.yaml) and updating the
IDE-FILE-RESOLUTION mapping, or move the file into
`.aios-core/development/data/workflow-chains.yaml` and update STEP 3 to read
from that new path; ensure the activation-instructions and REQUEST-RESOLUTION
logic are updated to allow reading this file during activation and maintain the
“only load dependency files” rule.

.claude/commands/AIOS/agents/data-engineer.md (1)

257-258: ⚠️ Potential issue | 🟡 Minor

Stale deprecated command references in usage_tips.

Lines 257–258 reference *rls-audit, *explain, and *analyze-hotpaths — all three were deprecated and consolidated in Story 6.1.2.3 (visible elsewhere in this same file's dependencies section). A user following these tips will hit a no-match path.

# line 257 — current (stale):
'Security audit: `*rls-audit` to check RLS coverage'

# line 258 — current (stale):
'Performance analysis: `*explain SELECT * FROM...` or `*analyze-hotpaths`'

✏️ Proposed fix

-    - 'Security audit: `*rls-audit` to check RLS coverage'
-    - 'Performance analysis: `*explain SELECT * FROM...` or `*analyze-hotpaths`'
+    - 'Security audit: `*security-audit rls` to check RLS coverage'
+    - 'Performance analysis: `*analyze-performance query` or `*analyze-performance hotpaths`'

The same stale *rls-audit reference also appears in the Typical Workflow guide at line 474 and should be updated to *security-audit rls there as well.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.claude/commands/AIOS/agents/data-engineer.md around lines 257 - 258, Update
the stale command references in the usage_tips and Typical Workflow sections:
replace the deprecated '*rls-audit' token with the new '*security-audit rls'
token, and remove the deprecated '*explain' and '*analyze-hotpaths' tokens and
replace them with the consolidated performance-analysis command introduced in
Story 6.1.2.3 (use the exact consolidated token shown in the file's dependencies
section), ensuring you update the occurrences in usage_tips and the Typical
Workflow guide where '*rls-audit' appears.

.codex/agents/sm.md (1)

226-230: ⚠️ Potential issue | 🟡 Minor

@devops in the Handoff Protocol table should be @github-devops

Every other reference in this file (lines 58, 103–130, 209, 215) consistently uses @github-devops. The Handoff Protocol table breaks that consistency, which could confuse a user or a downstream agent trying to route a delegation.

✏️ Proposed fix

-| Push to remote | `@devops` | `*push` |
-| Create PR | `@devops` | `*create-pr` |
+| Push to remote | `@github-devops` | `*push` |
+| Create PR | `@github-devops` | `*create-pr` |

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.codex/agents/sm.md around lines 226 - 230, Replace the inconsistent
delegate handle "@devops" in the Handoff Protocol markdown table with
"@github-devops" so it matches other references; specifically update the two
table cells currently containing "@devops" in the rows for "Push to remote"
(`*push`) and "Create PR" (`*create-pr`) to "@github-devops".

.aios-core/development/tasks/architect-analyze-impact.md (3)

604-612: ⚠️ Potential issue | 🟠 Major

handleHighRiskApproval only audits approvals, contradicting the new security bullet at line 827

Line 827 states that all high-risk modification attempts must be logged. However, approvalWorkflow.logApproval is only called inside the if (approved) branch — rejections are silently dropped, leaving a gap in the audit trail.

🔒 Proposed fix: log rejections too

     if (approved) {
       await this.approvalWorkflow.logApproval(report, {
         approvedBy: 'user',
         approvalTimestamp: new Date().toISOString(),
         riskLevel: report.summary.overallRisk
       });
+    } else {
+      await this.approvalWorkflow.logApproval(report, {
+        approvedBy: 'user',
+        approvalTimestamp: new Date().toISOString(),
+        riskLevel: report.summary.overallRisk,
+        decision: 'rejected'
+      });
     }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.aios-core/development/tasks/architect-analyze-impact.md around lines 604 -
612, The current code only calls approvalWorkflow.logApproval inside the if
(approved) branch, so rejected high-risk modification attempts are not audited;
update handleHighRiskApproval to always call approvalWorkflow.logApproval (or a
similar audit method) for both outcomes by moving the log call out of the if
block and include outcome metadata (e.g., approved: true/false), rejectionReason
or decisionReason, approvedBy, approvalTimestamp, and riskLevel using the
existing report and approved variables so every high-risk attempt is recorded.

---

644-680: ⚠️ Potential issue | 🟠 Major

Unsanitised user-controlled values interpolated directly into HTML output

report.targetComponent.path, comp.path, comp.reason, rec.title, and rec.description all originate from user-supplied CLI arguments. Interpolating them verbatim into the generated HTML (e.g., lines 648, 659, 666–669, 675–677) creates a stored XSS vector in the saved report file. A path like "><script>alert(1)</script> would execute when the report is opened in a browser.

Add an HTML-escape helper and apply it to every interpolated value:

🛡️ Proposed fix: escape interpolated HTML values

+  escapeHtml(str) {
+    return String(str)
+      .replace(/&/g, '&')
+      .replace(/</g, '&lt;')
+      .replace(/>/g, '&gt;')
+      .replace(/"/g, '&quot;')
+      .replace(/'/g, '&#039;');
+  }
+
   async generateHtmlReport(report) {
+    const e = (v) => this.escapeHtml(v);
     return `<!DOCTYPE html>
 ...
-    <h2>Target: ${report.targetComponent.path}</h2>
+    <h2>Target: ${e(report.targetComponent.path)}</h2>
-    <p><strong>Risk Level:</strong> <span class="risk-${report.summary.overallRisk}">${report.summary.overallRisk.toUpperCase()}</span></p>
+    <p><strong>Risk Level:</strong> <span class="risk-${e(report.summary.overallRisk)}">${e(report.summary.overallRisk.toUpperCase())}</span></p>
     ...
-             <strong>${comp.path}</strong> (Impact: ${comp.impactScore}/10)
-             <br><small>${comp.reason}</small>
+             <strong>${e(comp.path)}</strong> (Impact: ${e(comp.impactScore)}/10)
+             <br><small>${e(comp.reason)}</small>
     ...
-          `<li><strong>${rec.title}</strong><br>${rec.description}</li>`
+          `<li><strong>${e(rec.title)}</strong><br>${e(rec.description)}</li>`

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.aios-core/development/tasks/architect-analyze-impact.md around lines 644 -
680, The HTML generation interpolates unsanitised user input
(report.targetComponent.path, comp.path, comp.reason, rec.title,
rec.description) into a template literal, creating an XSS risk; add a small
HTML-escape helper (e.g., escapeHtml) on the class/module and use it everywhere
those fields are inserted into the returned string (including the risk span and
dependency list/assessment list) and keep using this.getRiskColor only for color
values, not for escaped content, so every occurrence of
report.targetComponent.path, comp.path, comp.reason, rec.title and
rec.description is wrapped with escapeHtml before concatenation.

---

475-479: ⚠️ Potential issue | 🔴 Critical

this.propagationPredictor is always null — guaranteed runtime NPE

this.propagationPredictor is initialised to null at line 256 and its require/constructor is commented out at lines 417–418. Calling .predictPropagation(...) here will throw a TypeError: Cannot read properties of null at runtime, taking down every invocation of this task.

Either restore the initialisation, or guard the call and return a stub result when the predictor is unavailable:

🐛 Proposed fix: guard against null propagationPredictor

   async predictChangePropagation(targetComponent, dependencyImpact, config) {
+    if (!this.propagationPredictor) {
+      // ChangePropagationPredictor archived (Story 3.1.2) — return a safe default
+      return { maxDepth: 0, propagationPaths: [], bottlenecks: [] };
+    }
     return await this.propagationPredictor.predictPropagation(targetComponent, dependencyImpact, {
       depth: config.depth,
       modificationType: config.modificationType
     });
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.aios-core/development/tasks/architect-analyze-impact.md around lines 475 -
479, predictChangePropagation currently calls
this.propagationPredictor.predictPropagation but this.propagationPredictor is
initialized to null (constructor/require commented out), causing a guaranteed
runtime NPE; fix by guarding the call in predictChangePropagation: if
this.propagationPredictor is falsy, return a sensible stub/default propagation
result (or a rejected Promise with a clear error) instead of calling
predictPropagation, otherwise delegate to
this.propagationPredictor.predictPropagation with the existing config mapping;
alternatively restore the propagationPredictor initialization where it was
originally constructed so predictChangePropagation can safely call
predictPropagation.

♻️ Duplicate comments (4)

.gemini/rules/AIOS/agents/ux-design-expert.md (1)

25-41: ⚠️ Potential issue | 🟠 Major

Clarify Step 4 as fallback-only to avoid conflicting activation flows.

Step 3 mandates native greeting with a fallback; Step 4 still unconditionally displays a GreetingBuilder output, which contradicts Step 3. Make Step 4 explicitly fallback-only (or remove it if the fallback is already covered in Step 3).

🔧 Suggested adjustment (native-first, fallback-only)

-  - STEP 4: Display the greeting returned by GreetingBuilder
+  - STEP 4: (Fallback only) Display the greeting returned by GreetingBuilder

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.gemini/rules/AIOS/agents/ux-design-expert.md around lines 25 - 41, The flow
currently runs both the native greeting (STEP 3) and unconditionally displays
GreetingBuilder output (STEP 4), causing conflicting activation; change STEP 4
to run only as a fallback when the native greeting fails or is skipped: update
the logic that calls GreetingBuilder (symbol GreetingBuilder and the fallback
script .aios-core/development/scripts/unified-activation-pipeline.js
ux-design-expert) so it only executes after STEP 3 reports failure or
no-native-output (and remove any unconditional display), and ensure any
handoff-consumed marking in STEP 3 still happens before the fallback is invoked.

.claude/commands/AIOS/agents/ux-design-expert.md (1)

25-42: ⚠️ Potential issue | 🟠 Major

Remove the duplicate greeting step (keep a single source of truth).

STEP 3 already defines the full native greeting output; STEP 4 repeats it, which can cause double greetings or conflicting content. Make STEP 3 the only output source and drop/clarify STEP 4.

✅ Suggested adjustment

-  - STEP 4: Display the greeting returned by GreetingBuilder
-  - STEP 5: HALT and await user input
+  - STEP 4: HALT and await user input

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.claude/commands/AIOS/agents/ux-design-expert.md around lines 25 - 42, The
review notes a duplicated greeting: STEP 3 already specifies the native greeting
and STEP 4 redundantly displays the same output; remove or disable the STEP 4
call to GreetingBuilder so STEP 3 remains the single source of truth. Locate the
greeting logic references (STEP 3, STEP 4, and GreetingBuilder) and either
delete or comment out the STEP 4 display, ensuring fallback to node
.aios-core/development/scripts/unified-activation-pipeline.js ux-design-expert
remains unchanged and that only STEP 3 emits the greeting.

.claude/commands/AIOS/agents/squad-creator.md (1)

35-38: STEP 4 still references the stale GreetingBuilder — all other agents in this PR were updated but squad-creator.md was missed.

Every other agent file in this PR (data-engineer, qa, devops, pm) had STEP 4 updated to Display the greeting assembled in STEP 3. squad-creator.md still says Display the greeting returned by GreetingBuilder, which is the old pipeline path. On the native happy path GreetingBuilder is never invoked, so STEP 4 is either a no-op or produces undefined behavior.

✂️ Proposed fix

-  - STEP 4: Display the greeting returned by GreetingBuilder
+  - STEP 4: Display the greeting assembled in STEP 3

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.claude/commands/AIOS/agents/squad-creator.md around lines 35 - 38, Update
STEP 4 in squad-creator.md to match the other agent docs: replace the stale
phrase "Display the greeting returned by GreetingBuilder" with "Display the
greeting assembled in STEP 3" so the documentation reflects the native pipeline
where GreetingBuilder is not invoked; locate the STEP 4 heading in
.claude/commands/AIOS/agents/squad-creator.md and make the text change to
exactly mirror the other agent files' wording.

.aios-core/development/agents/po.md (1)

21-36: Coding guidelines fully compliant; FALLBACK comment addressed from prior review.

The # FALLBACK: is correctly scoped as a documentation comment inside the STEP 3 block scalar (not an active instruction), consistent with the resolution marked in prior review. No further action needed on the fallback concern.

Same optional STEP 3/STEP 4 refactor note from sm.md applies here — STEP 4 ("Display the greeting assembled in STEP 3") is redundant with the Show: sub-steps in STEP 3 for this agent.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.aios-core/development/agents/po.md around lines 21 - 36, The STEP 4 line
("Display the greeting assembled in STEP 3") is redundant because STEP 3 already
contains explicit "Show:" sub-steps that perform the display; remove or collapse
STEP 4 to avoid duplication. Edit the po agent spec to delete the standalone
"STEP 4: Display the greeting assembled in STEP 3" or merge its intent into STEP
3, ensuring the workflow still ends after the STEP 3 display actions and that
references to STEP 4 are removed (look for the block labeled "STEP 3" and the
trailing "STEP 4" token to update).

🧹 Nitpick comments (8)

.gemini/rules/AIOS/agents/pm.md (2)

75-75: Reconcile STEP 4 with STEP 3.5’s greeting-builder.js reference.

STEP 4 now explicitly uses the STEP 3 native greeting, but STEP 3.5 still says “Continue with normal greeting from greeting-builder.js.” Please align the bob path language with the native greeting path to avoid ambiguity in activation behavior.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.gemini/rules/AIOS/agents/pm.md at line 75, Update the doc so STEP 4 and
STEP 3.5 consistently reference the same greeting source: replace the STEP 3.5
phrase "Continue with normal greeting from greeting-builder.js" (and any "bob
path" mentions) with wording that points to the native greeting assembled in
STEP 3, ensuring both steps explicitly state they use the STEP 3 native
greeting; preserve the greeting-builder.js note only if it is used as an
implementation detail and add a short parenthetical like "(implementation:
greeting-builder.js)" next to the STEP 3/native-greeting references for clarity.

---

35-46: Make handoff artifact consumption atomic to avoid double-use.

STEP 3 instructs marking the latest handoff as consumed, but without an atomic update/move, concurrent readers could both process the same artifact. Consider specifying an atomic rename or lock-based consume step.

Proposed wording tweak

-      5.5. Check `.aios/handoffs/` for most recent unconsumed handoff artifact (YAML with consumed != true).
+      5.5. Check `.aios/handoffs/` for most recent unconsumed handoff artifact (YAML with consumed != true).
            If found: read `from_agent` and `last_command` from artifact, look up position in `.aios-core/data/workflow-chains.yaml` matching from_agent + last_command, and show: "💡 **Suggested:** `*{next_command} {args}`"
            If chain has multiple valid next steps, also show: "Also: `*{alt1}`, `*{alt2}`"
-           Mark artifact as consumed: true.
+           Atomically mark artifact as consumed (e.g., write + fsync, or move to a consumed/ folder) to prevent double-processing.
            If no artifact or no match found: skip this step silently.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.gemini/rules/AIOS/agents/pm.md around lines 35 - 46, Update the handoff
consumption step in the `.aios/rules/AIOS/agents/pm.md` procedure to perform an
atomic consume operation: when checking `.aios/handoffs/` for the most recent
unconsumed artifact, acquire an exclusive lock or rename the artifact file to a
"consuming" temporary name (or write a consumed copy and atomic-rename it)
before reading `from_agent` and `last_command`, then perform the lookup in
`.aios-core/data/workflow-chains.yaml` and create the suggested
`*{next_command}` output, and finally atomically mark the artifact as consumed
(e.g., update consumed=true in-memory and write to a temp file then rename, or
move the file to a consumed/ subdirectory) so no concurrent reader can process
the same artifact twice.

.codex/agents/architect.md (1)

20-36: Avoid duplicate “display greeting” steps.

STEP 3 already instructs to display the greeting; STEP 4 repeats it. Consider changing STEP 3 to “assemble” and STEP 4 to “display,” or remove STEP 4 to avoid ambiguity.

✂️ Simplify the flow

-  - STEP 3: |
-      Display greeting using native context (zero JS execution):
+  - STEP 3: |
+      Assemble greeting using native context (zero JS execution):
...
-  - STEP 4: Display the greeting assembled in STEP 3
+  - STEP 4: Display the greeting assembled in STEP 3

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.codex/agents/architect.md around lines 20 - 36, The document currently
duplicates the greeting output by instructing to both "Display greeting" in STEP
3 and again in STEP 4; change STEP 3 to "Assemble greeting" (build the greeting
and perform checks like handoff lookup/consumption) and leave STEP 4 as the
single "Display the greeting" step, or remove STEP 4 entirely—update the STEP 3
heading text and any verbs in its substeps (e.g., the handoff check, signature,
and fallback) so they refer to assembling/preparing rather than displaying, and
ensure STEP 4 is the sole display action.

.codex/agents/sm.md (1)

280-281: Duplicate --- separator

Two consecutive --- markers with no content between them. One is sufficient.

✏️ Proposed fix

----
 ---

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.codex/agents/sm.md around lines 280 - 281, The markdown contains two
consecutive front-matter or section separators ("---" followed immediately by
another "---") with no content between them; remove the redundant second "---"
so only a single separator remains (search for the duplicated '---' sequence in
.codex/agents/sm.md and delete the extra marker).

.aios-core/development/tasks/architect-analyze-impact.md (1)

495-495: Use slice instead of substr

String.prototype.substr is a legacy feature specified in Annex B of the ECMAScript standard for web compatibility; prefer slice for more portable and recommended code.

♻️ Proposed fix

-      reportId: `impact-${Date.now()}-${Math.random().toString(36).substr(2, 6)}`,
+      reportId: `impact-${Date.now()}-${Math.random().toString(36).slice(2, 8)}`,

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.aios-core/development/tasks/architect-analyze-impact.md at line 495, The
template string that builds reportId uses Math.random().toString(36).substr(2,
6) which relies on legacy substr; change it to
Math.random().toString(36).slice(2, 8) (i.e., replace substr(2, 6) with slice(2,
8)) inside the reportId expression so it uses String.prototype.slice for a
portable, standards-compliant result.

.aios-core/development/tasks/qa-review-story.md (1)

706-714: Handoff section inserted mid-section splits the ClickUp Synchronization block, orphaning the Manual Sync bullet.

The - **Manual Sync**: line at 714 belongs to the ClickUp Synchronization section (starting at line 689). Placing ## Handoff between the "No Action Required" subsection and the "Manual Sync" bullet detaches that bullet from its section in rendered output. Moving the Handoff section to the very end of the document (after line 714) would preserve the ClickUp section's integrity.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.aios-core/development/tasks/qa-review-story.md around lines 706 - 714, The
"## Handoff" block is inserted inside the "ClickUp Synchronization" section and
orphaning the "- **Manual Sync**:" bullet; move the entire "## Handoff" section
(the block starting with "## Handoff" and its YAML/alternatives) to the end of
the document so the "ClickUp Synchronization" section (referenced by its heading
"ClickUp Synchronization") remains contiguous and the "- **Manual Sync**:"
bullet stays inside that section.

.claude/commands/AIOS/agents/pm.md (1)

34-49: LGTM — step 5.5 handoff integration is well-structured; consider clarifying Show vs Compose semantics across STEP 3.

In STEP 3 every sub-step uses imperative Show: language ("Display greeting… 1. Show… 2. Show…"), while STEP 4 re-states "Display the greeting assembled in STEP 3". An LLM reading both directives literally could attempt to emit output twice — once inline as each Show: fires in STEP 3, then again when it reaches STEP 4.

For pm.md specifically, STEP 4's (or resume summary if session detected) conditional gives it meaningful purpose for the Bob flow, so retaining STEP 4 is correct here. The fix is simply to change the sub-step verb from Show: to Include: (or Compose:) to clarify that STEP 3 assembles the greeting and STEP 4 triggers the single display.

♻️ Proposed clarity fix for STEP 3 sub-step verbs

-      1. Show: "{icon} {persona_profile.communication.greeting_levels.archetypal}" + permission badge ...
-      2. Show: "**Role:** {persona.role}"
-      3. Show: "📊 **Project Status:**" as natural language narrative ...
-      4. Show: "**Available Commands:**" — list commands ...
-      5. Show: "Type `*guide` for comprehensive usage instructions."
+      1. Include: "{icon} {persona_profile.communication.greeting_levels.archetypal}" + permission badge ...
+      2. Include: "**Role:** {persona.role}"
+      3. Include: "📊 **Project Status:**" as natural language narrative ...
+      4. Include: "**Available Commands:**" — list commands ...
+      5. Include: "Type `*guide` for comprehensive usage instructions."

This pairs naturally with STEP 4 as the single display trigger.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.claude/commands/AIOS/agents/pm.md around lines 34 - 49, Change the
imperative "Show:" verbs inside STEP 3 of pm.md to a non-emissive assembly verb
(e.g., "Include:" or "Compose:") so STEP 3 assembles the greeting and only STEP
4 triggers the single display; update each sub-step (1–6 and 5.5) under "STEP 3"
to use the new verb and keep STEP 4's existing "Display the greeting assembled
in STEP 3" (or resume summary) as the single emission point to avoid duplicate
output from the LLM.

.aios-core/development/agents/sm.md (1)

20-36: Coding guidelines compliant; Show vs Display verb ambiguity between STEP 3 and STEP 4 (same concern as noted for pm.md).

For the canonical source files under .aios-core/development/agents/, STEP 4 reads purely as "Display the greeting assembled in STEP 3" with no additional conditional. Since STEP 3's sub-steps already use Show: (imperative display language), STEP 4 is strictly redundant here — unlike pm.md where it carries the Bob-mode session conditional. The cleanest fix for non-pm agents is either to drop STEP 4 entirely, or adopt the Include: verb in STEP 3 sub-steps (as noted on pm.md) to clarify assembly vs. display responsibilities.

♻️ Proposed fix — drop redundant STEP 4 for sm (and other non-pm agents)

       # FALLBACK: If native greeting fails, run: node .aios-core/development/scripts/unified-activation-pipeline.js sm
-  - STEP 4: Display the greeting assembled in STEP 3
   - STEP 5: HALT and await user input

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.aios-core/development/agents/sm.md around lines 20 - 36, STEP 4 is
redundant for the sm agent because STEP 3 already uses imperative "Show" display
language; remove the "STEP 4: Display the greeting assembled in STEP 3" line
from .aios-core/development/agents/sm.md and keep STEP 3 as the single
display/assembly block (or if you prefer explicit assembly/display separation,
change STEP 3's "Show:" verbs to "Assemble:"/ "Include:" and keep STEP 4 as the
lone "Display" step) — update references to STEP 3/STEP 4 in the file
accordingly.

---

ℹ️ Review info

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b2eaa63 and 121df5d.

📒 Files selected for processing (75)

• .aios-core/data/workflow-chains.yaml
• .aios-core/development/agents/aios-master.md
• .aios-core/development/agents/analyst.md
• .aios-core/development/agents/architect.md
• .aios-core/development/agents/data-engineer.md
• .aios-core/development/agents/dev.md
• .aios-core/development/agents/devops.md
• .aios-core/development/agents/pm.md
• .aios-core/development/agents/po.md
• .aios-core/development/agents/qa.md
• .aios-core/development/agents/sm.md
• .aios-core/development/agents/squad-creator.md
• .aios-core/development/agents/ux-design-expert.md
• .aios-core/development/tasks/apply-qa-fixes.md
• .aios-core/development/tasks/architect-analyze-impact.md
• .aios-core/development/tasks/brownfield-create-story.md
• .aios-core/development/tasks/build-autonomous.md
• .aios-core/development/tasks/create-deep-research-prompt.md
• .aios-core/development/tasks/create-next-story.md
• .aios-core/development/tasks/create-suite.md
• .aios-core/development/tasks/dev-develop-story.md
• .aios-core/development/tasks/execute-checklist.md
• .aios-core/development/tasks/github-devops-github-pr-automation.md
• .aios-core/development/tasks/github-devops-pre-push-quality-gate.md
• .aios-core/development/tasks/po-close-story.md
• .aios-core/development/tasks/qa-create-fix-request.md
• .aios-core/development/tasks/qa-fix-issues.md
• .aios-core/development/tasks/qa-gate.md
• .aios-core/development/tasks/qa-review-story.md
• .aios-core/development/tasks/release-management.md
• .aios-core/development/tasks/spec-critique.md
• .aios-core/development/tasks/spec-gather-requirements.md
• .aios-core/development/tasks/spec-write-spec.md
• .aios-core/development/tasks/validate-next-story.md
• .aios-core/install-manifest.yaml
• .claude/commands/AIOS/agents/aios-master.md
• .claude/commands/AIOS/agents/analyst.md
• .claude/commands/AIOS/agents/architect.md
• .claude/commands/AIOS/agents/data-engineer.md
• .claude/commands/AIOS/agents/dev.md
• .claude/commands/AIOS/agents/devops.md
• .claude/commands/AIOS/agents/pm.md
• .claude/commands/AIOS/agents/po.md
• .claude/commands/AIOS/agents/qa.md
• .claude/commands/AIOS/agents/sm.md
• .claude/commands/AIOS/agents/squad-creator.md
• .claude/commands/AIOS/agents/ux-design-expert.md
• .codex/agents/aios-master.md
• .codex/agents/analyst.md
• .codex/agents/architect.md
• .codex/agents/data-engineer.md
• .codex/agents/dev.md
• .codex/agents/devops.md
• .codex/agents/pm.md
• .codex/agents/po.md
• .codex/agents/qa.md
• .codex/agents/sm.md
• .codex/agents/squad-creator.md
• .codex/agents/ux-design-expert.md
• .gemini/rules/AIOS/agents/aios-master.md
• .gemini/rules/AIOS/agents/analyst.md
• .gemini/rules/AIOS/agents/architect.md
• .gemini/rules/AIOS/agents/data-engineer.md
• .gemini/rules/AIOS/agents/dev.md
• .gemini/rules/AIOS/agents/devops.md
• .gemini/rules/AIOS/agents/pm.md
• .gemini/rules/AIOS/agents/po.md
• .gemini/rules/AIOS/agents/qa.md
• .gemini/rules/AIOS/agents/sm.md
• .gemini/rules/AIOS/agents/squad-creator.md
• .gemini/rules/AIOS/agents/ux-design-expert.md
• docs/stories/epics/epic-workflow-intelligence/story-WIS-16-workflow-aware-greeting-handoffs.md
• tests/fixtures/handoffs/handoff-dev-to-qa-consumed.yaml
• tests/fixtures/handoffs/handoff-sm-to-po-unconsumed.yaml
• tests/unit/workflow-chains/workflow-chains.test.js

✅ Files skipped from review due to trivial changes (5)

• .aios-core/development/tasks/spec-write-spec.md
• .aios-core/development/tasks/build-autonomous.md
• .aios-core/development/tasks/qa-fix-issues.md
• tests/fixtures/handoffs/handoff-dev-to-qa-consumed.yaml
• tests/fixtures/handoffs/handoff-sm-to-po-unconsumed.yaml

🚧 Files skipped from review as they are similar to previous changes (3)

• .gemini/rules/AIOS/agents/aios-master.md
• .codex/agents/squad-creator.md
• .claude/commands/AIOS/agents/sm.md

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Search for where *plan command is defined
echo "=== Searching for *plan command definition ==="
find .aios-core -type f -name "*.yaml" -o -name "*.yml" | xargs grep -l "\*plan" 2>/dev/null | head -20

echo -e "\n=== Context around *plan definitions ==="
find .aios-core -type f \( -name "*.yaml" -o -name "*.yml" \) -exec grep -H -B2 -A2 "\*plan" {} \; 2>/dev/null | head -50

echo -e "\n=== Searching for plan command definitions in agents ==="
find .aios-core/development/agents -type f -name "*.yaml" 2>/dev/null | xargs grep -l "plan" | head -10

echo -e "\n=== Check workflow-chains.yaml structure around lines 116-120 ==="
sed -n '100,130p' .aios-core/data/workflow-chains.yaml

Repository: SynkraAI/aios-core

Length of output: 1639

---

🏁 Script executed:

#!/bin/bash
# List directory structure of agents
echo "=== Contents of .aios-core/development/agents ==="
find .aios-core/development/agents -type f -name "*.md" -o -name "*.yaml" | sort

echo -e "\n=== Search for architect-analyze-impact.md references ==="
grep -r "architect-analyze-impact" .aios-core --include="*.yaml" --include="*.md" -n

echo -e "\n=== Check if there's command definition elsewhere ==="
grep -r "plan:" .aios-core/development --include="*.yaml" --include="*.md" -n | head -20

echo -e "\n=== Search for `@architect` agent definition ==="
grep -r "@architect" .aios-core --include="*.yaml" -B2 -A2 | head -30

Repository: SynkraAI/aios-core

Length of output: 5044

---

🏁 Script executed:

#!/bin/bash
# Read the architect agent definition
echo "=== Architect agent definition ==="
cat .aios-core/development/agents/architect.md

echo -e "\n=== Search for plan-related tasks ==="
find .aios-core/development/tasks -type f -name "*plan*.md" | sort

Repository: SynkraAI/aios-core

Length of output: 20229

---

🏁 Script executed:

#!/bin/bash
# Verify the actual mapping of commands to tasks
echo "=== Check workflow-chains.yaml for all `@architect` commands ==="
grep -A2 "agent: \"@architect\"" .aios-core/data/workflow-chains.yaml | head -40

echo -e "\n=== Verify plan-create-implementation.md exists ==="
ls -la .aios-core/development/tasks/plan-create-implementation.md 2>/dev/null || echo "NOT FOUND"

echo -e "\n=== Check what steps 2 and 6 are supposed to do ==="
sed -n '80,130p' .aios-core/data/workflow-chains.yaml | grep -A1 "step:"

Repository: SynkraAI/aios-core

Length of output: 951

---

🏁 Script executed:

#!/bin/bash
# Final verification - check the full workflow context for steps 2 and 6
echo "=== Full workflow context for steps 1-6 ==="
sed -n '70,130p' .aios-core/data/workflow-chains.yaml

Repository: SynkraAI/aios-core

Length of output: 2087

---

Update step 6 to use the correct task for implementation planning.

Step 6 (@architect, *plan) should use plan-create-implementation.md instead of architect-analyze-impact.md. The latter is already used in step 2 for impact analysis. Step 6 produces implementation.yaml and requires a distinct planning task that exists in the codebase (plan-create-implementation.md).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.aios-core/data/workflow-chains.yaml around lines 116 - 120, Replace the
task referenced in the step that runs agent "@architect" with command "*plan" so
it uses the implementation planning task: change task
"architect-analyze-impact.md" to "plan-create-implementation.md" for the step
that outputs "implementation.yaml" (this ensures step 6 uses the distinct
planning task instead of the impact-analysis task already used in step 2).

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Add visibility metadata and dependency mappings for commands.
STEP 3 filters “Available Commands” by visibility, but most commands in this file lack a visibility field, so they’ll never show. Also, several commands don’t appear in dependencies by name (e.g., help, kb, status, guide, exit, create, modify, update-manifest, validate-component, etc.). Please add visibility metadata and ensure each command is backed by a dependency entry.

As per coding guidelines, “Validate all commands listed have corresponding task dependencies” and “Ensure agent has proper visibility metadata for commands.”

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.aios-core/development/agents/aios-master.md around lines 29 - 45, STEP 3's
"Available Commands" filter is skipping most commands because many command
entries lack a visibility field and several command keys (help, kb, status,
guide, exit, create, modify, update-manifest, validate-component, etc.) are
missing corresponding dependency entries; add a visibility array (including
"key") to every command that should be listed by the greeting (e.g., entries
under the commands section like "help", "kb", "status", "guide", "exit",
"create", "modify", "update-manifest", "validate-component") and ensure each of
those command keys has a matching entry in the dependencies mapping (names must
match the command keys exactly) so the greeting's dependency validation passes
and the handoff suggestion logic can resolve next steps.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Find the task file and inspect its content
echo "=== Checking task file at .aios-core/development/tasks/architect-analyze-impact.md ==="
if [ -f ".aios-core/development/tasks/architect-analyze-impact.md" ]; then
  echo "File found. Inspecting lines 829-834 and surrounding context:"
  sed -n '820,845p' ".aios-core/development/tasks/architect-analyze-impact.md" | cat -n
else
  echo "File not found at expected path"
  fd -t f "architect-analyze-impact.md"
fi

Repository: SynkraAI/aios-core

Length of output: 874

---

🏁 Script executed:

#!/bin/bash
# Check for `@analyst` agent definition
echo "=== Searching for `@analyst` agent definition ==="
rg -n '@analyst|agent_name.*analyst|name.*analyst' --type md --type yaml --type json | head -20

# Check for *research command
echo "=== Searching for *research command ==="
rg -n '\*research' --type md --type yaml --type js | head -20

Repository: SynkraAI/aios-core

Length of output: 4305

---

🏁 Script executed:

#!/bin/bash
# Look for the outputs section in the task file (lines 52-66 mentioned in comment)
echo "=== Inspecting Saída (output) section of the task ==="
if [ -f ".aios-core/development/tasks/architect-analyze-impact.md" ]; then
  sed -n '45,75p' ".aios-core/development/tasks/architect-analyze-impact.md" | cat -n
fi

Repository: SynkraAI/aios-core

Length of output: 807

---

🏁 Script executed:

#!/bin/bash
# Check for the execute() return section (lines 331-339)
echo "=== Inspecting execute() return section ==="
if [ -f ".aios-core/development/tasks/architect-analyze-impact.md" ]; then
  sed -n '325,345p' ".aios-core/development/tasks/architect-analyze-impact.md" | cat -n
fi

Repository: SynkraAI/aios-core

Length of output: 1174

---

Handoff section has three issues: undefined output field for {topic}, undeclared complexity_class output, and missing code fence

1. {topic} placeholder lacks corresponding output field. The *research command exists in the codebase and does accept a {topic} parameter, but this task's **Saída:** block (lines 52–66) and execute() return (lines 331–339) never define a topic field. The handoff intends to pass targetComponent.path or derived component data—make this explicit by adding it as a declared output.

2. complexity_class is not a task output. Both the condition and alternatives gate on "Complexity class is STANDARD / COMPLEX / SIMPLE", but this field does not appear in the **Saída:** block or the execute() return object. Either add it as an output, or document how the consuming agent determines it.

3. Handoff section lacks code fence. This section is raw prose, whereas all other structured data in the file (pre-conditions, post-conditions, acceptance-criteria, performance, metadata) are wrapped in fenced YAML blocks. Inconsistent formatting prevents tooling from parsing the task format correctly.

As per coding guidelines, tasks under .aios-core/development/tasks/** must have clear elicitation points and well-defined deliverables.

♻️ Proposed fix: wrap in code fence and clarify output fields

## Handoff
-next_agent: `@analyst`
-next_command: *research {topic}
-condition: Complexity class is STANDARD or COMPLEX (research needed)
-alternatives:
-  - agent: `@pm`, command: *write-spec, condition: Complexity class is SIMPLE (skip research)

+```yaml
+next_agent: "@analyst"
+next_command: "*research {component_path}"
+condition: "complexity_class is STANDARD or COMPLEX"
+alternatives:
+  - agent: "@pm"
+    command: "*write-spec"
+    condition: "complexity_class is SIMPLE"
+```

Add complexity_class and clarify component_path in the **Saída:** block:

 **Saída:**
 - campo: execution_result
   tipo: object
   destino: Memory
   persistido: false
+- campo: component_path
+  tipo: string
+  origem: targetComponent.path from analysis
+  destino: Handoff parameter
+  persistido: false
+- campo: complexity_class
+  tipo: enum(SIMPLE, STANDARD, COMPLEX)
+  origem: Determined during impact analysis
+  destino: Handoff condition routing
+  persistido: false

📝 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

	## Handoff
	next_agent: @analyst
	next_command: *research {topic}
	condition: Complexity class is STANDARD or COMPLEX (research needed)
	alternatives:
	- agent: @pm, command: *write-spec, condition: Complexity class is SIMPLE (skip research)
	## Handoff

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.aios-core/development/tasks/architect-analyze-impact.md around lines 829 -
834, The Handoff block is missing a code fence and two declared outputs: the
`{topic}` parameter and `complexity_class`; wrap the Handoff YAML in a fenced
code block and update the task outputs (`**Saída:**` and the execute() return)
to include a concrete field (e.g., `component_path` or `topic`) that maps to
`targetComponent.path` and add `complexity_class` as an explicit output so the
`condition` and `alternatives` can reference it; specifically update the
`next_command` to use `*research {component_path}` (or `{topic}` if you prefer)
and ensure `execute()` returns `{ component_path: targetComponent.path,
complexity_class: <value> }` so tooling can parse `next_agent`, `next_command`,
`condition`, and `alternatives` correctly.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

“Available Commands” will be empty unless key visibility exists.

STEP 3 filters commands by visibility containing key, but this file doesn’t tag any commands with key. That likely yields an empty list in the greeting. Either add visibility: [key] to the intended short list or add a fallback rule in STEP 3.

Suggested wording fix (fallback if no key visibility)

-      4. Show: "**Available Commands:**" — list commands from the 'commands' section above that have 'key' in their visibility array
+      4. Show: "**Available Commands:**" — list commands from the 'commands' section above that have 'key' in their visibility array; if none are tagged, show a default core set (e.g., *help, *status, *guide, *task, *create).

📝 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

	Display greeting using native context (zero JS execution):
	1. Show: "{icon} {persona_profile.communication.greeting_levels.archetypal}" + permission badge from current permission mode (e.g., [⚠️ Ask], [🟢 Auto], [🔍 Explore])
	2. Show: "**Role:** {persona.role}"
	- Append: "Story: {active story from docs/stories/}" if detected + "Branch: `{branch from gitStatus}`" if not main/master
	3. Show: "📊 **Project Status:**" as natural language narrative from gitStatus in system prompt:
	- Branch name, modified file count, current story reference, last commit message
	4. Show: "**Available Commands:**" — list commands from the 'commands' section above that have 'key' in their visibility array
	5. Show: "Type `*guide` for comprehensive usage instructions."
	Display greeting using native context (zero JS execution):
	1. Show: "{icon} {persona_profile.communication.greeting_levels.archetypal}" + permission badge from current permission mode (e.g., [⚠️ Ask], [🟢 Auto], [🔍 Explore])
	2. Show: "**Role:** {persona.role}"
	- Append: "Story: {active story from docs/stories/}" if detected + "Branch: `{branch from gitStatus}`" if not main/master
	3. Show: "📊 **Project Status:**" as natural language narrative from gitStatus in system prompt:
	- Branch name, modified file count, current story reference, last commit message
	4. Show: "**Available Commands:**" — list commands from the 'commands' section above that have 'key' in their visibility array; if none are tagged, show a default core set (e.g., *help, *status, *guide, *task, *create).
	5. Show: "Type `*guide` for comprehensive usage instructions."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.codex/agents/aios-master.md around lines 30 - 37, The greeting builder's
STEP 3 filters the 'commands' section by visibility containing 'key', but this
document has no commands tagged with visibility: [key], so the "Available
Commands" list will be empty; fix by either adding visibility: [key] to the
intended short-list command entries in the 'commands' section or change STEP 3's
filtering logic to fall back when no commands match (e.g., include commands with
no visibility field or use a default visibility set) so the greeting shows a
sensible command list; refer to STEP 3, the 'commands' section, and the
'visibility'/'key' token when making the change.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Handoff artifact scan conflicts with “do not scan filesystem during startup.”

STEP 5.5 explicitly scans .aios/handoffs/, but the later rule disallows filesystem scans at startup. Please reconcile this by adding a clear exception for the handoff check (or moving the check behind an explicit command).

Suggested clarification

-  - CRITICAL: Do NOT scan filesystem or load any resources during startup, ONLY when commanded
+  - CRITICAL: Do NOT scan filesystem or load any resources during startup, ONLY when commanded (except the `.aios/handoffs/` check in STEP 5.5).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.codex/agents/aios-master.md around lines 38 - 42, The doc currently has
STEP 5.5 scanning `.aios/handoffs/` at startup which conflicts with the rule "do
not scan filesystem during startup"; update the document to reconcile by either
(A) adding a clear exception clause that permits scanning `.aios/handoffs/` only
when the agent is in a designated "handoff-check" startup mode (explicitly name
the mode) and state that the scan is limited to unconsumed handoff artifacts, or
(B) move STEP 5.5 out of the startup flow and require an explicit command (e.g.,
`check-handoffs`) before reading `.aios/handoffs/` and
`.aios-core/data/workflow-chains.yaml`; reference STEP 5.5, `.aios/handoffs/`,
and `.aios-core/data/workflow-chains.yaml` so reviewers can apply the chosen
change consistently.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Native greeting's visibility: 'key' filter produces no results — all commands in this agent use the compact format without visibility metadata.

STEP 3 sub-step 4 instructs the agent to "list commands from the 'commands' section above that have 'key' in their visibility array." Every other agent updated in this PR (qa, devops, squad-creator, pm) has structured commands with explicit visibility arrays (e.g., visibility: [full, quick, key]). data-engineer.md uses the compact key-value format for all commands:

# Current compact format (no visibility field)
- help: Show all available commands with descriptions
- guide: Show comprehensive usage guide for this agent

On activation, "Available Commands:" will render empty, defeating the purpose of the native greeting improvement.

The same issue is likely present in the synced source at .aios-core/development/agents/data-engineer.md.

🔧 Proposed fix — convert commands to structured format with visibility

 commands:
   # Core Commands
-  - help: Show all available commands with descriptions
-  - guide: Show comprehensive usage guide for this agent
-  - yolo: 'Toggle permission mode (cycle: ask > auto > explore)'
-  - exit: Exit data-engineer mode
-  - doc-out: Output complete document
-  - execute-checklist {checklist}: Run DBA checklist
+  - name: help
+    visibility: [full, quick, key]
+    description: 'Show all available commands with descriptions'
+  - name: guide
+    visibility: [full, quick, key]
+    description: 'Show comprehensive usage guide for this agent'
+  - name: yolo
+    visibility: [full, quick, key]
+    description: 'Toggle permission mode (cycle: ask > auto > explore)'
+  - name: exit
+    visibility: [full, quick, key]
+    description: 'Exit data-engineer mode'
+  - name: doc-out
+    visibility: [full]
+    description: 'Output complete document'
+  - name: execute-checklist
+    args: '{checklist}'
+    visibility: [full, quick]
+    description: 'Run DBA checklist'
   # ... (remaining commands similarly)

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.codex/agents/data-engineer.md around lines 22 - 37, The native greeting
shows no "Available Commands" because the commands in the data-engineer agent
use the compact key-value YAML form (e.g., "- help: ...") and therefore lack a
visibility array with 'key'; update the commands section in data-engineer.md
(and the synced copy in .aios-core/development/agents/data-engineer.md if
present) to the structured format so each command becomes an object with
explicit fields: name (or key), description, and visibility: [full, quick, key]
(at minimum include 'key' so the native greeting picks it up); keep the same
descriptions and add other visibility flags as appropriate for each command.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Resolve activation-time file-loading contradiction.

STEP 3 requires reading .aios-core/data/workflow-chains.yaml during activation, but the IDE-FILE-RESOLUTION section says dependency files must only be loaded on explicit user command. This is a direct conflict and can block compliant activation. Also, “commands section above” is inaccurate (it’s below), which can mislead strict renderers.

📝 Suggested doc fix

-      4. Show: "**Available Commands:**" — list commands from the 'commands' section above that have 'key' in their visibility array
+      4. Show: "**Available Commands:**" — list commands from the 'commands' section below that have 'key' in their visibility array
       5. Show: "Type `*guide` for comprehensive usage instructions."
       5.5. Check `.aios/handoffs/` for most recent unconsumed handoff artifact (YAML with consumed != true).
            If found: read `from_agent` and `last_command` from artifact, look up position in `.aios-core/data/workflow-chains.yaml` matching from_agent + last_command, and show: "💡 **Suggested:** `*{next_command} {args}`"
            If chain has multiple valid next steps, also show: "Also: `*{alt1}`, `*{alt2}`"
            Mark artifact as consumed: true.
            If no artifact or no match found: skip this step silently.
+      NOTE: workflow-chains.yaml is allowed for activation-time read (handoff suggestion only).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.codex/agents/devops.md around lines 22 - 34, The activation doc currently
requires loading `.aios-core/data/workflow-chains.yaml` during startup (STEP 3)
which conflicts with the IDE-FILE-RESOLUTION policy that forbids dependency file
reads at activation; change the flow so activation only inspects
`.aios/handoffs/` for an unconsumed handoff artifact and, if found, surface the
`from_agent`/`last_command` context but defer loading `workflow-chains.yaml`
until an explicit user command (e.g., `*suggest` or similar) or when the user
grants permission; also correct the copy that says "commands section above" to
"commands section below" so renderers aren’t misled. Ensure references to
`workflow-chains.yaml`, `.aios/handoffs/`, `from_agent`, and `last_command` are
used so the implementer can find the relevant code paths (`activation`/greeting
generation and the handoff processing logic).

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Locate workflow-chains.yaml to confirm its actual path in the repo
fd -t f "workflow-chains.yaml"

Repository: SynkraAI/aios-core

Length of output: 44

---

🏁 Script executed:

#!/bin/bash
# Check the IDE-FILE-RESOLUTION convention definition in the file
cat -n .codex/agents/sm.md | head -20

Repository: SynkraAI/aios-core

Length of output: 1596

---

🏁 Script executed:

#!/bin/bash
# Look for the data dependency type mapping around lines 11-15
sed -n '11,15p' .codex/agents/sm.md

Repository: SynkraAI/aios-core

Length of output: 453

---

🏁 Script executed:

#!/bin/bash
# Check the exact line 30 and surrounding context to see the reference
sed -n '25,35p' .codex/agents/sm.md

Repository: SynkraAI/aios-core

Length of output: 1179

---

🏁 Script executed:

#!/bin/bash
# Broader search to confirm workflow-chains.yaml doesn't exist anywhere
find . -name "*workflow*" -o -name "*chains*" 2>/dev/null | head -20

Repository: SynkraAI/aios-core

Length of output: 1109

---

🏁 Script executed:

#!/bin/bash
# Check if the .aios-core/data or .aios-core/development/data directories exist
ls -la .aios-core/ 2>/dev/null | head -20

Repository: SynkraAI/aios-core

Length of output: 1272

---

Move workflow-chains.yaml to follow IDE-FILE-RESOLUTION convention

The reference .aios-core/data/workflow-chains.yaml at line 30 violates the IDE-FILE-RESOLUTION convention defined in this file (lines 11–15), which maps data dependencies to .aios-core/development/data/{name}. The file should be relocated from .aios-core/data/workflow-chains.yaml to .aios-core/development/data/workflow-chains.yaml, and the reference updated accordingly.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.codex/agents/sm.md at line 30, The reference to
`.aios-core/data/workflow-chains.yaml` in .codex/agents/sm.md violates the
IDE-FILE-RESOLUTION convention; move the actual file to
`.aios-core/development/data/workflow-chains.yaml` and update the reference
string in the sentence "If found: read `from_agent` and `last_command` from
artifact, look up position in `.aios-core/data/workflow-chains.yaml`..." to
point to `.aios-core/development/data/workflow-chains.yaml`; also search for any
other occurrences of `workflow-chains.yaml` in the repo and update them to the
new path to keep readers and code consistent.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Command list filter doesn’t match this file’s command schema.

STEP 3 requires visibility metadata, but the commands section here is a simple map without visibility. That will likely result in an empty “Available Commands” list. Consider listing a fixed 3–6 core commands or add visibility metadata.

Suggested wording fix (schema-aligned)

-      4. Show: "**Available Commands:**" — list commands from the 'commands' section above that have 'key' in their visibility array
+      4. Show: "**Available Commands:**" — list 3–6 core commands from the 'commands' section (e.g., *help, *research, *audit, *tokenize, *build, *document).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.codex/agents/ux-design-expert.md around lines 26 - 36, The "Available
Commands" filter expects a visibility array but the current commands section is
a plain map, so either add visibility metadata to each command entry (include a
visibility array with values like "key", "auto", etc.) or change the greeting
generation to select commands from the existing map keys (and fallback to a
fixed 3–6 core commands list) instead of filtering by visibility; update the
greeting builder logic that reads
persona_profile.communication.greeting_levels.archetypal and the "commands" map
(and the handoff lookup logic that reads .aios/handoffs and
workflow-chains.yaml) so it uses the new visibility fields or the
key-based/fallback selection for the "Available Commands" list.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Silent write failure in STEP 5.5 can cause the handoff suggestion to replay on every activation.

Line 32 instructs the agent to "Mark artifact as consumed: true." If this file write fails — due to missing write tools in the current context, read-only filesystem mount, or a permissions mismatch — the artifact stays unconsumed and the same handoff suggestion will reappear on every subsequent activation, creating a sticky re-display loop.

Additionally, the write side-effect sits inside a block labelled "zero JS execution," which is philosophically inconsistent. Either the fallback handling for write failure should be made explicit, or the consumed-state update should be deferred to a post-greeting step:

✏️ Proposed fix

-     Mark artifact as consumed: true.
-     If no artifact or no match found: skip this step silently.
+     Attempt to mark artifact as consumed: true. If the write fails, skip silently and do not retry.
+     If no artifact or no match found: skip this step silently.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.gemini/rules/AIOS/agents/analyst.md around lines 29 - 33, STEP 5.5
currently performs an unconditional write ("Mark artifact as consumed: true.")
inside the "zero JS execution" block which can silently fail and cause replay
loops; update the step to attempt the write atomically and handle failures:
after resolving the handoff artifact from .aios/handoffs/ (and reading
from_agent/last_command and lookup in .aios-core/data/workflow-chains.yaml),
either (A) perform the consumed=true write and verify success (retry with
backoff on transient failures and log/emit a non-blocking warning if it fails),
or (B) defer marking consumed until a guaranteed post-greeting step that runs
with proper write permissions; ensure the rule documents the fallback behavior
(log/error message or defer path) and remove the expectation that writes succeed
silently inside the "zero JS execution" block so the suggestion cannot replay on
every activation.

[coderabbitai]

Actionable comments posted: 8

♻️ Duplicate comments (5)

.aios-core/core/code-intel/code-intel-client.js (1)

94-102: Past review concern (try/catch in _detectProvider) is addressed.

The try/catch now wraps the isAvailable() call as previously requested. One observation: errors are silently swallowed (_err is unused). If provider availability checks fail intermittently, debugging will be harder without any log output. Consider adding a single console.warn or structured log at debug level for observability — but this is optional given the graceful fallback behavior.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.aios-core/core/code-intel/code-intel-client.js around lines 94 - 102, The
try/catch in _detectProvider swallows provider availability errors (caught as
_err) which hinders observability; update the catch to log the error (e.g.,
console.warn or your module logger) including the provider identity and the
error object so intermittent failures in provider.isAvailable() are visible,
while keeping the graceful fallback and still returning the next available
provider and assigning this._activeProvider as before.

.aios-core/core/code-intel/hook-runtime.js (1)

33-84: Past review concern (try/catch guard in resolveCodeIntel) is addressed.

The entire function body is now wrapped in a try/catch that returns null on any exception, preventing unhandled rejections from bubbling into hook callers. This correctly implements the previously requested fix.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.aios-core/core/code-intel/hook-runtime.js around lines 33 - 84,
resolveCodeIntel currently wraps the whole body in a try/catch that returns null
but silently swallows errors; update the catch in resolveCodeIntel to log the
caught error (e.g., use processLogger.error or console.error with the _err/err
stack and context such as cwd and relativePath) before returning null so
provider exceptions (from getProvider, provider.findDefinition,
provider.findReferences, provider.analyzeDependencies) are still guarded but
recorded for debugging.

.gemini/rules/AIOS/agents/ux-design-expert.md (1)

26-41: Same visibility array mismatch as the other synced copies.

This file is identical to the .claude and .codex copies. The same issue applies: STEP 3 item 4 references visibility arrays that don't exist in the flat commands map. See the comment on .claude/commands/AIOS/agents/ux-design-expert.md for the suggested fix — it should be applied at the source (.aios-core/development/agents/ux-design-expert.md) and re-synced.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.gemini/rules/AIOS/agents/ux-design-expert.md around lines 26 - 41, STEP 3
item 4 references a non‑existent visibility array on the flat commands map;
update the canonical agent spec that generates these synced copies to either (a)
change the commands structure to include a visibility array per command, or (b)
change STEP 3 item 4 to filter visible commands using the existing command.key
membership (e.g., check command.key against the visibility list source), then
regenerate/sync the derived copies (ensure the fix is applied in the source
agent definition that produces ux-design-expert and re-sync other copies).

.claude/commands/AIOS/agents/ux-design-expert.md (1)

26-41: ⚠️ Potential issue | 🟡 Minor

STEP 3 item 4 references visibility arrays that don't exist in this file's command schema.

STEP 3 sub-step 4 instructs: "list commands from the 'commands' section above that have 'key' in their visibility array." However, the commands section (Lines 173–211) is a flat key-value map (e.g., research: 'description') with no visibility metadata. This will likely produce an empty "Available Commands" list during activation.

Either add visibility arrays to the command entries (as done in squad-creator.md) or change the instruction to list a fixed set of core commands.

🔧 Simpler fix: hardcode core commands in the greeting instruction

-      4. Show: "**Available Commands:**" — list commands from the 'commands' section above that have 'key' in their visibility array
+      4. Show: "**Available Commands:**" — list core commands: *help, *research, *audit, *tokenize, *build, *document

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.claude/commands/AIOS/agents/ux-design-expert.md around lines 26 - 41, STEP
3 item 4 references a non‑existent "visibility" array on entries in the commands
section, so the "Available Commands" list will be empty; fix by either (A)
adding a visibility array to each command entry in the commands map (e.g., add
"visibility": ["key", ...] to entries used by UX flows, matching the pattern
used in squad-creator.md) and update the greeting logic to filter commands by
visibility, or (B) change STEP 3 item 4 to list a fixed set of core commands
(hardcode names like "research", "sketch", "prototype", etc.) instead of
filtering by visibility — choose one approach and update the STEP 3 item 4 text
and the commands data accordingly so the greeting shows actual commands.

.codex/agents/ux-design-expert.md (1)

26-32: Same visibility array mismatch — see root cause at source file.

This was flagged in a previous review on this file. The fix should be applied at the source (.aios-core/development/agents/ux-design-expert.md) and re-synced.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.codex/agents/ux-design-expert.md around lines 26 - 32, The copied agent
spec has a mismatched visibility array for command entries; open the source
ux-design-expert.md and align each command's "visibility" array with the
canonical keys used by the system (ensure each command object in the "commands"
section includes the expected "key" values and that the "visibility" arrays
reference those exact keys), correct any discrepancies involving "visibility" vs
actual command "key" names (check entries referencing
persona_profile.communication.greeting_levels.archetypal and the commands list),
save the source file, and re-sync/regenerate the .codex copy so both documents
match.

🧹 Nitpick comments (6)

.aios-core/development/agents/squad-creator.md (2)

29-33: Sub-item numbering jumps 5 → 5.5 → 6 — prefer sequential numbering.

The non-sequential 5.5 label is unusual for agent instruction parsing. A numbered 5a / 5b split or promoting 5.5 to its own numbered step keeps the instruction set uniformly parseable.

✏️ Proposed fix (option A — promote to step 6, renumber closing)

-      5. Show: "Type `*guide` for comprehensive usage instructions."
-      5.5. Check `.aios/handoffs/` ...
-           ...
-      6. Show: "{persona_profile.communication.signature_closing}"
+      5. Show: "Type `*guide` for comprehensive usage instructions."
+      6. Check `.aios/handoffs/` ...
+         ...
+      7. Show: "{persona_profile.communication.signature_closing}"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.aios-core/development/agents/squad-creator.md around lines 29 - 33, The
sub-step labeled "5.5" in the squad-creator instructions should be renumbered to
maintain sequential numbering; change the "5.5" label to "6" (and increment the
original step 6 and any following steps accordingly) so the block that reads
about checking `.aios/handoffs/` for unconsumed artifacts, reading `from_agent`
and `last_command`, matching against `.aios-core/data/workflow-chains.yaml`,
showing the "💡 **Suggested:** `*{next_command} {args}`" and alternate
suggestions, and marking `consumed: true` becomes step 6 and subsequent steps
are renumbered to preserve order and parsing consistency.

---

95-151: All commands carry visibility metadata; task-file coverage is complete.

Every command that executes a workflow (design, create, validate, list, migrate, analyze, extend, download, publish, sync) maps to a corresponding .md file in dependencies.tasks. Utility commands (help, guide, yolo, exit) correctly omit task files. No hardcoded credentials or sensitive data found.

Minor inconsistency worth noting: migrate-squad, analyze-squad, and extend-squad include an explicit task: field in their command definitions while the remaining workflow commands rely solely on name-convention resolution via IDE-FILE-RESOLUTION. Aligning all workflow commands to carry (or all to omit) the explicit task: field would improve consistency. As per coding guidelines: "Validate all commands listed have corresponding task dependencies."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.aios-core/development/agents/squad-creator.md around lines 95 - 151, The
command list mixes explicit task: fields and implicit name-convention
resolution; fix by adding explicit task entries for all workflow commands so
every command has a corresponding task dependency. For each command name
(design-squad, create-squad, validate-squad, list-squads, download-squad,
publish-squad, sync-squad-synkra) add a task: reference using the same naming
convention as existing entries (e.g., task: squad-creator-design.md,
squad-creator-create.md, squad-creator-validate.md, squad-creator-list.md,
squad-creator-download.md, squad-creator-publish.md, squad-creator-sync.md) to
match migrate-squad, analyze-squad, and extend-squad and satisfy the "Validate
all commands listed have corresponding task dependencies" guideline.

.gemini/rules/AIOS/agents/squad-creator.md (1)

337-338: Duplicate --- horizontal rule.

Line 337 introduces a second consecutive --- separator immediately before the pre-existing one on line 338, creating redundant dividers.

✏️ Proposed fix

-
----
-
 ---
 *AIOS Agent - Synced from .aios-core/development/agents/squad-creator.md*

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.gemini/rules/AIOS/agents/squad-creator.md around lines 337 - 338, Remove
the redundant horizontal rule by deleting the duplicate '---' introduced on the
earlier line so only a single '---' separator remains; locate the consecutive
'---' sequences in the AIOS agents squad-creator markdown (the duplicated '---'
adjacent to the existing separator) and remove the extra one.

.aios-core/core/code-intel/hook-runtime.js (2)

136-149: Dependency node slicing assumes the first node is the target file.

Line 139 (dependencies.nodes.slice(1)) relies on the convention that analyzeDependencies always places the target file as the first node. This is an implicit contract with the RegistryProvider's output format. If a different provider is wired in (or the convention changes), this would silently exclude a real dependency or include the target in the output.

Consider adding a defensive filter or a brief inline comment documenting the contract.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.aios-core/core/code-intel/hook-runtime.js around lines 136 - 149, The
current code assumes the first element returned by
analyzeDependencies/RegistryProvider is the target and uses
dependencies.nodes.slice(1), which can silently drop or include the wrong node
if that contract changes; replace the blind slice with a defensive filter that
excludes the target explicitly (e.g., filter out nodes with an explicit marker
like node.isTarget or by comparing node.name/path to the known target
identifier) and then use that filtered list as depNodes, and also add a short
inline comment on analyzeDependencies/RegistryProvider contract near the
dependencies handling to document expected behavior.

---

160-167: escapeXml omits single-quote (' → ') escaping.

The current implementation handles &, <, >, and ", which is sufficient for the double-quoted attributes in formatAsXml. However, since escapeXml is exported as a public utility, external callers may use it in contexts where single-quoted XML attributes are expected. Adding ' would make it a complete XML escape function.

🔧 Optional fix

 function escapeXml(str) {
   if (!str) return '';
   return String(str)
     .replace(/&/g, '&')
     .replace(/</g, '&lt;')
     .replace(/>/g, '&gt;')
-    .replace(/"/g, '&quot;');
+    .replace(/"/g, '&quot;')
+    .replace(/'/g, '&apos;');
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.aios-core/core/code-intel/hook-runtime.js around lines 160 - 167, escapeXml
currently escapes &, <, > and " but omits single-quote, which makes it
incomplete for contexts using single-quoted XML attributes; update the exported
function escapeXml to also replace single-quote characters (') with &apos; so it
returns a fully escaped XML string for both single- and double-quoted attribute
contexts (keep replacements in String(str).replace(...) style and reference the
escapeXml function used by formatAsXml).

.aios-core/core/code-intel/code-intel-client.js (1)

134-143: Cache key serialization could throw on circular references.

JSON.stringify(args) on Line 136 will throw a TypeError if any argument contains circular references. The outer try/catch in _executeCapability catches this, but it will count as a circuit-breaker failure via _onFailure(), which is misleading — it's not a provider issue. This is a low-probability edge case, but worth noting.

🛡️ Optional: isolate cache-key creation

     // Check cache
-    const cacheKey = `${capability}:${JSON.stringify(args)}`;
+    let cacheKey;
+    try {
+      cacheKey = `${capability}:${JSON.stringify(args)}`;
+    } catch {
+      // Fallback: skip cache for non-serializable args
+      cacheKey = null;
+    }
     const cached = this._getFromCache(cacheKey);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.aios-core/core/code-intel/code-intel-client.js around lines 134 - 143, The
cache key creation using JSON.stringify(args) inside _executeCapability can
throw on circular references and wrongly trigger circuit-breaker failure
handling; modify the logic around building cacheKey so JSON.stringify is
attempted inside a small try/catch (or use a safe serializer) and if
serialization fails simply skip cache lookup/metric updates (do not call
_getFromCache, do not increment _cacheMisses/_cacheHits, and do not invoke
_onFailure), then proceed to execute the capability normally; locate references
to cacheKey, args, _getFromCache, _cacheHits, _cacheMisses and _onFailure in
_executeCapability to implement this change.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.aios-core/core/code-intel/hook-runtime.js:
- Around line 14-19: getProvider currently stores a single _provider and ignores
later projectRoot args, so change the cache to be keyed by projectRoot (e.g.,
use a Map or object) and return the RegistryProvider instance for the requested
projectRoot; update references to _provider to use a per-root cache (lookup by
projectRoot, instantiate new RegistryProvider({ projectRoot }) when missing) so
getProvider(projectRoot) always returns the provider for that root while
preserving the RegistryProvider construction and return behavior.

In @.aios-core/core/doctor/checks/ide-sync.js:
- Around line 38-62: The catch blocks for reading agentsSourceDir and
agentsIdeDir drop the underlying error; update the two catch handlers that
return the FAIL/WARN objects so they include the caught error details and
directory path (use the caught error variable instead of _err) in the message
(references: agentsSourceDir, agentsIdeDir, sourceAgents, ideFiles, and name).
Capture err.message (and optionally err.stack) and concatenate it into the
returned message field so the returned object provides both the directory path
and the filesystem error information.

In @.aios-core/development/agents/squad-creator.md:
- Around line 29-33: Step 5.5 currently marks the handoff artifact as consumed
in the same block that assembles and displays the suggestion, which can
permanently lose the hint if sending fails; change the flow so you only set the
artifact's consumed flag to true after the "💡 **Suggested:** `*{next_command}
{args}`" (and any "Also:" alternatives) have been successfully output/confirmed
sent, i.e., move the "Mark artifact as consumed: true" write to occur after the
suggestion display/confirmation step and add minimal error handling to avoid
consuming the artifact on display failure.
- Around line 21-37: STEP 3 currently both assembles and displays the greeting
("Display greeting using native context" and multiple "Show:" lines) while STEP
4 again says "Display the greeting assembled in STEP 3", causing
double-rendering; change STEP 3 to "Assemble greeting using native context (do
not display)" and convert each "Show:" sub-item into an assembly directive
(e.g., build components for
persona_profile.communication.greeting_levels.archetypal, persona.role +
story/branch, project status from gitStatus, available commands from commands
where visibility includes key, handoff lookup in .aios/handoffs and
workflow-chains resolution, and signature_closing) so STEP 3 only constructs the
greeting, and leave the actual output/printing only in STEP 4 (including the
fallback that invokes
.aios-core/development/scripts/unified-activation-pipeline.js squad-creator).

In @.aios-core/development/agents/ux-design-expert.md:
- Around line 26-32: The greeting instructions reference a non-existent
commands[].visibility field: update the 'commands' section to use the object
schema (each entry as {name, visibility, description}) like squad-creator.md so
STEP 3 sub-step 4 can filter by visibility, or instead change the greeting step
to list a fixed set of core commands (remove visibility filtering) to match the
current flat key-value commands format; ensure you update the 'commands' symbol
and any code that reads it so it expects the chosen schema and keep the existing
persona_profile checks as-is.

In @.gemini/rules/AIOS/agents/squad-creator.md:
- Line 47: Change the word "deviance" to "deviation" in the rule text that reads
"CRITICAL: On activation, ONLY greet user and then HALT to await user requested
assistance or given commands. ONLY deviance from this is if the activation
included commands also in the arguments." — edit that sentence (the rule string
containing "ONLY deviance from this") to use "deviation" instead to correct the
grammar while preserving the original meaning.
- Around line 29-31: The suggestion template uses an undefined `{args}` variable
and the "most recent unconsumed handoff artifact" recency is ambiguous; update
the logic that reads `.aios/handoffs/` to deterministically pick the most recent
unconsumed artifact by file modification time (mtime) and, when looking up the
entry in `.aios-core/data/workflow-chains.yaml`, either read a defined `args`
field from the matched chain entry and substitute it into the template
`*{next_command} {args}`, or remove `{args}` from the template entirely so it
only shows `*{next_command}`; ensure the code that performs the lookup (the
workflow-chains reader / matcher) is updated to expose an `args` property if you
choose the first option.

---

Duplicate comments:
In @.aios-core/core/code-intel/code-intel-client.js:
- Around line 94-102: The try/catch in _detectProvider swallows provider
availability errors (caught as _err) which hinders observability; update the
catch to log the error (e.g., console.warn or your module logger) including the
provider identity and the error object so intermittent failures in
provider.isAvailable() are visible, while keeping the graceful fallback and
still returning the next available provider and assigning this._activeProvider
as before.

In @.aios-core/core/code-intel/hook-runtime.js:
- Around line 33-84: resolveCodeIntel currently wraps the whole body in a
try/catch that returns null but silently swallows errors; update the catch in
resolveCodeIntel to log the caught error (e.g., use processLogger.error or
console.error with the _err/err stack and context such as cwd and relativePath)
before returning null so provider exceptions (from getProvider,
provider.findDefinition, provider.findReferences, provider.analyzeDependencies)
are still guarded but recorded for debugging.

In @.claude/commands/AIOS/agents/ux-design-expert.md:
- Around line 26-41: STEP 3 item 4 references a non‑existent "visibility" array
on entries in the commands section, so the "Available Commands" list will be
empty; fix by either (A) adding a visibility array to each command entry in the
commands map (e.g., add "visibility": ["key", ...] to entries used by UX flows,
matching the pattern used in squad-creator.md) and update the greeting logic to
filter commands by visibility, or (B) change STEP 3 item 4 to list a fixed set
of core commands (hardcode names like "research", "sketch", "prototype", etc.)
instead of filtering by visibility — choose one approach and update the STEP 3
item 4 text and the commands data accordingly so the greeting shows actual
commands.

In @.codex/agents/ux-design-expert.md:
- Around line 26-32: The copied agent spec has a mismatched visibility array for
command entries; open the source ux-design-expert.md and align each command's
"visibility" array with the canonical keys used by the system (ensure each
command object in the "commands" section includes the expected "key" values and
that the "visibility" arrays reference those exact keys), correct any
discrepancies involving "visibility" vs actual command "key" names (check
entries referencing persona_profile.communication.greeting_levels.archetypal and
the commands list), save the source file, and re-sync/regenerate the .codex copy
so both documents match.

In @.gemini/rules/AIOS/agents/ux-design-expert.md:
- Around line 26-41: STEP 3 item 4 references a non‑existent visibility array on
the flat commands map; update the canonical agent spec that generates these
synced copies to either (a) change the commands structure to include a
visibility array per command, or (b) change STEP 3 item 4 to filter visible
commands using the existing command.key membership (e.g., check command.key
against the visibility list source), then regenerate/sync the derived copies
(ensure the fix is applied in the source agent definition that produces
ux-design-expert and re-sync other copies).

---

Nitpick comments:
In @.aios-core/core/code-intel/code-intel-client.js:
- Around line 134-143: The cache key creation using JSON.stringify(args) inside
_executeCapability can throw on circular references and wrongly trigger
circuit-breaker failure handling; modify the logic around building cacheKey so
JSON.stringify is attempted inside a small try/catch (or use a safe serializer)
and if serialization fails simply skip cache lookup/metric updates (do not call
_getFromCache, do not increment _cacheMisses/_cacheHits, and do not invoke
_onFailure), then proceed to execute the capability normally; locate references
to cacheKey, args, _getFromCache, _cacheHits, _cacheMisses and _onFailure in
_executeCapability to implement this change.

In @.aios-core/core/code-intel/hook-runtime.js:
- Around line 136-149: The current code assumes the first element returned by
analyzeDependencies/RegistryProvider is the target and uses
dependencies.nodes.slice(1), which can silently drop or include the wrong node
if that contract changes; replace the blind slice with a defensive filter that
excludes the target explicitly (e.g., filter out nodes with an explicit marker
like node.isTarget or by comparing node.name/path to the known target
identifier) and then use that filtered list as depNodes, and also add a short
inline comment on analyzeDependencies/RegistryProvider contract near the
dependencies handling to document expected behavior.
- Around line 160-167: escapeXml currently escapes &, <, > and " but omits
single-quote, which makes it incomplete for contexts using single-quoted XML
attributes; update the exported function escapeXml to also replace single-quote
characters (') with &apos; so it returns a fully escaped XML string for both
single- and double-quoted attribute contexts (keep replacements in
String(str).replace(...) style and reference the escapeXml function used by
formatAsXml).

In @.aios-core/development/agents/squad-creator.md:
- Around line 29-33: The sub-step labeled "5.5" in the squad-creator
instructions should be renumbered to maintain sequential numbering; change the
"5.5" label to "6" (and increment the original step 6 and any following steps
accordingly) so the block that reads about checking `.aios/handoffs/` for
unconsumed artifacts, reading `from_agent` and `last_command`, matching against
`.aios-core/data/workflow-chains.yaml`, showing the "💡 **Suggested:**
`*{next_command} {args}`" and alternate suggestions, and marking `consumed:
true` becomes step 6 and subsequent steps are renumbered to preserve order and
parsing consistency.
- Around line 95-151: The command list mixes explicit task: fields and implicit
name-convention resolution; fix by adding explicit task entries for all workflow
commands so every command has a corresponding task dependency. For each command
name (design-squad, create-squad, validate-squad, list-squads, download-squad,
publish-squad, sync-squad-synkra) add a task: reference using the same naming
convention as existing entries (e.g., task: squad-creator-design.md,
squad-creator-create.md, squad-creator-validate.md, squad-creator-list.md,
squad-creator-download.md, squad-creator-publish.md, squad-creator-sync.md) to
match migrate-squad, analyze-squad, and extend-squad and satisfy the "Validate
all commands listed have corresponding task dependencies" guideline.

In @.gemini/rules/AIOS/agents/squad-creator.md:
- Around line 337-338: Remove the redundant horizontal rule by deleting the
duplicate '---' introduced on the earlier line so only a single '---' separator
remains; locate the consecutive '---' sequences in the AIOS agents squad-creator
markdown (the duplicated '---' adjacent to the existing separator) and remove
the extra one.

---

ℹ️ Review info

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 121df5d and ef94e75.

📒 Files selected for processing (12)

• .aios-core/core/code-intel/code-intel-client.js
• .aios-core/core/code-intel/hook-runtime.js
• .aios-core/core/doctor/checks/ide-sync.js
• .aios-core/development/agents/squad-creator.md
• .aios-core/development/agents/ux-design-expert.md
• .aios-core/install-manifest.yaml
• .claude/commands/AIOS/agents/squad-creator.md
• .claude/commands/AIOS/agents/ux-design-expert.md
• .codex/agents/squad-creator.md
• .codex/agents/ux-design-expert.md
• .gemini/rules/AIOS/agents/squad-creator.md
• .gemini/rules/AIOS/agents/ux-design-expert.md

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Singleton ignores projectRoot after first initialization.

getProvider caches the first RegistryProvider instance and returns it for all subsequent calls regardless of the projectRoot argument. If this module is ever called with different project roots within the same process (e.g., a multi-workspace scenario), the second call silently uses the wrong project's registry.

🔧 Suggested fix: key the cache by projectRoot

-/** Cached provider instance (survives across hook invocations in same process). */
-let _provider = null;
+/** Cached provider instances keyed by projectRoot. */
+const _providers = new Map();

 function getProvider(projectRoot) {
-  if (!_provider) {
-    _provider = new RegistryProvider({ projectRoot });
-  }
-  return _provider;
+  const key = projectRoot || '';
+  if (!_providers.has(key)) {
+    _providers.set(key, new RegistryProvider({ projectRoot }));
+  }
+  return _providers.get(key);
 }

 function _resetForTesting() {
-  _provider = null;
+  _providers.clear();
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.aios-core/core/code-intel/hook-runtime.js around lines 14 - 19, getProvider
currently stores a single _provider and ignores later projectRoot args, so
change the cache to be keyed by projectRoot (e.g., use a Map or object) and
return the RegistryProvider instance for the requested projectRoot; update
references to _provider to use a per-root cache (lookup by projectRoot,
instantiate new RegistryProvider({ projectRoot }) when missing) so
getProvider(projectRoot) always returns the provider for that root while
preserving the RegistryProvider construction and return behavior.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Add error details to the FAIL/WARN messages.

The catch blocks drop the underlying filesystem error and path context, which makes doctor failures harder to diagnose. Include err.message (and ideally the directory path) in the message.

💡 Suggested update

-  } catch (_err) {
+  } catch (err) {
     return {
       check: name,
       status: 'FAIL',
-      message: 'Cannot read source agents directory',
+      message: `Cannot read source agents directory (${agentsSourceDir}): ${err.message}`,
       fixCommand: 'npx aios-core install --force',
     };
   }
@@
-  } catch (_err) {
+  } catch (err) {
     return {
       check: name,
       status: 'WARN',
-      message: 'Cannot read IDE agents directory',
+      message: `Cannot read IDE agents directory (${agentsIdeDir}): ${err.message}`,
       fixCommand: 'npx aios-core install --force',
     };
   }

As per coding guidelines "Verify error handling is comprehensive with proper try/catch and error context."

📝 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

	let sourceAgents, ideFiles;
	try {
	sourceAgents = fs.readdirSync(agentsSourceDir)
	.filter((f) => f.endsWith('.md'))
	.map((f) => f.replace('.md', ''));
	} catch (_err) {
	return {
	check: name,
	status: 'FAIL',
	message: 'Cannot read source agents directory',
	fixCommand: 'npx aios-core install --force',
	};
	}
	const ideFiles = fs.readdirSync(agentsIdeDir)
	.filter((f) => f.endsWith('.md'));
	try {
	ideFiles = fs.readdirSync(agentsIdeDir)
	.filter((f) => f.endsWith('.md'));
	} catch (_err) {
	return {
	check: name,
	status: 'WARN',
	message: 'Cannot read IDE agents directory',
	fixCommand: 'npx aios-core install --force',
	};
	}
	let sourceAgents, ideFiles;
	try {
	sourceAgents = fs.readdirSync(agentsSourceDir)
	.filter((f) => f.endsWith('.md'))
	.map((f) => f.replace('.md', ''));
	} catch (err) {
	return {
	check: name,
	status: 'FAIL',
	message: `Cannot read source agents directory (${agentsSourceDir}): ${err.message}`,
	fixCommand: 'npx aios-core install --force',
	};
	}
	try {
	ideFiles = fs.readdirSync(agentsIdeDir)
	.filter((f) => f.endsWith('.md'));
	} catch (err) {
	return {
	check: name,
	status: 'WARN',
	message: `Cannot read IDE agents directory (${agentsIdeDir}): ${err.message}`,
	fixCommand: 'npx aios-core install --force',
	};
	}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.aios-core/core/doctor/checks/ide-sync.js around lines 38 - 62, The catch
blocks for reading agentsSourceDir and agentsIdeDir drop the underlying error;
update the two catch handlers that return the FAIL/WARN objects so they include
the caught error details and directory path (use the caught error variable
instead of _err) in the message (references: agentsSourceDir, agentsIdeDir,
sourceAgents, ideFiles, and name). Capture err.message (and optionally
err.stack) and concatenate it into the returned message field so the returned
object provides both the directory path and the filesystem error information.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

STEP 3 header ambiguity risks double-rendering the greeting.

STEP 3's opening directive says "Display greeting using native context" (line 21), and its sub-items (1–6) already instruct the agent to Show: each block. STEP 4 (line 37) then says "Display the greeting assembled in STEP 3." An agent following both instructions literally will render the greeting twice.

STEP 3 should be scoped to assemble, leaving display exclusively to STEP 4.

✏️ Proposed fix

-  - STEP 3: |
-      Display greeting using native context (zero JS execution):
+  - STEP 3: |
+      Assemble greeting using native context (zero JS execution):
       1. Show: "{icon} {persona_profile.communication.greeting_levels.archetypal}" + permission badge from current permission mode (e.g., [⚠️ Ask], [🟢 Auto], [🔍 Explore])
       ...
-  - STEP 4: Display the greeting assembled in STEP 3
+  - STEP 4: Display the complete greeting assembled in STEP 3 — do not re-render individual parts

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.aios-core/development/agents/squad-creator.md around lines 21 - 37, STEP 3
currently both assembles and displays the greeting ("Display greeting using
native context" and multiple "Show:" lines) while STEP 4 again says "Display the
greeting assembled in STEP 3", causing double-rendering; change STEP 3 to
"Assemble greeting using native context (do not display)" and convert each
"Show:" sub-item into an assembly directive (e.g., build components for
persona_profile.communication.greeting_levels.archetypal, persona.role +
story/branch, project status from gitStatus, available commands from commands
where visibility includes key, handoff lookup in .aios/handoffs and
workflow-chains resolution, and signature_closing) so STEP 3 only constructs the
greeting, and leave the actual output/printing only in STEP 4 (including the
fallback that invokes
.aios-core/development/scripts/unified-activation-pipeline.js squad-creator).

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

STEP 5.5 marks the handoff artifact as consumed before confirming display.

The artifact mutation (line 32: Mark artifact as consumed: true) happens in the same instruction block as the suggestion display (lines 30–31). If the agent fails to surface the suggestion to the user (e.g., due to a context-assembly error), the artifact is silently consumed with no recovery path — the handoff hint is permanently lost.

Move the consumed flag write to after the 💡 Suggested: output is confirmed sent.

✏️ Proposed fix

       5.5. Check `.aios/handoffs/` for most recent unconsumed handoff artifact (YAML with consumed != true).
            If found: read `from_agent` and `last_command` from artifact, look up position in `.aios-core/data/workflow-chains.yaml` matching from_agent + last_command, and show: "💡 **Suggested:** `*{next_command} {args}`"
            If chain has multiple valid next steps, also show: "Also: `*{alt1}`, `*{alt2}`"
-           Mark artifact as consumed: true.
+           After outputting the suggestion above, mark artifact as consumed: true.
            If no artifact or no match found: skip this step silently.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.aios-core/development/agents/squad-creator.md around lines 29 - 33, Step
5.5 currently marks the handoff artifact as consumed in the same block that
assembles and displays the suggestion, which can permanently lose the hint if
sending fails; change the flow so you only set the artifact's consumed flag to
true after the "💡 **Suggested:** `*{next_command} {args}`" (and any "Also:"
alternatives) have been successfully output/confirmed sent, i.e., move the "Mark
artifact as consumed: true" write to occur after the suggestion
display/confirmation step and add minimal error handling to avoid consuming the
artifact on display failure.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Root cause: STEP 3 references visibility arrays absent from the commands schema.

This is the source file that syncs to .claude, .gemini, and .codex directories. STEP 3 sub-step 4 (Line 32) instructs filtering commands by a visibility array, but the commands section (Lines 173–211) uses a flat key-value format without visibility metadata.

The squad-creator.md agent demonstrates the correct approach — each command entry is an object with name, visibility, and description fields. Either adopt that schema here or simplify the greeting instruction to list a fixed set of core commands.

As per coding guidelines: "Check that persona_profile includes archetype, communication style, and greeting_levels" — these are present, but the commands visibility contract referenced in activation-instructions is broken.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.aios-core/development/agents/ux-design-expert.md around lines 26 - 32, The
greeting instructions reference a non-existent commands[].visibility field:
update the 'commands' section to use the object schema (each entry as {name,
visibility, description}) like squad-creator.md so STEP 3 sub-step 4 can filter
by visibility, or instead change the greeting step to list a fixed set of core
commands (remove visibility filtering) to match the current flat key-value
commands format; ensure you update the 'commands' symbol and any code that reads
it so it expects the chosen schema and keep the existing persona_profile checks
as-is.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

STEP 3 and STEP 4 are redundant, risking a double-output greeting.

STEP 3's own sub-steps (1–6) are all imperative Show: directives — they are the display. STEP 4 then instructs "Display the greeting assembled in STEP 3", which an LLM executing sequentially will interpret as a second display pass, potentially emitting the greeting twice.

If STEP 3 is truly an assembly phase, none of its sub-steps should say Show: — they should say Assemble: / Prepare:. If STEP 3 is the display phase, STEP 4 should be removed or reduced to a no-op acknowledgement (e.g., "Greeting now shown — proceed to STEP 5").

✏️ Option A — Make STEP 3 purely an assembly phase

-  - STEP 3: |
-      Display greeting using native context (zero JS execution):
-      1. Show: "{icon} {persona_profile.communication.greeting_levels.archetypal}" ...
-      2. Show: "**Role:** {persona.role}"
+  - STEP 3: |
+      Assemble greeting using native context (zero JS execution) — do NOT output yet:
+      1. Prepare: "{icon} {persona_profile.communication.greeting_levels.archetypal}" ...
+      2. Prepare: "**Role:** {persona.role}"
       ...
-  - STEP 4: Display the greeting assembled in STEP 3
+  - STEP 4: Output the greeting assembled in STEP 3 as a single block

✏️ Option B — Make STEP 3 the display phase and drop STEP 4

  - STEP 3: |
      Display greeting using native context (zero JS execution):
      1. Show: ...
      ...
-  - STEP 4: Display the greeting assembled in STEP 3
+  - STEP 4: Greeting displayed above — proceed to STEP 5

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

{args} in step 5.5 suggestion template has no defined data source.

Line 30 renders "💡 **Suggested:** \*{next_command} {args}`"but the workflow-chains.yaml lookup is only specified to returnnext_command. {args}` is never sourced, leaving the agent to hallucinate a value.

Either source args explicitly from the chain entry or drop it from the template:

✏️ Proposed fix

-          and show: "💡 **Suggested:** `*{next_command} {args}`"
+          and show: "💡 **Suggested:** `*{next_command}`" (append args from chain entry's `default_args` field if present)

Additionally, "most recent unconsumed handoff artifact" on line 29 leaves the recency criterion undefined (modification time? creation time? lexicographic sort?). Specifying it prevents non-deterministic artifact selection when multiple unconsumed handoffs exist.

📝 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

	5.5. Check `.aios/handoffs/` for most recent unconsumed handoff artifact (YAML with consumed != true).
	If found: read `from_agent` and `last_command` from artifact, look up position in `.aios-core/data/workflow-chains.yaml` matching from_agent + last_command, and show: "💡 **Suggested:** `*{next_command} {args}`"
	If chain has multiple valid next steps, also show: "Also: `*{alt1}`, `*{alt2}`"
	5.5. Check `.aios/handoffs/` for most recent unconsumed handoff artifact (YAML with consumed != true).
	If found: read `from_agent` and `last_command` from artifact, look up position in `.aios-core/data/workflow-chains.yaml` matching from_agent + last_command, and show: "💡 **Suggested:** `*{next_command}`" (append args from chain entry's `default_args` field if present)
	If chain has multiple valid next steps, also show: "Also: `*{alt1}`, `*{alt2}`"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.gemini/rules/AIOS/agents/squad-creator.md around lines 29 - 31, The
suggestion template uses an undefined `{args}` variable and the "most recent
unconsumed handoff artifact" recency is ambiguous; update the logic that reads
`.aios/handoffs/` to deterministically pick the most recent unconsumed artifact
by file modification time (mtime) and, when looking up the entry in
`.aios-core/data/workflow-chains.yaml`, either read a defined `args` field from
the matched chain entry and substitute it into the template `*{next_command}
{args}`, or remove `{args}` from the template entirely so it only shows
`*{next_command}`; ensure the code that performs the lookup (the workflow-chains
reader / matcher) is updated to expose an `args` property if you choose the
first option.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Grammar nit: "deviance" → "deviation".

"Deviance" carries a connotation of abnormal/undesirable behaviour. The intended word here is "deviation" (a neutral departure from a rule).

✏️ Proposed fix

-  - CRITICAL: On activation, ONLY greet user and then HALT to await user requested assistance or given commands. ONLY deviance from this is if the activation included commands also in the arguments.
+  - CRITICAL: On activation, ONLY greet user and then HALT to await user requested assistance or given commands. The ONLY deviation from this is if the activation included commands in its arguments.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.gemini/rules/AIOS/agents/squad-creator.md at line 47, Change the word
"deviance" to "deviation" in the rule text that reads "CRITICAL: On activation,
ONLY greet user and then HALT to await user requested assistance or given
commands. ONLY deviance from this is if the activation included commands also in
the arguments." — edit that sentence (the rule string containing "ONLY deviance
from this") to use "deviation" instead to correct the grammar while preserving
the original meaning.

[coderabbitai]

Actionable comments posted: 6

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

.codex/agents/squad-creator.md (1)

21-47: ⚠️ Potential issue | 🟠 Major

Resolve activation-rule conflict with handoff processing.
STEP 5.5 requires reading .aios/handoffs/ and .aios-core/data/workflow-chains.yaml and mutating artifacts, but Line 40-41 and Line 47 prohibit loading dependencies or doing anything beyond greeting on activation. This is a behavior contradiction that will cause noncompliant activation. Please either (a) explicitly carve out STEP 5.5 as an allowed activation-time exception and list the workflow chain file under dependencies (e.g., a new data: section), or (b) move handoff processing behind an explicit command so activation remains greeting-only.

✅ Example reconciliation (allow handoff processing + declare dependency)

 activation-instructions:
@@
-  - ONLY load dependency files when user selects them for execution via command or request of a task
+  - ONLY load dependency files when user selects them for execution via command or request of a task
+  - EXCEPTION: STEP 5.5 may read `.aios/handoffs/` and `.aios-core/data/workflow-chains.yaml` during activation
@@
 dependencies:
   tasks:
@@
   tools:
     - git # For checking author info
     - context7 # Look up library documentation
+  data:
+    - .aios-core/data/workflow-chains.yaml

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.codex/agents/squad-creator.md around lines 21 - 47, There is a conflict
between STEP 5.5 (which requires reading/mutating .aios/handoffs/ and
.aios-core/data/workflow-chains.yaml) and the activation rules that forbid
loading dependencies or doing work during activation; resolve by either (A)
explicitly carving out STEP 5.5 as an allowed activation exception: add a short
clause in the activation section stating "STEP 5.5 handoff processing is
permitted during activation" and declare the workflow chain file under
dependencies/data (e.g., list .aios-core/data/workflow-chains.yaml in a new
data: dependencies block) so the agent may load it, or (B) move STEP 5.5 out of
activation and implement it as an explicit quick-command (e.g.,
"*process-handoff") so handoff reading/mutation happens only when the user
invokes that command; update references to STEP 5.5 accordingly (in the greeting
flow and in agent.customization) so the behavior is unambiguous.

♻️ Duplicate comments (6)

.codex/agents/ux-design-expert.md (1)

25-33: Command visibility filter likely yields empty list.

STEP 3 expects command entries to have a visibility array, but the commands section is a plain map. This will probably produce no “Available Commands.”

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.codex/agents/ux-design-expert.md around lines 25 - 33, STEP 3's "Available
Commands" filter assumes each command item has a visibility array but the
'commands' data is a plain map, so the filter will yield an empty list; update
the logic that builds the Available Commands list to either (A) accept the
current map shape by treating each map value as a command object and checking
for a visibility property (defaulting to visible when missing), or (B) change
the 'commands' structure to an array of command objects that include a
visibility array. Locate the code that references "STEP 3", the 'commands'
section, and the visibility check (the function constructing the Available
Commands list) and implement one of these fixes so commands without a visibility
field are shown by default or convert commands to the expected array shape.

.claude/commands/AIOS/agents/squad-creator.md (1)

37-37: STEP 4 likely duplicates STEP 3 greeting output.

STEP 3 already instructs displaying the full greeting; STEP 4 repeats “Display the greeting assembled in STEP 3,” which risks a second output. This mirrors the previously flagged duplicate-greeting concern.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.claude/commands/AIOS/agents/squad-creator.md at line 37, STEP 4 duplicates
STEP 3's output and may cause the greeting to be printed twice; remove or change
STEP 4 so the greeting is only displayed once. Locate the "STEP 3" instruction
that says to "Display the full greeting" and the "STEP 4" line "Display the
greeting assembled in STEP 3" and either delete STEP 4 or replace it with a
non-output follow-up (e.g., confirmation or next action) to avoid duplicate
greeting printing.

.gemini/rules/AIOS/agents/squad-creator.md (3)

47-47: ⚠️ Potential issue | 🟡 Minor

deviance → deviation — grammar nit still unresolved from a prior review.

✏️ Proposed fix

-  - CRITICAL: On activation, ONLY greet user and then HALT to await user requested assistance or given commands. ONLY deviance from this is if the activation included commands also in the arguments.
+  - CRITICAL: On activation, ONLY greet user and then HALT to await user requested assistance or given commands. The ONLY deviation from this is if the activation included commands in its arguments.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.gemini/rules/AIOS/agents/squad-creator.md at line 47, Replace the incorrect
word "deviance" with "deviation" in the rule string "CRITICAL: On activation,
ONLY greet user and then HALT to await user requested assistance or given
commands. ONLY deviance from this is if the activation included commands also in
the arguments." so the sentence reads "...ONLY deviation from this is if the
activation included commands also in the arguments." Ensure you update only that
token and preserve capitalization and surrounding punctuation.

---

37-37: ⚠️ Potential issue | 🟡 Minor

STEP 4 still triggers a second display pass despite the AI summary claiming it was removed.

STEP 3's sub-steps are all Show: directives (immediate output to the user). STEP 4 at line 37 then instructs "Display the greeting assembled in STEP 3," which an LLM will interpret as a second render, producing a duplicate greeting. This issue was raised in a prior review and remains unaddressed.

Additionally, the AI summary states "STEP 4 is removed as a separate display path," which is inconsistent with the code — line 37 is unchanged.

✏️ Quickest fix — convert STEP 4 to a no-op acknowledgement

-  - STEP 4: Display the greeting assembled in STEP 3
+  - STEP 4: Greeting rendered inline in STEP 3 — proceed to STEP 5

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.gemini/rules/AIOS/agents/squad-creator.md at line 37, STEP 4 currently
re-issues the greeting ("STEP 4: Display the greeting assembled in STEP 3")
causing a duplicate output; change STEP 4 to a no-op acknowledgement (e.g.,
"STEP 4: Acknowledge greeting assembled in STEP 3 — do not re-display") so the
LLM won't treat it as a second Show directive; update the markdown entry for
STEP 4 in .gemini/rules/AIOS/agents/squad-creator.md and keep all STEP 3 Show:
sub-steps unchanged.

---

29-33: ⚠️ Potential issue | 🟡 Minor

{args} is still unsourced, and "most recent" artifact is still ambiguous — both flagged in a prior review.

1. Line 30 emits "💡 **Suggested:** \*{next_command} {args}`"but{args}` has no mapping to any field in the workflow-chains lookup. The agent will hallucinate a value.
2. Line 29 says "most recent unconsumed handoff artifact" without specifying the sort key (mtime, ctime, lexicographic). When multiple unconsumed handoffs exist the selection is non-deterministic.

✏️ Proposed fix

-          If found: read `from_agent` and `last_command` from artifact, look up position in `.aios-core/data/workflow-chains.yaml` matching from_agent + last_command, and show: "💡 **Suggested:** `*{next_command} {args}`"
+          If found: read `from_agent` and `last_command` from the artifact with the latest mtime, look up position in `.aios-core/data/workflow-chains.yaml` matching from_agent + last_command, and show: "💡 **Suggested:** `*{next_command}`" (append `default_args` from the chain entry if present)

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.gemini/rules/AIOS/agents/squad-creator.md around lines 29 - 33, The
suggested step emits an unsourced `{args}` and selects a non-deterministic “most
recent” artifact; fix by (1) sourcing args explicitly from the handoff YAML (use
the artifact field named args, or if absent omit `{args}` from the Suggested
string) when composing the message for `next_command`, and (2) define “most
recent unconsumed handoff artifact” deterministically by sorting candidates by
file modification time (mtime) descending before picking one; keep the rest of
the logic that reads `from_agent` and `last_command` and looks up
`.aios-core/data/workflow-chains.yaml` for `next_command`/alternatives and then
mark the chosen artifact’s consumed: true.

.claude/commands/AIOS/agents/ux-design-expert.md (1)

25-41: STEP 3 "Display greeting" header vs. STEP 4 "Display the greeting assembled in STEP 3".

The dual-display ambiguity between STEP 3 and STEP 4 was previously flagged. This comment is recorded for traceability — the prior comment was marked ✅ Addressed.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.claude/commands/AIOS/agents/ux-design-expert.md around lines 25 - 41, The
STEP 3 vs STEP 4 duplication creates ambiguity about where greeting assembly vs
rendering occurs; fix by making STEP 3 explicitly the assembly phase (retain all
substeps 1–6 and the handoff check in .aios/handoffs/ and the fallback node
.aios-core/development/scripts/unified-activation-pipeline.js ux-design-expert)
and change STEP 4 to a one-line, unambiguous "Render the assembled greeting" (or
remove STEP 4 entirely and rename STEP 3 to "Assemble and display greeting") so
readers can unambiguously locate the assembly logic (STEP 3) and the actual
display action (STEP 4) in the ux-design-expert flow.

🧹 Nitpick comments (1)

.gemini/rules/AIOS/agents/squad-creator.md (1)

27-34: Inner sub-step numbering (5, 5.5) collides cognitively with outer STEP 5.

STEP 3 contains sub-steps 1–6 (including 5.5), while the outer activation-instructions list also contains a STEP 5 ("HALT"). An LLM sequentially reading the document may conflate inner sub-step 5/5.5 with the outer STEP 5 halt directive, potentially halting mid-greeting. Using letter-based sub-steps (a–f) inside STEP 3 eliminates the ambiguity.

✏️ Proposed refactor — use letters for STEP 3 sub-steps

-      4. Show: "**Available Commands:**" ...
-      5. Show: "Type `*guide` for comprehensive usage instructions."
-      5.5. Check `.aios/handoffs/` ...
-      6. Show: "{persona_profile.communication.signature_closing}"
+      d. Show: "**Available Commands:**" ...
+      e. Show: "Type `*guide` for comprehensive usage instructions."
+      e.5. Check `.aios/handoffs/` ...
+      f. Show: "{persona_profile.communication.signature_closing}"

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.claude/commands/AIOS/agents/squad-creator.md:
- Around line 29-33: The handoff artifact should only be marked consumed when a
matching workflow chain is found and a suggestion is emitted; update the logic
that reads `.aios/handoffs/` to: read the most recent unconsumed artifact (where
`consumed != true`), look up `from_agent` + `last_command` in
`.aios-core/data/workflow-chains.yaml`, and if a `next_command` (and any alts)
is found show the suggested output (`"💡 **Suggested:** *{next_command} {args}"`
and `"Also: *{alt1}, *{alt2}"`), then set `consumed = true` on that artifact; if
no match is found, leave the artifact unchanged and skip silently. Ensure the
code paths that set `consumed` reference the same artifact object read earlier
so consumption only occurs after a successful match.

In @.claude/commands/AIOS/agents/ux-design-expert.md:
- Line 32: The instruction referencing "have 'key' in their visibility array" is
invalid because the commands block is a flat key: description map with no
visibility metadata; remove that undefined filter from the "Show: "**Available
Commands:**" — list commands..." line so the step simply lists all keys from the
commands block, or alternatively add a clear visibility field to each command in
the commands block and update the instruction to reference that field (choose
one approach and keep instructions and the commands block consistent).
- Around line 34-38: The handoff artifact is being marked consumed in STEP 5.5
during the STEP 3 assembly sequence which can permanently lose context if STEP 4
(greeting render) never completes; change the flow so that the `.aios/handoffs/`
artifact's consumed: true flag is only set after STEP 4 successfully renders the
greeting (i.e., move the consume action out of STEP 5.5 into a post-render
confirmation), and add a rollback or conditional path so if rendering fails or
FALLBACK is triggered the artifact is not marked (or is reverted) so the
suggested `from_agent` + `last_command` line can still be shown later.

In @.gemini/rules/AIOS/agents/ux-design-expert.md:
- Line 27: The greeting composes a duplicated emoji because the template
prefixes {icon} to persona_profile.communication.greeting_levels.archetypal
which already includes the emoji; fix by removing the redundant {icon} prefix
(or ensure archetypal value is emoji-free) so that the final string uses only
one emoji, i.e., update the template that builds "Show: '{icon}
{persona_profile.communication.greeting_levels.archetypal}' + permission badge"
to concatenate either {icon} OR
persona_profile.communication.greeting_levels.archetypal (not both) while
preserving the permission badge.
- Around line 34-38: The handoff artifact is being mutated (consumed: true)
during STEP 3 (assembly) which can permanently lose the suggested next command
if an error occurs before STEP 4 (greeting display); change the flow so the code
that writes consumed: true to the artifact in .aios/handoffs/ only runs after
STEP 4 successfully emits the greeting (or as a post-STEP-4 callback), i.e.,
defer the file-write that sets consumed to true (and any update to the
artifact’s consumed field) until after the display/greeting routine completes
successfully; ensure functions handling reading from_agent/last_command and
lookup in .aios-core/data/workflow-chains.yaml remain the same but move the
artifact mutation out of the assembly step and into the post-display path (or
guard it behind a success flag) so failures between assembly and display do not
mark the artifact consumed.
- Line 32: Line 32 refers to a non-existent visibility field; update the
instruction so it matches the current commands schema by removing the visibility
filter and instead "Show: '**Available Commands:**' — list all keys from the
'commands' section" (or, if selective display is desired, add a visibility
metadata property to each entry in the 'commands' map and then filter by that
property). Locate the 'commands' section and either (A) change the display rule
to enumerate every key in the commands map, or (B) add a per-command visibility
field (e.g., visibility: ['public'] ) and change the rule to filter commands
whose visibility array contains the given key.

---

Outside diff comments:
In @.codex/agents/squad-creator.md:
- Around line 21-47: There is a conflict between STEP 5.5 (which requires
reading/mutating .aios/handoffs/ and .aios-core/data/workflow-chains.yaml) and
the activation rules that forbid loading dependencies or doing work during
activation; resolve by either (A) explicitly carving out STEP 5.5 as an allowed
activation exception: add a short clause in the activation section stating "STEP
5.5 handoff processing is permitted during activation" and declare the workflow
chain file under dependencies/data (e.g., list
.aios-core/data/workflow-chains.yaml in a new data: dependencies block) so the
agent may load it, or (B) move STEP 5.5 out of activation and implement it as an
explicit quick-command (e.g., "*process-handoff") so handoff reading/mutation
happens only when the user invokes that command; update references to STEP 5.5
accordingly (in the greeting flow and in agent.customization) so the behavior is
unambiguous.

---

Duplicate comments:
In @.claude/commands/AIOS/agents/squad-creator.md:
- Line 37: STEP 4 duplicates STEP 3's output and may cause the greeting to be
printed twice; remove or change STEP 4 so the greeting is only displayed once.
Locate the "STEP 3" instruction that says to "Display the full greeting" and the
"STEP 4" line "Display the greeting assembled in STEP 3" and either delete STEP
4 or replace it with a non-output follow-up (e.g., confirmation or next action)
to avoid duplicate greeting printing.

In @.claude/commands/AIOS/agents/ux-design-expert.md:
- Around line 25-41: The STEP 3 vs STEP 4 duplication creates ambiguity about
where greeting assembly vs rendering occurs; fix by making STEP 3 explicitly the
assembly phase (retain all substeps 1–6 and the handoff check in .aios/handoffs/
and the fallback node
.aios-core/development/scripts/unified-activation-pipeline.js ux-design-expert)
and change STEP 4 to a one-line, unambiguous "Render the assembled greeting" (or
remove STEP 4 entirely and rename STEP 3 to "Assemble and display greeting") so
readers can unambiguously locate the assembly logic (STEP 3) and the actual
display action (STEP 4) in the ux-design-expert flow.

In @.codex/agents/ux-design-expert.md:
- Around line 25-33: STEP 3's "Available Commands" filter assumes each command
item has a visibility array but the 'commands' data is a plain map, so the
filter will yield an empty list; update the logic that builds the Available
Commands list to either (A) accept the current map shape by treating each map
value as a command object and checking for a visibility property (defaulting to
visible when missing), or (B) change the 'commands' structure to an array of
command objects that include a visibility array. Locate the code that references
"STEP 3", the 'commands' section, and the visibility check (the function
constructing the Available Commands list) and implement one of these fixes so
commands without a visibility field are shown by default or convert commands to
the expected array shape.

In @.gemini/rules/AIOS/agents/squad-creator.md:
- Line 47: Replace the incorrect word "deviance" with "deviation" in the rule
string "CRITICAL: On activation, ONLY greet user and then HALT to await user
requested assistance or given commands. ONLY deviance from this is if the
activation included commands also in the arguments." so the sentence reads
"...ONLY deviation from this is if the activation included commands also in the
arguments." Ensure you update only that token and preserve capitalization and
surrounding punctuation.
- Line 37: STEP 4 currently re-issues the greeting ("STEP 4: Display the
greeting assembled in STEP 3") causing a duplicate output; change STEP 4 to a
no-op acknowledgement (e.g., "STEP 4: Acknowledge greeting assembled in STEP 3 —
do not re-display") so the LLM won't treat it as a second Show directive; update
the markdown entry for STEP 4 in .gemini/rules/AIOS/agents/squad-creator.md and
keep all STEP 3 Show: sub-steps unchanged.
- Around line 29-33: The suggested step emits an unsourced `{args}` and selects
a non-deterministic “most recent” artifact; fix by (1) sourcing args explicitly
from the handoff YAML (use the artifact field named args, or if absent omit
`{args}` from the Suggested string) when composing the message for
`next_command`, and (2) define “most recent unconsumed handoff artifact”
deterministically by sorting candidates by file modification time (mtime)
descending before picking one; keep the rest of the logic that reads
`from_agent` and `last_command` and looks up
`.aios-core/data/workflow-chains.yaml` for `next_command`/alternatives and then
mark the chosen artifact’s consumed: true.

---

ℹ️ Review info

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ef94e75 and 39b9242.

📒 Files selected for processing (6)

• .claude/commands/AIOS/agents/squad-creator.md
• .claude/commands/AIOS/agents/ux-design-expert.md
• .codex/agents/squad-creator.md
• .codex/agents/ux-design-expert.md
• .gemini/rules/AIOS/agents/squad-creator.md
• .gemini/rules/AIOS/agents/ux-design-expert.md

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Clarify when the handoff artifact is marked consumed.

The current order reads as “mark consumed” even if no matching workflow chain is found, but the final line says to skip silently when no match is found. Please make the consumption conditional on a successful suggestion (or explicitly state the intended behavior) to avoid losing unconsumed handoffs.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.claude/commands/AIOS/agents/squad-creator.md around lines 29 - 33, The
handoff artifact should only be marked consumed when a matching workflow chain
is found and a suggestion is emitted; update the logic that reads
`.aios/handoffs/` to: read the most recent unconsumed artifact (where `consumed
!= true`), look up `from_agent` + `last_command` in
`.aios-core/data/workflow-chains.yaml`, and if a `next_command` (and any alts)
is found show the suggested output (`"💡 **Suggested:** *{next_command} {args}"`
and `"Also: *{alt1}, *{alt2}"`), then set `consumed = true` on that artifact; if
no match is found, leave the artifact unchanged and skip silently. Ensure the
code paths that set `consumed` reference the same artifact object read earlier
so consumption only occurs after a successful match.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Undefined visibility filter will produce a non-deterministic commands list.

The filter have 'key' in their visibility array references a visibility field that is not present anywhere in the commands block (lines 173–211). Every command there is a flat key: description pair with no metadata. An LLM parsing this instruction may display zero commands (strict interpretation) or all of them (lenient), making the greeting output unpredictable.

✏️ Suggested fix — remove the undefined filter

-      4. Show: "**Available Commands:**" — list commands from the 'commands' section above that have 'key' in their visibility array
+      4. Show: "**Available Commands:**" — list all commands from the 'commands' section above

📝 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

	4. Show: "**Available Commands:**" — list commands from the 'commands' section above that have 'key' in their visibility array
	4. Show: "**Available Commands:**" — list all commands from the 'commands' section above

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.claude/commands/AIOS/agents/ux-design-expert.md at line 32, The instruction
referencing "have 'key' in their visibility array" is invalid because the
commands block is a flat key: description map with no visibility metadata;
remove that undefined filter from the "Show: "**Available Commands:**" — list
commands..." line so the step simply lists all keys from the commands block, or
alternatively add a clear visibility field to each command in the commands block
and update the instruction to reference that field (choose one approach and keep
instructions and the commands block consistent).

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Handoff artifact marked consumed before STEP 4 renders the greeting.

Step 5.5 writes consumed: true while still inside the STEP 3 assembly sequence. STEP 4 is the point where the assembled greeting is actually rendered to the user. If STEP 4 is truncated or never reached (e.g., context-limit cut-off, native greeting failure triggering the FALLBACK), the artifact is permanently consumed but the 💡 Suggested: line was never shown — silently losing the handoff context.

✏️ Suggested fix — defer consumed marking to post-display

      5.5. Check `.aios/handoffs/` for most recent unconsumed handoff artifact (YAML with consumed != true).
           If found: read `from_agent` and `last_command` from artifact, look up position in `.aios-core/data/workflow-chains.yaml` matching from_agent + last_command, and show: "💡 **Suggested:** `*{next_command} {args}`"
           If chain has multiple valid next steps, also show: "Also: `*{alt1}`, `*{alt2}`"
-          Mark artifact as consumed: true.
           If no artifact or no match found: skip this step silently.
      6. Show: "{persona_profile.communication.signature_closing}"
      # FALLBACK: If native greeting fails, run: node .aios-core/development/scripts/unified-activation-pipeline.js ux-design-expert
  - STEP 4: Display the greeting assembled in STEP 3
+    - After STEP 4 completes: if a handoff artifact was matched in STEP 3 sub-step 5.5, mark it as consumed: true

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.claude/commands/AIOS/agents/ux-design-expert.md around lines 34 - 38, The
handoff artifact is being marked consumed in STEP 5.5 during the STEP 3 assembly
sequence which can permanently lose context if STEP 4 (greeting render) never
completes; change the flow so that the `.aios/handoffs/` artifact's consumed:
true flag is only set after STEP 4 successfully renders the greeting (i.e., move
the consume action out of STEP 5.5 into a post-render confirmation), and add a
rollback or conditional path so if rendering fails or FALLBACK is triggered the
artifact is not marked (or is reverted) so the suggested `from_agent` +
`last_command` line can still be shown later.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Redundant {icon} prefix produces a doubled emoji in the greeting.

{icon} resolves to 🎨, and greeting_levels.archetypal (line 148) is already '🎨 Uma the Empathizer ready to empathize!'. The composed output would be 🎨 🎨 Uma the Empathizer ready to empathize! [⚠️ Ask].

🔧 Proposed fix

-      1. Show: "{icon} {persona_profile.communication.greeting_levels.archetypal}" + permission badge from current permission mode (e.g., [⚠️ Ask], [🟢 Auto], [🔍 Explore])
+      1. Show: "{persona_profile.communication.greeting_levels.archetypal}" + permission badge from current permission mode (e.g., [⚠️ Ask], [🟢 Auto], [🔍 Explore])

📝 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

	1. Show: "{icon} {persona_profile.communication.greeting_levels.archetypal}" + permission badge from current permission mode (e.g., [⚠️ Ask], [🟢 Auto], [🔍 Explore])
	1. Show: "{persona_profile.communication.greeting_levels.archetypal}" + permission badge from current permission mode (e.g., [⚠️ Ask], [🟢 Auto], [🔍 Explore])

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.gemini/rules/AIOS/agents/ux-design-expert.md at line 27, The greeting
composes a duplicated emoji because the template prefixes {icon} to
persona_profile.communication.greeting_levels.archetypal which already includes
the emoji; fix by removing the redundant {icon} prefix (or ensure archetypal
value is emoji-free) so that the final string uses only one emoji, i.e., update
the template that builds "Show: '{icon}
{persona_profile.communication.greeting_levels.archetypal}' + permission badge"
to concatenate either {icon} OR
persona_profile.communication.greeting_levels.archetypal (not both) while
preserving the permission badge.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

# First, let's locate and read the specific file mentioned
find . -name "ux-design-expert.md" -type f

Repository: SynkraAI/aios-core

Length of output: 339

---

🏁 Script executed:

# Read the file to check the content around line 32 and the commands section
cat -n .gemini/rules/AIOS/agents/ux-design-expert.md | head -50

Repository: SynkraAI/aios-core

Length of output: 3980

---

🏁 Script executed:

# Get the commands section (around lines 173-211)
cat -n .gemini/rules/AIOS/agents/ux-design-expert.md | sed -n '170,220p'

Repository: SynkraAI/aios-core

Length of output: 2577

---

🏁 Script executed:

# Search for all references to "visibility" in agent files to understand the convention
rg "visibility" --type md -B3 -A3 -g "*agents*"

Repository: SynkraAI/aios-core

Length of output: 44

---

Line 32 references an undefined visibility field that doesn't exist in the commands schema.

The instruction on line 32 filters commands by visibility array, but all commands (lines 173–211) are plain key: 'description' pairs with no metadata. The LLM will be unable to apply this filter, resulting in either showing all commands or none — neither matches the intent. No sibling agent files use a visibility convention either.

Simplify the filter to match the current schema:

-      4. Show: "**Available Commands:**" — list commands from the 'commands' section above that have 'key' in their visibility array
+      4. Show: "**Available Commands:**" — list all commands from the 'commands' section above

Alternatively, add visibility metadata to commands if selective display is needed in the future.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.gemini/rules/AIOS/agents/ux-design-expert.md at line 32, Line 32 refers to
a non-existent visibility field; update the instruction so it matches the
current commands schema by removing the visibility filter and instead "Show:
'**Available Commands:**' — list all keys from the 'commands' section" (or, if
selective display is desired, add a visibility metadata property to each entry
in the 'commands' map and then filter by that property). Locate the 'commands'
section and either (A) change the display rule to enumerate every key in the
commands map, or (B) add a per-command visibility field (e.g., visibility:
['public'] ) and change the rule to filter commands whose visibility array
contains the given key.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Handoff artifact marked consumed: true before the greeting is displayed — suggestion can be silently lost.

The mutation happens in STEP 3 (assembly), before STEP 4 emits the greeting. If any failure occurs between assembly and display (context limit, error, restart), the artifact is permanently consumed and the user never sees the suggested next command.

Move the consumption marking to after display, or scope it as a post-STEP-4 action:

🔧 Proposed fix — defer mutation to after display

       5.5. Check `.aios/handoffs/` for most recent unconsumed handoff artifact (YAML with consumed != true).
            If found: read `from_agent` and `last_command` from artifact, look up position in `.aios-core/data/workflow-chains.yaml` matching from_agent + last_command, and show: "💡 **Suggested:** `*{next_command} {args}`"
            If chain has multiple valid next steps, also show: "Also: `*{alt1}`, `*{alt2}`"
-           Mark artifact as consumed: true.
            If no artifact or no match found: skip this step silently.
       6. Show: "{persona_profile.communication.signature_closing}"
       # FALLBACK: If native greeting fails, run: node .aios-core/development/scripts/unified-activation-pipeline.js ux-design-expert
   - STEP 4: Display the greeting assembled in STEP 3
+  - STEP 4.1: If handoff artifact was found and suggestion was shown in STEP 3 (5.5), mark artifact as consumed: true.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.gemini/rules/AIOS/agents/ux-design-expert.md around lines 34 - 38, The
handoff artifact is being mutated (consumed: true) during STEP 3 (assembly)
which can permanently lose the suggested next command if an error occurs before
STEP 4 (greeting display); change the flow so the code that writes consumed:
true to the artifact in .aios/handoffs/ only runs after STEP 4 successfully
emits the greeting (or as a post-STEP-4 callback), i.e., defer the file-write
that sets consumed to true (and any update to the artifact’s consumed field)
until after the display/greeting routine completes successfully; ensure
functions handling reading from_agent/last_command and lookup in
.aios-core/data/workflow-chains.yaml remain the same but move the artifact
mutation out of the assembly step and into the post-display path (or guard it
behind a success flag) so failures between assembly and display do not mark the
artifact consumed.

All issues addressed in commits 946f3a5 and aa15bfe. CI fully green.