@askexenow/exe-os 0.9.86 → 0.9.87

package/dist/bin/agentic-ontology-backfill.js

@@ -3382,6 +3382,24 @@ var init_platform_procedures = __esm({
         priority: "p0",
         content: "When an agent encounters a suspected Exe OS bug, update breakage, MCP/tool failure, installer issue, memory/orchestration defect, or customer-local patch need, it MUST use create_bug_report. Do this before or alongside any local workaround so the report reaches AskExe support directly via the customer's license. Do NOT ask the founder for permission to file a required bug report. If create_bug_report is deferred/lazy-loaded, load it and call it. If it is unavailable in the live MCP surface, report 'create_bug_report unavailable in this session' and save a local report in exe/output \u2014 never claim the tool does not exist unless the live MCP surface was checked. If upstream delivery fails, call support_test (MCP) and include its result in the local report so AskExe can distinguish customer setup, license provisioning, and server intake issues; only ask the founder to run `exe-os support test` if MCP is disconnected/unavailable. Classify first: upstream_bug = reproducible exe-os/platform defect; customer_customization = identity, behavior, procedure, config, branding, workflow preference that belongs in customer-owned layers; emergency_hotfix = temporary local patch. For upstream bugs/emergency hotfixes include version, repro steps, expected/actual, files changed, workaround, and local diff summary. Avoid permanent platform-code patches unless founder approves; if a hotfix is unavoidable, document it in the bug report and re-check after npm update."
       },
+      {
+        title: "Bug report status check \u2014 surface available fixes on boot",
+        domain: "support",
+        priority: "p1",
+        content: "Once per session (COO boot only, never repeat), call list_my_bug_reports to check if any previously filed bug reports have been fixed by AskExe. If any report has status 'fixed' with a fixed_version, surface it to the founder immediately: '\u{1F527} N bug fix(es) available \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no reports exist or none are fixed, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+      },
+      {
+        title: "Feature request triage \u2014 upstream feature vs local customization",
+        domain: "support",
+        priority: "p0",
+        content: "When an agent or founder identifies a desired capability that exe-os does not yet provide, the COO (or equivalent coordinator) must decide: is this a local customization (identity, behavior, procedure, config, branding, workflow preference that can be configured in customer-owned layers) or an upstream feature request (a platform capability that requires changes to exe-os code, shipped via npm update)? Local customizations: implement immediately using store_behavior, update_identity, company_procedure, or config changes. Upstream features: use create_feature_request to submit to AskExe. Include use case, business impact, and current workaround. Do NOT ask the founder for permission to file a feature request \u2014 file it proactively when the need is clear."
+      },
+      {
+        title: "Feature request status check \u2014 surface shipped features on boot",
+        domain: "support",
+        priority: "p1",
+        content: "Once per session (COO boot only, never repeat), call list_my_feature_requests to check if any previously filed feature requests have been shipped by AskExe. If any request has status 'shipped' with a shipped_version, surface it to the founder immediately: '\u{1F680} N feature(s) shipped \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no requests exist or none are shipped, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+      },
       // --- Operations ---
       {
         title: "Managers must supervise deployed workers",

package/dist/bin/agentic-reflection-backfill.js

@@ -3382,6 +3382,24 @@ var init_platform_procedures = __esm({
         priority: "p0",
         content: "When an agent encounters a suspected Exe OS bug, update breakage, MCP/tool failure, installer issue, memory/orchestration defect, or customer-local patch need, it MUST use create_bug_report. Do this before or alongside any local workaround so the report reaches AskExe support directly via the customer's license. Do NOT ask the founder for permission to file a required bug report. If create_bug_report is deferred/lazy-loaded, load it and call it. If it is unavailable in the live MCP surface, report 'create_bug_report unavailable in this session' and save a local report in exe/output \u2014 never claim the tool does not exist unless the live MCP surface was checked. If upstream delivery fails, call support_test (MCP) and include its result in the local report so AskExe can distinguish customer setup, license provisioning, and server intake issues; only ask the founder to run `exe-os support test` if MCP is disconnected/unavailable. Classify first: upstream_bug = reproducible exe-os/platform defect; customer_customization = identity, behavior, procedure, config, branding, workflow preference that belongs in customer-owned layers; emergency_hotfix = temporary local patch. For upstream bugs/emergency hotfixes include version, repro steps, expected/actual, files changed, workaround, and local diff summary. Avoid permanent platform-code patches unless founder approves; if a hotfix is unavoidable, document it in the bug report and re-check after npm update."
       },
+      {
+        title: "Bug report status check \u2014 surface available fixes on boot",
+        domain: "support",
+        priority: "p1",
+        content: "Once per session (COO boot only, never repeat), call list_my_bug_reports to check if any previously filed bug reports have been fixed by AskExe. If any report has status 'fixed' with a fixed_version, surface it to the founder immediately: '\u{1F527} N bug fix(es) available \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no reports exist or none are fixed, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+      },
+      {
+        title: "Feature request triage \u2014 upstream feature vs local customization",
+        domain: "support",
+        priority: "p0",
+        content: "When an agent or founder identifies a desired capability that exe-os does not yet provide, the COO (or equivalent coordinator) must decide: is this a local customization (identity, behavior, procedure, config, branding, workflow preference that can be configured in customer-owned layers) or an upstream feature request (a platform capability that requires changes to exe-os code, shipped via npm update)? Local customizations: implement immediately using store_behavior, update_identity, company_procedure, or config changes. Upstream features: use create_feature_request to submit to AskExe. Include use case, business impact, and current workaround. Do NOT ask the founder for permission to file a feature request \u2014 file it proactively when the need is clear."
+      },
+      {
+        title: "Feature request status check \u2014 surface shipped features on boot",
+        domain: "support",
+        priority: "p1",
+        content: "Once per session (COO boot only, never repeat), call list_my_feature_requests to check if any previously filed feature requests have been shipped by AskExe. If any request has status 'shipped' with a shipped_version, surface it to the founder immediately: '\u{1F680} N feature(s) shipped \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no requests exist or none are shipped, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+      },
       // --- Operations ---
       {
         title: "Managers must supervise deployed workers",

package/dist/bin/agentic-semantic-label.js

@@ -3382,6 +3382,24 @@ var init_platform_procedures = __esm({
         priority: "p0",
         content: "When an agent encounters a suspected Exe OS bug, update breakage, MCP/tool failure, installer issue, memory/orchestration defect, or customer-local patch need, it MUST use create_bug_report. Do this before or alongside any local workaround so the report reaches AskExe support directly via the customer's license. Do NOT ask the founder for permission to file a required bug report. If create_bug_report is deferred/lazy-loaded, load it and call it. If it is unavailable in the live MCP surface, report 'create_bug_report unavailable in this session' and save a local report in exe/output \u2014 never claim the tool does not exist unless the live MCP surface was checked. If upstream delivery fails, call support_test (MCP) and include its result in the local report so AskExe can distinguish customer setup, license provisioning, and server intake issues; only ask the founder to run `exe-os support test` if MCP is disconnected/unavailable. Classify first: upstream_bug = reproducible exe-os/platform defect; customer_customization = identity, behavior, procedure, config, branding, workflow preference that belongs in customer-owned layers; emergency_hotfix = temporary local patch. For upstream bugs/emergency hotfixes include version, repro steps, expected/actual, files changed, workaround, and local diff summary. Avoid permanent platform-code patches unless founder approves; if a hotfix is unavoidable, document it in the bug report and re-check after npm update."
       },
+      {
+        title: "Bug report status check \u2014 surface available fixes on boot",
+        domain: "support",
+        priority: "p1",
+        content: "Once per session (COO boot only, never repeat), call list_my_bug_reports to check if any previously filed bug reports have been fixed by AskExe. If any report has status 'fixed' with a fixed_version, surface it to the founder immediately: '\u{1F527} N bug fix(es) available \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no reports exist or none are fixed, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+      },
+      {
+        title: "Feature request triage \u2014 upstream feature vs local customization",
+        domain: "support",
+        priority: "p0",
+        content: "When an agent or founder identifies a desired capability that exe-os does not yet provide, the COO (or equivalent coordinator) must decide: is this a local customization (identity, behavior, procedure, config, branding, workflow preference that can be configured in customer-owned layers) or an upstream feature request (a platform capability that requires changes to exe-os code, shipped via npm update)? Local customizations: implement immediately using store_behavior, update_identity, company_procedure, or config changes. Upstream features: use create_feature_request to submit to AskExe. Include use case, business impact, and current workaround. Do NOT ask the founder for permission to file a feature request \u2014 file it proactively when the need is clear."
+      },
+      {
+        title: "Feature request status check \u2014 surface shipped features on boot",
+        domain: "support",
+        priority: "p1",
+        content: "Once per session (COO boot only, never repeat), call list_my_feature_requests to check if any previously filed feature requests have been shipped by AskExe. If any request has status 'shipped' with a shipped_version, surface it to the founder immediately: '\u{1F680} N feature(s) shipped \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no requests exist or none are shipped, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+      },
       // --- Operations ---
       {
         title: "Managers must supervise deployed workers",

package/dist/bin/backfill-conversations.js

@@ -3522,6 +3522,24 @@ var init_platform_procedures = __esm({
         priority: "p0",
         content: "When an agent encounters a suspected Exe OS bug, update breakage, MCP/tool failure, installer issue, memory/orchestration defect, or customer-local patch need, it MUST use create_bug_report. Do this before or alongside any local workaround so the report reaches AskExe support directly via the customer's license. Do NOT ask the founder for permission to file a required bug report. If create_bug_report is deferred/lazy-loaded, load it and call it. If it is unavailable in the live MCP surface, report 'create_bug_report unavailable in this session' and save a local report in exe/output \u2014 never claim the tool does not exist unless the live MCP surface was checked. If upstream delivery fails, call support_test (MCP) and include its result in the local report so AskExe can distinguish customer setup, license provisioning, and server intake issues; only ask the founder to run `exe-os support test` if MCP is disconnected/unavailable. Classify first: upstream_bug = reproducible exe-os/platform defect; customer_customization = identity, behavior, procedure, config, branding, workflow preference that belongs in customer-owned layers; emergency_hotfix = temporary local patch. For upstream bugs/emergency hotfixes include version, repro steps, expected/actual, files changed, workaround, and local diff summary. Avoid permanent platform-code patches unless founder approves; if a hotfix is unavoidable, document it in the bug report and re-check after npm update."
       },
+      {
+        title: "Bug report status check \u2014 surface available fixes on boot",
+        domain: "support",
+        priority: "p1",
+        content: "Once per session (COO boot only, never repeat), call list_my_bug_reports to check if any previously filed bug reports have been fixed by AskExe. If any report has status 'fixed' with a fixed_version, surface it to the founder immediately: '\u{1F527} N bug fix(es) available \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no reports exist or none are fixed, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+      },
+      {
+        title: "Feature request triage \u2014 upstream feature vs local customization",
+        domain: "support",
+        priority: "p0",
+        content: "When an agent or founder identifies a desired capability that exe-os does not yet provide, the COO (or equivalent coordinator) must decide: is this a local customization (identity, behavior, procedure, config, branding, workflow preference that can be configured in customer-owned layers) or an upstream feature request (a platform capability that requires changes to exe-os code, shipped via npm update)? Local customizations: implement immediately using store_behavior, update_identity, company_procedure, or config changes. Upstream features: use create_feature_request to submit to AskExe. Include use case, business impact, and current workaround. Do NOT ask the founder for permission to file a feature request \u2014 file it proactively when the need is clear."
+      },
+      {
+        title: "Feature request status check \u2014 surface shipped features on boot",
+        domain: "support",
+        priority: "p1",
+        content: "Once per session (COO boot only, never repeat), call list_my_feature_requests to check if any previously filed feature requests have been shipped by AskExe. If any request has status 'shipped' with a shipped_version, surface it to the founder immediately: '\u{1F680} N feature(s) shipped \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no requests exist or none are shipped, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+      },
       // --- Operations ---
       {
         title: "Managers must supervise deployed workers",

package/dist/bin/backfill-responses.js

@@ -3522,6 +3522,24 @@ var init_platform_procedures = __esm({
         priority: "p0",
         content: "When an agent encounters a suspected Exe OS bug, update breakage, MCP/tool failure, installer issue, memory/orchestration defect, or customer-local patch need, it MUST use create_bug_report. Do this before or alongside any local workaround so the report reaches AskExe support directly via the customer's license. Do NOT ask the founder for permission to file a required bug report. If create_bug_report is deferred/lazy-loaded, load it and call it. If it is unavailable in the live MCP surface, report 'create_bug_report unavailable in this session' and save a local report in exe/output \u2014 never claim the tool does not exist unless the live MCP surface was checked. If upstream delivery fails, call support_test (MCP) and include its result in the local report so AskExe can distinguish customer setup, license provisioning, and server intake issues; only ask the founder to run `exe-os support test` if MCP is disconnected/unavailable. Classify first: upstream_bug = reproducible exe-os/platform defect; customer_customization = identity, behavior, procedure, config, branding, workflow preference that belongs in customer-owned layers; emergency_hotfix = temporary local patch. For upstream bugs/emergency hotfixes include version, repro steps, expected/actual, files changed, workaround, and local diff summary. Avoid permanent platform-code patches unless founder approves; if a hotfix is unavoidable, document it in the bug report and re-check after npm update."
       },
+      {
+        title: "Bug report status check \u2014 surface available fixes on boot",
+        domain: "support",
+        priority: "p1",
+        content: "Once per session (COO boot only, never repeat), call list_my_bug_reports to check if any previously filed bug reports have been fixed by AskExe. If any report has status 'fixed' with a fixed_version, surface it to the founder immediately: '\u{1F527} N bug fix(es) available \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no reports exist or none are fixed, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+      },
+      {
+        title: "Feature request triage \u2014 upstream feature vs local customization",
+        domain: "support",
+        priority: "p0",
+        content: "When an agent or founder identifies a desired capability that exe-os does not yet provide, the COO (or equivalent coordinator) must decide: is this a local customization (identity, behavior, procedure, config, branding, workflow preference that can be configured in customer-owned layers) or an upstream feature request (a platform capability that requires changes to exe-os code, shipped via npm update)? Local customizations: implement immediately using store_behavior, update_identity, company_procedure, or config changes. Upstream features: use create_feature_request to submit to AskExe. Include use case, business impact, and current workaround. Do NOT ask the founder for permission to file a feature request \u2014 file it proactively when the need is clear."
+      },
+      {
+        title: "Feature request status check \u2014 surface shipped features on boot",
+        domain: "support",
+        priority: "p1",
+        content: "Once per session (COO boot only, never repeat), call list_my_feature_requests to check if any previously filed feature requests have been shipped by AskExe. If any request has status 'shipped' with a shipped_version, surface it to the founder immediately: '\u{1F680} N feature(s) shipped \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no requests exist or none are shipped, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+      },
       // --- Operations ---
       {
         title: "Managers must supervise deployed workers",

package/dist/bin/backfill-vectors.js

@@ -3518,6 +3518,24 @@ var init_platform_procedures = __esm({
         priority: "p0",
         content: "When an agent encounters a suspected Exe OS bug, update breakage, MCP/tool failure, installer issue, memory/orchestration defect, or customer-local patch need, it MUST use create_bug_report. Do this before or alongside any local workaround so the report reaches AskExe support directly via the customer's license. Do NOT ask the founder for permission to file a required bug report. If create_bug_report is deferred/lazy-loaded, load it and call it. If it is unavailable in the live MCP surface, report 'create_bug_report unavailable in this session' and save a local report in exe/output \u2014 never claim the tool does not exist unless the live MCP surface was checked. If upstream delivery fails, call support_test (MCP) and include its result in the local report so AskExe can distinguish customer setup, license provisioning, and server intake issues; only ask the founder to run `exe-os support test` if MCP is disconnected/unavailable. Classify first: upstream_bug = reproducible exe-os/platform defect; customer_customization = identity, behavior, procedure, config, branding, workflow preference that belongs in customer-owned layers; emergency_hotfix = temporary local patch. For upstream bugs/emergency hotfixes include version, repro steps, expected/actual, files changed, workaround, and local diff summary. Avoid permanent platform-code patches unless founder approves; if a hotfix is unavoidable, document it in the bug report and re-check after npm update."
       },
+      {
+        title: "Bug report status check \u2014 surface available fixes on boot",
+        domain: "support",
+        priority: "p1",
+        content: "Once per session (COO boot only, never repeat), call list_my_bug_reports to check if any previously filed bug reports have been fixed by AskExe. If any report has status 'fixed' with a fixed_version, surface it to the founder immediately: '\u{1F527} N bug fix(es) available \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no reports exist or none are fixed, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+      },
+      {
+        title: "Feature request triage \u2014 upstream feature vs local customization",
+        domain: "support",
+        priority: "p0",
+        content: "When an agent or founder identifies a desired capability that exe-os does not yet provide, the COO (or equivalent coordinator) must decide: is this a local customization (identity, behavior, procedure, config, branding, workflow preference that can be configured in customer-owned layers) or an upstream feature request (a platform capability that requires changes to exe-os code, shipped via npm update)? Local customizations: implement immediately using store_behavior, update_identity, company_procedure, or config changes. Upstream features: use create_feature_request to submit to AskExe. Include use case, business impact, and current workaround. Do NOT ask the founder for permission to file a feature request \u2014 file it proactively when the need is clear."
+      },
+      {
+        title: "Feature request status check \u2014 surface shipped features on boot",
+        domain: "support",
+        priority: "p1",
+        content: "Once per session (COO boot only, never repeat), call list_my_feature_requests to check if any previously filed feature requests have been shipped by AskExe. If any request has status 'shipped' with a shipped_version, surface it to the founder immediately: '\u{1F680} N feature(s) shipped \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no requests exist or none are shipped, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+      },
       // --- Operations ---
       {
         title: "Managers must supervise deployed workers",

package/dist/bin/bulk-sync-postgres.js

@@ -3690,6 +3690,24 @@ var init_platform_procedures = __esm({
         priority: "p0",
         content: "When an agent encounters a suspected Exe OS bug, update breakage, MCP/tool failure, installer issue, memory/orchestration defect, or customer-local patch need, it MUST use create_bug_report. Do this before or alongside any local workaround so the report reaches AskExe support directly via the customer's license. Do NOT ask the founder for permission to file a required bug report. If create_bug_report is deferred/lazy-loaded, load it and call it. If it is unavailable in the live MCP surface, report 'create_bug_report unavailable in this session' and save a local report in exe/output \u2014 never claim the tool does not exist unless the live MCP surface was checked. If upstream delivery fails, call support_test (MCP) and include its result in the local report so AskExe can distinguish customer setup, license provisioning, and server intake issues; only ask the founder to run `exe-os support test` if MCP is disconnected/unavailable. Classify first: upstream_bug = reproducible exe-os/platform defect; customer_customization = identity, behavior, procedure, config, branding, workflow preference that belongs in customer-owned layers; emergency_hotfix = temporary local patch. For upstream bugs/emergency hotfixes include version, repro steps, expected/actual, files changed, workaround, and local diff summary. Avoid permanent platform-code patches unless founder approves; if a hotfix is unavoidable, document it in the bug report and re-check after npm update."
       },
+      {
+        title: "Bug report status check \u2014 surface available fixes on boot",
+        domain: "support",
+        priority: "p1",
+        content: "Once per session (COO boot only, never repeat), call list_my_bug_reports to check if any previously filed bug reports have been fixed by AskExe. If any report has status 'fixed' with a fixed_version, surface it to the founder immediately: '\u{1F527} N bug fix(es) available \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no reports exist or none are fixed, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+      },
+      {
+        title: "Feature request triage \u2014 upstream feature vs local customization",
+        domain: "support",
+        priority: "p0",
+        content: "When an agent or founder identifies a desired capability that exe-os does not yet provide, the COO (or equivalent coordinator) must decide: is this a local customization (identity, behavior, procedure, config, branding, workflow preference that can be configured in customer-owned layers) or an upstream feature request (a platform capability that requires changes to exe-os code, shipped via npm update)? Local customizations: implement immediately using store_behavior, update_identity, company_procedure, or config changes. Upstream features: use create_feature_request to submit to AskExe. Include use case, business impact, and current workaround. Do NOT ask the founder for permission to file a feature request \u2014 file it proactively when the need is clear."
+      },
+      {
+        title: "Feature request status check \u2014 surface shipped features on boot",
+        domain: "support",
+        priority: "p1",
+        content: "Once per session (COO boot only, never repeat), call list_my_feature_requests to check if any previously filed feature requests have been shipped by AskExe. If any request has status 'shipped' with a shipped_version, surface it to the founder immediately: '\u{1F680} N feature(s) shipped \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no requests exist or none are shipped, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+      },
       // --- Operations ---
       {
         title: "Managers must supervise deployed workers",

package/dist/bin/cleanup-stale-review-tasks.js

@@ -4165,6 +4165,24 @@ var init_platform_procedures = __esm({
         priority: "p0",
         content: "When an agent encounters a suspected Exe OS bug, update breakage, MCP/tool failure, installer issue, memory/orchestration defect, or customer-local patch need, it MUST use create_bug_report. Do this before or alongside any local workaround so the report reaches AskExe support directly via the customer's license. Do NOT ask the founder for permission to file a required bug report. If create_bug_report is deferred/lazy-loaded, load it and call it. If it is unavailable in the live MCP surface, report 'create_bug_report unavailable in this session' and save a local report in exe/output \u2014 never claim the tool does not exist unless the live MCP surface was checked. If upstream delivery fails, call support_test (MCP) and include its result in the local report so AskExe can distinguish customer setup, license provisioning, and server intake issues; only ask the founder to run `exe-os support test` if MCP is disconnected/unavailable. Classify first: upstream_bug = reproducible exe-os/platform defect; customer_customization = identity, behavior, procedure, config, branding, workflow preference that belongs in customer-owned layers; emergency_hotfix = temporary local patch. For upstream bugs/emergency hotfixes include version, repro steps, expected/actual, files changed, workaround, and local diff summary. Avoid permanent platform-code patches unless founder approves; if a hotfix is unavoidable, document it in the bug report and re-check after npm update."
       },
+      {
+        title: "Bug report status check \u2014 surface available fixes on boot",
+        domain: "support",
+        priority: "p1",
+        content: "Once per session (COO boot only, never repeat), call list_my_bug_reports to check if any previously filed bug reports have been fixed by AskExe. If any report has status 'fixed' with a fixed_version, surface it to the founder immediately: '\u{1F527} N bug fix(es) available \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no reports exist or none are fixed, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+      },
+      {
+        title: "Feature request triage \u2014 upstream feature vs local customization",
+        domain: "support",
+        priority: "p0",
+        content: "When an agent or founder identifies a desired capability that exe-os does not yet provide, the COO (or equivalent coordinator) must decide: is this a local customization (identity, behavior, procedure, config, branding, workflow preference that can be configured in customer-owned layers) or an upstream feature request (a platform capability that requires changes to exe-os code, shipped via npm update)? Local customizations: implement immediately using store_behavior, update_identity, company_procedure, or config changes. Upstream features: use create_feature_request to submit to AskExe. Include use case, business impact, and current workaround. Do NOT ask the founder for permission to file a feature request \u2014 file it proactively when the need is clear."
+      },
+      {
+        title: "Feature request status check \u2014 surface shipped features on boot",
+        domain: "support",
+        priority: "p1",
+        content: "Once per session (COO boot only, never repeat), call list_my_feature_requests to check if any previously filed feature requests have been shipped by AskExe. If any request has status 'shipped' with a shipped_version, surface it to the founder immediately: '\u{1F680} N feature(s) shipped \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no requests exist or none are shipped, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+      },
       // --- Operations ---
       {
         title: "Managers must supervise deployed workers",

package/dist/bin/cli.js

@@ -1229,6 +1229,15 @@ async function registerMcpServer(packageRoot, homeDir = os6.homedir()) {
     delete claudeJson.mcpServers[MCP_LEGACY_KEY];
     process.stderr.write("exe-os: migrated MCP server key exe-mem \u2192 exe-os\n");
   }
+  if (claudeJson.projects) {
+    for (const [projectPath, projectConfig] of Object.entries(claudeJson.projects)) {
+      if (projectConfig.mcpServers?.[MCP_LEGACY_KEY]) {
+        delete projectConfig.mcpServers[MCP_LEGACY_KEY];
+        process.stderr.write(`exe-os: removed stale project-level exe-mem from ${projectPath}
+`);
+      }
+    }
+  }
   const currentOs = claudeJson.mcpServers[MCP_PRIMARY_KEY];
   const osMatches = currentOs && JSON.stringify(currentOs) === JSON.stringify(newEntry);
   if (osMatches) {
@@ -8719,6 +8728,24 @@ var init_platform_procedures = __esm({
         priority: "p0",
         content: "When an agent encounters a suspected Exe OS bug, update breakage, MCP/tool failure, installer issue, memory/orchestration defect, or customer-local patch need, it MUST use create_bug_report. Do this before or alongside any local workaround so the report reaches AskExe support directly via the customer's license. Do NOT ask the founder for permission to file a required bug report. If create_bug_report is deferred/lazy-loaded, load it and call it. If it is unavailable in the live MCP surface, report 'create_bug_report unavailable in this session' and save a local report in exe/output \u2014 never claim the tool does not exist unless the live MCP surface was checked. If upstream delivery fails, call support_test (MCP) and include its result in the local report so AskExe can distinguish customer setup, license provisioning, and server intake issues; only ask the founder to run `exe-os support test` if MCP is disconnected/unavailable. Classify first: upstream_bug = reproducible exe-os/platform defect; customer_customization = identity, behavior, procedure, config, branding, workflow preference that belongs in customer-owned layers; emergency_hotfix = temporary local patch. For upstream bugs/emergency hotfixes include version, repro steps, expected/actual, files changed, workaround, and local diff summary. Avoid permanent platform-code patches unless founder approves; if a hotfix is unavoidable, document it in the bug report and re-check after npm update."
       },
+      {
+        title: "Bug report status check \u2014 surface available fixes on boot",
+        domain: "support",
+        priority: "p1",
+        content: "Once per session (COO boot only, never repeat), call list_my_bug_reports to check if any previously filed bug reports have been fixed by AskExe. If any report has status 'fixed' with a fixed_version, surface it to the founder immediately: '\u{1F527} N bug fix(es) available \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no reports exist or none are fixed, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+      },
+      {
+        title: "Feature request triage \u2014 upstream feature vs local customization",
+        domain: "support",
+        priority: "p0",
+        content: "When an agent or founder identifies a desired capability that exe-os does not yet provide, the COO (or equivalent coordinator) must decide: is this a local customization (identity, behavior, procedure, config, branding, workflow preference that can be configured in customer-owned layers) or an upstream feature request (a platform capability that requires changes to exe-os code, shipped via npm update)? Local customizations: implement immediately using store_behavior, update_identity, company_procedure, or config changes. Upstream features: use create_feature_request to submit to AskExe. Include use case, business impact, and current workaround. Do NOT ask the founder for permission to file a feature request \u2014 file it proactively when the need is clear."
+      },
+      {
+        title: "Feature request status check \u2014 surface shipped features on boot",
+        domain: "support",
+        priority: "p1",
+        content: "Once per session (COO boot only, never repeat), call list_my_feature_requests to check if any previously filed feature requests have been shipped by AskExe. If any request has status 'shipped' with a shipped_version, surface it to the founder immediately: '\u{1F680} N feature(s) shipped \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no requests exist or none are shipped, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+      },
       // --- Operations ---
       {
         title: "Managers must supervise deployed workers",
@@ -18017,12 +18044,14 @@ On EVERY new conversation, before doing anything else:
 1. **Memory scan**: Run recall_my_memory with broad queries \u2014 "project", "client", "pipeline", "campaign", "deal", "decision", "blocker". Summarize what you find.
 2. **Task scan**: Run list_tasks to see what's open, in progress, blocked, or needs review across all employees.
 3. **Team check**: Run ask_team_memory for recent activity from CTO/CMO/engineers.
-4. **Present the brief**: Give the founder a concise status report:
+4. **Bug fix check** (one-time, never repeat): Call list_my_bug_reports to see if AskExe has fixed any previously filed bugs. If any have status "fixed" with a fixed_version, tell the founder: "\u{1F527} N bug fix(es) available \u2014 run \`exe-os update\` to get version X.Y.Z." Skip silently if none or if the call fails.
+5. **Present the brief**: Give the founder a concise status report:
    - What's active and progressing
    - What's blocked and needs attention
    - What decisions are pending
+   - Available bug fixes (from step 4, if any)
    - What you recommend doing next
-5. Then ask: "What's the priority?"
+6. Then ask: "What's the priority?"
 
 If this is your FIRST ever conversation (few or no prior memories):
 - Search more broadly: "product", "SEO", "meeting", "strategy", "revenue"
@@ -18042,6 +18071,8 @@ Never say "I have no memories" without first searching broadly. Your memory may
 - **get_identity** \u2014 read any agent's identity for coordination
 - **set_agent_config** \u2014 view or change which tool (Claude Code, Codex, OpenCode) and model each agent uses. Call with no args to show all agents' current settings. Call with agent_id + runtime + model to change.
 - **send_message** \u2014 direct intercom to employees
+- **create_bug_report** \u2014 file a bug when you encounter an Exe OS platform issue
+- **list_my_bug_reports** \u2014 check status of filed bugs (boot check: surface available fixes to founder)
 ${PLAN_MODE_COMPAT}
 ## Completion Workflow
 
@@ -35190,16 +35221,89 @@ var code_context_index_exports = {};
 __export(code_context_index_exports, {
   analyzeBlastRadius: () => analyzeBlastRadius,
   buildCodeContextIndex: () => buildCodeContextIndex,
+  buildCodeContextIndexWithEmbeddings: () => buildCodeContextIndexWithEmbeddings,
   getCodeContextIndexPath: () => getCodeContextIndexPath,
   getCodeContextStats: () => getCodeContextStats,
   loadOrBuildCodeContextIndex: () => loadOrBuildCodeContextIndex,
   searchCodeContext: () => searchCodeContext,
+  searchCodeContextSemantic: () => searchCodeContextSemantic,
   traceCodeSymbol: () => traceCodeSymbol
 });
 import crypto14 from "crypto";
 import path51 from "path";
 import { existsSync as existsSync36, mkdirSync as mkdirSync25, readFileSync as readFileSync32, readdirSync as readdirSync11, statSync as statSync7, writeFileSync as writeFileSync26 } from "fs";
 import { spawnSync as spawnSync3 } from "child_process";
+function vectorStorePath(projectRoot) {
+  const rootHash = hashText(projectRoot).slice(0, 16);
+  return path51.join(indexDir(), `${rootHash}.vectors.json`);
+}
+function loadVectorStore(projectRoot) {
+  const file = vectorStorePath(projectRoot);
+  if (!existsSync36(file)) return null;
+  try {
+    const parsed = JSON.parse(readFileSync32(file, "utf8"));
+    if (parsed.version !== VECTOR_STORE_VERSION) return null;
+    return parsed;
+  } catch {
+    return null;
+  }
+}
+function saveVectorStore(projectRoot, store) {
+  writeFileSync26(vectorStorePath(projectRoot), JSON.stringify(store));
+}
+function cosineSimilarity(a, b) {
+  let dot = 0, normA = 0, normB = 0;
+  for (let i = 0; i < a.length; i++) {
+    dot += a[i] * b[i];
+    normA += a[i] * a[i];
+    normB += b[i] * b[i];
+  }
+  const denom = Math.sqrt(normA) * Math.sqrt(normB);
+  return denom === 0 ? 0 : dot / denom;
+}
+async function embedSymbols(index) {
+  const rootHash = hashText(index.projectRoot).slice(0, 16);
+  const existing = loadVectorStore(index.projectRoot);
+  const store = {
+    version: VECTOR_STORE_VERSION,
+    projectRootHash: rootHash,
+    vectors: {}
+  };
+  const allSymbols = [];
+  for (const file of Object.values(index.files)) {
+    for (const symbol of file.symbols) {
+      if (existing?.vectors[symbol.id]) {
+        store.vectors[symbol.id] = existing.vectors[symbol.id];
+      } else {
+        allSymbols.push({ id: symbol.id, text: symbol.summary || `${symbol.kind} ${symbol.name} in ${symbol.filePath}` });
+      }
+    }
+  }
+  if (allSymbols.length === 0) {
+    saveVectorStore(index.projectRoot, store);
+    return store;
+  }
+  const connected = await connectEmbedDaemon().catch(() => false);
+  if (!connected) {
+    saveVectorStore(index.projectRoot, store);
+    return store;
+  }
+  for (let i = 0; i < allSymbols.length; i += EMBED_BATCH_SIZE) {
+    const batch = allSymbols.slice(i, i + EMBED_BATCH_SIZE);
+    const texts = batch.map((s) => s.text);
+    try {
+      const vectors = await embedBatchViaClient(texts, "low");
+      if (vectors && vectors.length === batch.length) {
+        for (let j = 0; j < batch.length; j++) {
+          store.vectors[batch[j].id] = vectors[j];
+        }
+      }
+    } catch {
+    }
+  }
+  saveVectorStore(index.projectRoot, store);
+  return store;
+}
 function normalizeProjectRoot(projectRoot) {
   return path51.resolve(projectRoot || process.cwd());
 }
@@ -35475,7 +35579,7 @@ function filteredFiles(index, options = {}) {
     return matchesPath(file.path, options.paths);
   });
 }
-function searchCodeContext(query, options = {}) {
+function lexicalSearch(query, options = {}) {
   const terms = tokenize2(query);
   if (terms.length === 0) return [];
   const index = loadOrBuildCodeContextIndex({ projectRoot: options.projectRoot, force: options.force || options.refreshIndex, maxFiles: options.maxFiles });
@@ -35501,6 +35605,81 @@ function searchCodeContext(query, options = {}) {
   const limit = options.limit ?? 20;
   return results.sort((a, b) => b.score - a.score || a.filePath.localeCompare(b.filePath)).slice(offset, offset + limit);
 }
+function searchCodeContext(query, options = {}) {
+  return lexicalSearch(query, options);
+}
+async function searchCodeContextSemantic(query, options = {}) {
+  const terms = tokenize2(query);
+  if (terms.length === 0) return [];
+  const index = loadOrBuildCodeContextIndex({ projectRoot: options.projectRoot, force: options.force || options.refreshIndex, maxFiles: options.maxFiles });
+  const projectRoot = normalizeProjectRoot(options.projectRoot);
+  const vectorStore = loadVectorStore(projectRoot);
+  if (!vectorStore || Object.keys(vectorStore.vectors).length === 0) {
+    return lexicalSearch(query, options);
+  }
+  let queryVector = null;
+  try {
+    const connected = await connectEmbedDaemon().catch(() => false);
+    if (connected) {
+      const result = await embedBatchViaClient([query], "high");
+      if (result && result.length === 1) queryVector = result[0];
+    }
+  } catch {
+  }
+  if (!queryVector) return lexicalSearch(query, options);
+  const files = filteredFiles(index, options);
+  const candidates = [];
+  for (const file of files) {
+    for (const symbol of file.symbols) {
+      const lexical = scoreSymbol(symbol, terms);
+      const vec = vectorStore.vectors[symbol.id];
+      const vectorScore = vec ? cosineSimilarity(queryVector, vec) : 0;
+      if (lexical.score > 0 || vectorScore > 0.3) {
+        candidates.push({
+          symbol,
+          lexicalScore: lexical.score,
+          vectorScore,
+          matches: lexical.matches
+        });
+      }
+    }
+  }
+  const byLexical = [...candidates].sort((a, b) => b.lexicalScore - a.lexicalScore);
+  const byVector = [...candidates].sort((a, b) => b.vectorScore - a.vectorScore);
+  const lexicalRank = /* @__PURE__ */ new Map();
+  const vectorRank = /* @__PURE__ */ new Map();
+  byLexical.forEach((c, i) => lexicalRank.set(c.symbol.id, i + 1));
+  byVector.forEach((c, i) => vectorRank.set(c.symbol.id, i + 1));
+  const VECTOR_WEIGHT = 0.6;
+  const LEXICAL_WEIGHT = 0.4;
+  const fused = candidates.map((c) => {
+    const lRank = lexicalRank.get(c.symbol.id) ?? candidates.length + 1;
+    const vRank = vectorRank.get(c.symbol.id) ?? candidates.length + 1;
+    const rrfScore = VECTOR_WEIGHT * (1 / (RRF_K + vRank)) + LEXICAL_WEIGHT * (1 / (RRF_K + lRank));
+    return {
+      symbol: c.symbol,
+      score: rrfScore,
+      matches: c.vectorScore > 0.3 ? [...c.matches, `semantic=${c.vectorScore.toFixed(3)}`] : c.matches,
+      filePath: c.symbol.filePath,
+      language: c.symbol.language,
+      content: c.symbol.text,
+      startLine: c.symbol.startLine,
+      endLine: c.symbol.endLine
+    };
+  });
+  const offset = Math.max(0, options.offset ?? 0);
+  const limit = options.limit ?? 20;
+  return fused.sort((a, b) => b.score - a.score || a.filePath.localeCompare(b.filePath)).slice(offset, offset + limit);
+}
+async function buildCodeContextIndexWithEmbeddings(options = {}) {
+  const index = buildCodeContextIndex(options);
+  const existingStore = loadVectorStore(index.projectRoot);
+  const existingCount = existingStore ? Object.keys(existingStore.vectors).length : 0;
+  const store = await embedSymbols(index);
+  const vectorCount = Object.keys(store.vectors).length;
+  const newEmbeddings = vectorCount - Math.min(existingCount, vectorCount);
+  return { index, vectorCount, newEmbeddings };
+}
 function dependentsMap(index) {
   const map = /* @__PURE__ */ new Map();
   for (const file of Object.values(index.files)) {
@@ -35592,15 +35771,19 @@ function getCodeContextStats(options = {}) {
     indexPath: getCodeContextIndexPath(index.projectRoot)
   };
 }
-var INDEX_VERSION, DEFAULT_MAX_FILES, IGNORE_SEGMENTS;
+var VECTOR_STORE_VERSION, EMBED_BATCH_SIZE, INDEX_VERSION, DEFAULT_MAX_FILES, IGNORE_SEGMENTS, RRF_K;
 var init_code_context_index = __esm({
   "src/lib/code-context-index.ts"() {
     "use strict";
     init_config();
     init_code_chunker();
+    init_exe_daemon_client();
+    VECTOR_STORE_VERSION = 1;
+    EMBED_BATCH_SIZE = 64;
     INDEX_VERSION = 2;
     DEFAULT_MAX_FILES = 5e3;
     IGNORE_SEGMENTS = /* @__PURE__ */ new Set(["node_modules", "dist", ".git", "coverage", ".worktrees", ".next", "build", "target", "vendor"]);
+    RRF_K = 60;
   }
 });
 

package/dist/bin/exe-agent.js

@@ -1377,6 +1377,24 @@ var PLATFORM_PROCEDURES = [
     priority: "p0",
     content: "When an agent encounters a suspected Exe OS bug, update breakage, MCP/tool failure, installer issue, memory/orchestration defect, or customer-local patch need, it MUST use create_bug_report. Do this before or alongside any local workaround so the report reaches AskExe support directly via the customer's license. Do NOT ask the founder for permission to file a required bug report. If create_bug_report is deferred/lazy-loaded, load it and call it. If it is unavailable in the live MCP surface, report 'create_bug_report unavailable in this session' and save a local report in exe/output \u2014 never claim the tool does not exist unless the live MCP surface was checked. If upstream delivery fails, call support_test (MCP) and include its result in the local report so AskExe can distinguish customer setup, license provisioning, and server intake issues; only ask the founder to run `exe-os support test` if MCP is disconnected/unavailable. Classify first: upstream_bug = reproducible exe-os/platform defect; customer_customization = identity, behavior, procedure, config, branding, workflow preference that belongs in customer-owned layers; emergency_hotfix = temporary local patch. For upstream bugs/emergency hotfixes include version, repro steps, expected/actual, files changed, workaround, and local diff summary. Avoid permanent platform-code patches unless founder approves; if a hotfix is unavoidable, document it in the bug report and re-check after npm update."
   },
+  {
+    title: "Bug report status check \u2014 surface available fixes on boot",
+    domain: "support",
+    priority: "p1",
+    content: "Once per session (COO boot only, never repeat), call list_my_bug_reports to check if any previously filed bug reports have been fixed by AskExe. If any report has status 'fixed' with a fixed_version, surface it to the founder immediately: '\u{1F527} N bug fix(es) available \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no reports exist or none are fixed, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+  },
+  {
+    title: "Feature request triage \u2014 upstream feature vs local customization",
+    domain: "support",
+    priority: "p0",
+    content: "When an agent or founder identifies a desired capability that exe-os does not yet provide, the COO (or equivalent coordinator) must decide: is this a local customization (identity, behavior, procedure, config, branding, workflow preference that can be configured in customer-owned layers) or an upstream feature request (a platform capability that requires changes to exe-os code, shipped via npm update)? Local customizations: implement immediately using store_behavior, update_identity, company_procedure, or config changes. Upstream features: use create_feature_request to submit to AskExe. Include use case, business impact, and current workaround. Do NOT ask the founder for permission to file a feature request \u2014 file it proactively when the need is clear."
+  },
+  {
+    title: "Feature request status check \u2014 surface shipped features on boot",
+    domain: "support",
+    priority: "p1",
+    content: "Once per session (COO boot only, never repeat), call list_my_feature_requests to check if any previously filed feature requests have been shipped by AskExe. If any request has status 'shipped' with a shipped_version, surface it to the founder immediately: '\u{1F680} N feature(s) shipped \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no requests exist or none are shipped, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+  },
   // --- Operations ---
   {
     title: "Managers must supervise deployed workers",

package/dist/bin/exe-assign.js

@@ -3532,6 +3532,24 @@ var init_platform_procedures = __esm({
         priority: "p0",
         content: "When an agent encounters a suspected Exe OS bug, update breakage, MCP/tool failure, installer issue, memory/orchestration defect, or customer-local patch need, it MUST use create_bug_report. Do this before or alongside any local workaround so the report reaches AskExe support directly via the customer's license. Do NOT ask the founder for permission to file a required bug report. If create_bug_report is deferred/lazy-loaded, load it and call it. If it is unavailable in the live MCP surface, report 'create_bug_report unavailable in this session' and save a local report in exe/output \u2014 never claim the tool does not exist unless the live MCP surface was checked. If upstream delivery fails, call support_test (MCP) and include its result in the local report so AskExe can distinguish customer setup, license provisioning, and server intake issues; only ask the founder to run `exe-os support test` if MCP is disconnected/unavailable. Classify first: upstream_bug = reproducible exe-os/platform defect; customer_customization = identity, behavior, procedure, config, branding, workflow preference that belongs in customer-owned layers; emergency_hotfix = temporary local patch. For upstream bugs/emergency hotfixes include version, repro steps, expected/actual, files changed, workaround, and local diff summary. Avoid permanent platform-code patches unless founder approves; if a hotfix is unavoidable, document it in the bug report and re-check after npm update."
       },
+      {
+        title: "Bug report status check \u2014 surface available fixes on boot",
+        domain: "support",
+        priority: "p1",
+        content: "Once per session (COO boot only, never repeat), call list_my_bug_reports to check if any previously filed bug reports have been fixed by AskExe. If any report has status 'fixed' with a fixed_version, surface it to the founder immediately: '\u{1F527} N bug fix(es) available \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no reports exist or none are fixed, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+      },
+      {
+        title: "Feature request triage \u2014 upstream feature vs local customization",
+        domain: "support",
+        priority: "p0",
+        content: "When an agent or founder identifies a desired capability that exe-os does not yet provide, the COO (or equivalent coordinator) must decide: is this a local customization (identity, behavior, procedure, config, branding, workflow preference that can be configured in customer-owned layers) or an upstream feature request (a platform capability that requires changes to exe-os code, shipped via npm update)? Local customizations: implement immediately using store_behavior, update_identity, company_procedure, or config changes. Upstream features: use create_feature_request to submit to AskExe. Include use case, business impact, and current workaround. Do NOT ask the founder for permission to file a feature request \u2014 file it proactively when the need is clear."
+      },
+      {
+        title: "Feature request status check \u2014 surface shipped features on boot",
+        domain: "support",
+        priority: "p1",
+        content: "Once per session (COO boot only, never repeat), call list_my_feature_requests to check if any previously filed feature requests have been shipped by AskExe. If any request has status 'shipped' with a shipped_version, surface it to the founder immediately: '\u{1F680} N feature(s) shipped \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no requests exist or none are shipped, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+      },
       // --- Operations ---
       {
         title: "Managers must supervise deployed workers",

package/dist/bin/exe-boot.js

@@ -3269,6 +3269,24 @@ var init_platform_procedures = __esm({
         priority: "p0",
         content: "When an agent encounters a suspected Exe OS bug, update breakage, MCP/tool failure, installer issue, memory/orchestration defect, or customer-local patch need, it MUST use create_bug_report. Do this before or alongside any local workaround so the report reaches AskExe support directly via the customer's license. Do NOT ask the founder for permission to file a required bug report. If create_bug_report is deferred/lazy-loaded, load it and call it. If it is unavailable in the live MCP surface, report 'create_bug_report unavailable in this session' and save a local report in exe/output \u2014 never claim the tool does not exist unless the live MCP surface was checked. If upstream delivery fails, call support_test (MCP) and include its result in the local report so AskExe can distinguish customer setup, license provisioning, and server intake issues; only ask the founder to run `exe-os support test` if MCP is disconnected/unavailable. Classify first: upstream_bug = reproducible exe-os/platform defect; customer_customization = identity, behavior, procedure, config, branding, workflow preference that belongs in customer-owned layers; emergency_hotfix = temporary local patch. For upstream bugs/emergency hotfixes include version, repro steps, expected/actual, files changed, workaround, and local diff summary. Avoid permanent platform-code patches unless founder approves; if a hotfix is unavoidable, document it in the bug report and re-check after npm update."
       },
+      {
+        title: "Bug report status check \u2014 surface available fixes on boot",
+        domain: "support",
+        priority: "p1",
+        content: "Once per session (COO boot only, never repeat), call list_my_bug_reports to check if any previously filed bug reports have been fixed by AskExe. If any report has status 'fixed' with a fixed_version, surface it to the founder immediately: '\u{1F527} N bug fix(es) available \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no reports exist or none are fixed, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+      },
+      {
+        title: "Feature request triage \u2014 upstream feature vs local customization",
+        domain: "support",
+        priority: "p0",
+        content: "When an agent or founder identifies a desired capability that exe-os does not yet provide, the COO (or equivalent coordinator) must decide: is this a local customization (identity, behavior, procedure, config, branding, workflow preference that can be configured in customer-owned layers) or an upstream feature request (a platform capability that requires changes to exe-os code, shipped via npm update)? Local customizations: implement immediately using store_behavior, update_identity, company_procedure, or config changes. Upstream features: use create_feature_request to submit to AskExe. Include use case, business impact, and current workaround. Do NOT ask the founder for permission to file a feature request \u2014 file it proactively when the need is clear."
+      },
+      {
+        title: "Feature request status check \u2014 surface shipped features on boot",
+        domain: "support",
+        priority: "p1",
+        content: "Once per session (COO boot only, never repeat), call list_my_feature_requests to check if any previously filed feature requests have been shipped by AskExe. If any request has status 'shipped' with a shipped_version, surface it to the founder immediately: '\u{1F680} N feature(s) shipped \u2014 run exe-os update to get version X.Y.Z'. This is a one-time check at boot, not a recurring poll. If no requests exist or none are shipped, skip silently. If the MCP tool is unavailable or the network call fails, skip silently \u2014 this is informational, not blocking."
+      },
       // --- Operations ---
       {
         title: "Managers must supervise deployed workers",