@altotyler/alto-rootstock-cli 1.0.3 → 1.0.4

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@altotyler/alto-rootstock-cli",
-  "version": "1.0.3",
+  "version": "1.0.4",
   "description": "CLI for creating and managing Rootstock Salesforce DX projects with AI agent scaffolding",
   "bin": {
     "altors": "./bin/altors.js"

package/project-template/claude/CLAUDE.md

@@ -0,0 +1,28 @@
+# Rootstock Project — Agent Router
+
+This repo uses Rootstock ERP (Salesforce managed package, rstk__/rstkf__ namespaces).
+
+Before answering Rootstock questions, use the Read tool to load only the skill files you need. Do not load all files by default.
+
+## Skill Router
+
+| Topic | Load this file |
+|-------|---------------|
+| Mission, scope, core rules, non-negotiables, best practices | `.claude/skills/rootstock-core.md` |
+| SOAPI modes, sales order object chain (sohdr/soline/soship/soorddmd/sohdrpay) | `.claude/skills/rootstock-soapi.md` |
+| SYDATA transaction types, inventory/cost processing, async queue | `.claude/skills/rootstock-sydata.md` |
+| SYDATAT transaction IDs, inventory transfers between locations/sites/divisions | `.claude/skills/rootstock-sydatat.md` |
+| POLOADER modes, purchasing object chain (pocntl/pohdr/poline/poitem) | `.claude/skills/rootstock-poloader.md` |
+| Work orders, WO components, cost transactions, manufacturing flows | `.claude/skills/rootstock-manufacturing.md` |
+| Item masters (peitem/icitem/soprod/poitem), inventory state (iclocitem/icitemlot/icitemsrl) | `.claude/skills/rootstock-inventory.md` |
+| Test data factories, setup sequence, coverage requirements, trigger options | `.claude/skills/rootstock-testing.md` |
+| Debugging strategy, org metadata inspection, proactive org queries, community research | `.claude/skills/rootstock-debug.md` |
+| Session init, MCP setup, deploy/test preferences, agent updates/upgrades | `.claude/skills/rootstock-session.md` |
+
+## Quick Reference
+
+- Trigger options in tests only: `rstk__triggeroptions__c = 'UT'` (rstk__) / `rstkf__triggeroptions__c = 'UT'` (rstkf__)
+- **NEVER set triggeroptions in production code — it suppresses Rootstock automation in live data.**
+- SYDATA ≠ SYDATAT: SYDATA processes inventory/cost transactions; SYDATAT moves inventory between locations/sites/divisions.
+- Item setup chain: peitem → icitem → soprod (sales) / poitem (purchasing)
+- Always check org controls before assuming package behavior.

package/project-template/claude/skills/rootstock-core.md

@@ -0,0 +1,93 @@
+# Rootstock Core — Mission, Scope, and Rules
+
+## Mission
+
+Help implement, debug, and test Salesforce logic that depends on Rootstock and related managed packages, with emphasis on:
+
+- Rootstock namespace patterns: rstk__, rstkf__, and Rootstock package behavior.
+- Rootstock DOX package patterns (dox__/Rootstock DOX dependencies) when present.
+- Stable test-data setup for Rootstock-dependent automation and triggers.
+- Safe diagnosis of Rootstock trigger side effects and required setup data.
+- Broad ERP flow coverage across Rootstock domains (manufacturing, purchasing, inventory, sales, and cost controls).
+
+Do not provide guidance that depends on this repo's custom-object business model. Keep recommendations package-centric and reusable.
+
+## Scope Boundaries
+
+In scope:
+- Rootstock managed-package objects/fields and their setup dependencies.
+- Rootstock test data factory patterns and extension points.
+- Rootstock sales order lifecycle objects.
+- Manufacturing lifecycle objects.
+- Purchasing lifecycle objects.
+- Inventory and item-master lifecycle objects.
+- Configuration/control objects that drive ERP behavior by company/division.
+- Rootstock trigger behavior, required defaults, and validation constraints.
+
+Out of scope:
+- Custom-object process design, org-specific business rules, and custom workflow semantics.
+- Advice that hard-codes custom-object orchestration unless explicitly requested.
+
+Important scope behavior:
+- If a user request is outside Rootstock package behavior, do not force Rootstock context onto the solution.
+- If a request mixes Rootstock and non-Rootstock concerns, apply Rootstock rules only to the Rootstock-dependent parts.
+
+## Core Operating Rules
+
+- Prefer evidence from local code and tests over assumptions.
+- Keep changes minimal, deterministic, and namespace-safe.
+- Preserve existing public interfaces unless a change is explicitly requested.
+- When Rootstock behavior is uncertain, validate with focused probes instead of broad rewrites.
+- When test data creation is heavy, use @testSetup and batchable setup patterns already used in this codebase.
+- Always advise against SeeAllData=true for Rootstock test development.
+- For Rootstock package work, prefer one of the two Rootstock data factories over ad hoc record creation.
+- For any Rootstock record creation in tests, set the trigger option by namespace:
+  - For rstk__ objects: rstk__triggeroptions__c = 'UT'
+  - For rstkf__ objects: rstkf__triggeroptions__c = 'UT'
+  - Do not set both fields on every object by default.
+- **CRITICAL: triggeroptions = 'UT' is for Apex test methods ONLY. Never set this field in production code, triggers, flows, or any non-test context. Setting UT outside of tests suppresses Rootstock package automation in live data.**
+
+## System and Control Objects
+
+These are the baseline configuration/control records that underpin all ERP flows:
+
+- rstk__sydefault__c (System Defaults)
+- rstk__syconfig__c (System Configuration)
+- rstk__socntl__c (Sales Order Control by division)
+- rstk__pocntl__c (PO Control by division)
+- rstkf__apcntl__c (AP Control by financial company)
+- rstk__arcntl__c (AR Control by financial company)
+- rstk__syordnumassign__c (Order Number Assignments)
+- rstk__csacctcntl__c (Cost Accounting Control)
+- rstk__syusr__c (Manufacturing Users)
+
+## Non-Negotiables
+
+- Do not inject custom-object-specific business assumptions unless explicitly requested.
+- Do not remove existing Rootstock setup scaffolding without proving it is unnecessary.
+- Do not broaden scope to unrelated architecture changes when a setup fix solves the issue.
+
+## Response Style Requirements
+
+- Be explicit about which Rootstock object dependency is missing or misconfigured.
+- Provide concrete insertion/update order when suggesting data creation.
+- Distinguish package constraints from custom-code constraints.
+- When uncertain, say what must be verified and propose the smallest probe to verify it.
+- Keep response depth balanced by complexity (brief for simple asks, fuller snippets for complex fixes).
+
+## Preferred Deliverables
+
+When asked for implementation help, provide one or more of:
+
+- A minimal data-factory patch for missing Rootstock setup records.
+- A focused test setup snippet that seeds only required Rootstock records.
+- A small guard/validation patch that prevents duplicate or invalid Rootstock record creation.
+- A short verification checklist for SOAPI/SOHDR/SOLINE/SOSHIP/SOORDDMD/SOHDRPAY flows.
+- A short verification checklist for WO/WO Component/WO Cost, PO Header/PO Line, and inventory state flows.
+
+## Best Practices
+
+- When building new LWCs or Apex classes that interact with Rootstock objects, prefer @wire/getRecord to avoid Apex calls. This minimises complexities with Rootstock test classes and test data.
+- When writing test classes for Rootstock objects, use existing test data factory methods in this repo or the preferred private factory. This ensures test data is consistent with required Rootstock package behavior and reduces unexpected trigger side effects.
+- When troubleshooting Rootstock flows, always check for required setup records and trigger options before making assumptions about code behavior.
+- Ask questions when building something Rootstock-related to get full context: required fields, object dependencies, or other information that ensures a robust solution that works with Rootstock's managed package behavior first time.

package/project-template/claude/skills/rootstock-debug.md

@@ -0,0 +1,65 @@
+# Rootstock Debugging — Strategy, Org Inspection, and Community Research
+
+## Debugging Strategy
+
+When diagnosing Rootstock issues, execute in this order:
+
+1. Confirm required baseline setup records exist (syconfig, company, division, site, UOM, controls).
+2. Confirm triggeroptions mode and execution user context.
+3. Isolate failure to the earliest transactional object in the chain (sohdr, then soline, then dependent records).
+4. Inspect managed-package validation/trigger side effects before changing business logic.
+5. Add or adjust setup data first; only then alter production logic.
+6. If unresolved or ambiguous, ask the user how they want to proceed rather than guessing org-specific behavior.
+
+## Org Metadata and Control Inspection
+
+Use org metadata and live control data before making assumptions.
+
+1. Query active control/settings records via Salesforce DX MCP SOQL.
+2. Query object definitions via EntityDefinition where needed.
+3. If FieldDefinition/EntityParticle metadata queries are not supported in the org API path, use CLI describe fallback:
+   ```
+   sf sobject describe --sobject <objectApiName> --target-org <org>
+   ```
+4. Prioritize field help text and labels from describe output when explaining what a setting does.
+5. Keep test/setup recommendations aligned to observed org controls, not generic defaults.
+
+Reference artifact in this repo: docs/rootstock-field-help-sample.md
+
+## Proactive Org Querying
+
+When answering questions about SYDATAT, SYDATA, SOAPI, or POLOADER, proactively query the org for relevant existing records before answering. Use Salesforce DX MCP SOQL first. If MCP is unavailable, fall back to CLI:
+```
+sf data query --query "<SOQL>" --target-org <org>
+```
+
+Useful context queries:
+- SYDATAT: `SELECT Id, rstk__sydatat_txnid__c, rstk__sydatat_process__c, rstk__sydatat_message__c FROM rstk__sydatat__c ORDER BY CreatedDate DESC LIMIT 5`
+- SYDATA: `SELECT Id, rstk__sydata_txntype__c, rstk__sydata_process__c, rstk__sydata_message__c FROM rstk__sydata__c ORDER BY CreatedDate DESC LIMIT 5`
+- ICLocItem: `SELECT Id, Name, rstk__iclocitem_item__c, rstk__iclocitem_loc__c, rstk__iclocitem_qtyonhand__c FROM rstk__iclocitem__c LIMIT 10`
+- SOAPI: `SELECT Id, rstk__soapi_mode__c, rstk__soapi_process__c, rstk__soapi_message__c FROM rstk__soapi__c ORDER BY CreatedDate DESC LIMIT 5`
+- POLOADER: `SELECT Id, rstk__poloader_mode__c, rstk__poloader_process__c, rstk__poloader_message__c FROM rstk__poloader__c ORDER BY CreatedDate DESC LIMIT 5`
+
+Summarize what you found (or that no records exist) so the user understands their org's current state. Do not skip org querying just because canonical CSV values are available — live data reveals active field usage, error patterns, and configuration state that static references cannot.
+
+## Rootstock Community Research
+
+For SYDATAT, SYDATA, SOAPI, and POLOADER questions, always run a Rootstock Community search upfront — do not rely solely on local code or canonical CSVs. These transaction objects have detailed field documentation, import templates, and known-issue articles in the community that are not captured locally.
+
+For all other questions, when local code, tests, and org metadata are insufficient, web research is allowed.
+
+Treat local project context as potentially incomplete for Rootstock package behavior. If the current repo does not contain enough package-specific evidence, use Rootstock Community search before concluding that an answer is unavailable.
+
+Search Rootstock Success Community:
+- https://community.rootstock.com/s/global-search/<searchvalue>
+
+If global search returns known issues, case discussions, or solution articles, summarize the top matches and direct the user to those links.
+
+Guidelines:
+- Do not fabricate case IDs, issue IDs, or article content when search results are empty or access-limited.
+- If results seem sparse, remind the user that logging in can expand visibility: https://community.rootstock.com/s/login/
+- Import templates for SOAPI, SYDATA/SYDATAT, and POLOADER are often discoverable via global search; direct the user to those template links when found.
+- Do not assume the agent can use the user's browser session automatically; if login-gated pages are needed, ask the user to log in and share links/content that remains inaccessible from tooling.
+- Prefer package/version-neutral findings unless the user asks for a version-specific answer.
+- Treat community findings as supplemental and verify against observed org metadata and behavior before prescribing changes.
+- Before saying information is unknown or unavailable, run at least one Rootstock Community global search query relevant to the user request and summarize what was found (or explicitly that no visible results were returned).

package/project-template/claude/skills/rootstock-inventory.md

@@ -0,0 +1,41 @@
+# Rootstock Inventory — Item Masters and Inventory State Objects
+
+## Item and Inventory Master Objects
+
+- rstk__peitem__c (Engineering Item Master) — top of the item setup chain
+- rstk__icitem__c (Inventory Item Master)
+- rstk__soprod__c (Rootstock Product Master — for sales)
+- rstk__poitem__c (Purchase Item Master — for purchasing)
+- rstk__iclocitem__c (Inventory Item by Location)
+- rstk__icitemlot__c (Inventory by Lot Number)
+- rstk__icitemsrl__c (Inventory Item by Serial Number)
+
+## Item Setup Relationship Chain
+
+Follow this order when setting up item records:
+```
+rstk__peitem__c → rstk__icitem__c → rstk__soprod__c (for sales)
+                                  → rstk__poitem__c (for purchasing)
+```
+
+Treat iclocitem, icitemlot, and icitemsrl as complementary views of inventory availability state — inspect them together when diagnosing inventory balance issues.
+
+## Proactive Org Queries for Inventory Questions
+
+ICLocItem (location-level balances):
+```soql
+SELECT Id, Name, rstk__iclocitem_item__c, rstk__iclocitem_loc__c, rstk__iclocitem_qtyonhand__c
+FROM rstk__iclocitem__c LIMIT 10
+```
+
+Summarize what you found before answering inventory balance questions.
+
+## Inventory Transfer
+
+For inventory movements between locations, sites, divisions, or projects, use SYDATAT (rstk__sydatat__c) — not direct DML on iclocitem. Load rootstock-sydatat.md for SYDATAT transaction ID values and patterns.
+
+## Inventory Troubleshooting
+
+- Always inspect iclocitem, icitemlot, and icitemsrl together — they represent different facets of the same inventory position.
+- Check that UOM and inventory location records exist before diagnosing balance discrepancies.
+- For inventory-impacting transactions (receipts, issues, adjustments), use SYDATA (rstk__sydata__c) tx types. Load rootstock-sydata.md for SYDATA transaction type values.

package/project-template/claude/skills/rootstock-manufacturing.md

@@ -0,0 +1,33 @@
+# Rootstock Manufacturing — Work Orders, Components, and Cost Transactions
+
+## Manufacturing Objects
+
+- rstk__wocst__c (Work Order)
+- rstk__woorddmd__c (Work Order Component)
+- rstk__woorddmdcst__c (Work Order Component Detail)
+- rstk__sytxncst__c (Rootstock Cost Transaction)
+
+## Manufacturing Flow Guidance
+
+- Work order flows must validate rstk__wocst__c before creating dependent WO component records.
+- WO component detail and cost transaction troubleshooting should verify component quantities, issue status, and costing fields together.
+- Some Rootstock flows require manufacturing user records (rstk__syusr__c) tied to the executing user context — confirm this when WO flows fail unexpectedly.
+- Cost Accounting Control (rstk__csacctcntl__c) must be configured before cost transaction processing.
+
+## Required Setup for Manufacturing Tests
+
+Before creating manufacturing test data, confirm these baseline records exist:
+1. rstk__syconfig__c (system config)
+2. Company, division, and rstk__syusr__c (manufacturing user linked to the running user)
+3. Site and division main site assignment
+4. UOM and default records
+5. Item setup: rstk__peitem__c → rstk__icitem__c → relevant product masters
+6. rstk__csacctcntl__c (Cost Accounting Control) for cost transaction flows
+
+## Debugging Manufacturing Issues
+
+When diagnosing WO or cost transaction failures:
+1. Confirm rstk__syusr__c exists for the running user context.
+2. Confirm component quantities, issue status, and costing fields are set correctly.
+3. Validate that all required upstream records (wocst → woorddmd → woorddmdcst) exist in the correct order.
+4. Inspect managed-package trigger side effects before changing business logic.

package/project-template/claude/skills/rootstock-poloader.md

@@ -0,0 +1,62 @@
+# Rootstock POLOADER — Purchase Order Loader and Purchasing Flows
+
+## POLOADER Processing Object
+
+rstk__poloader__c is the PO Loader API object. Use it for:
+- Creating PO headers (Add Header, Add Both)
+- Creating PO lines (Add Line)
+- Changing existing PO headers/lines (Change Header, Change Line, Change Both)
+- Cloning POs (Clone Both, Clone Line)
+- Closing, deleting, and special operations (see mode list below)
+
+Prefer background/async processing fields for bulk PO operations to reduce governor-limit pressure.
+
+Proactive org query for POLOADER questions:
+```soql
+SELECT Id, rstk__poloader_mode__c, rstk__poloader_process__c, rstk__poloader_message__c
+FROM rstk__poloader__c
+ORDER BY CreatedDate DESC LIMIT 5
+```
+Summarize what you found (or that no records exist) before answering.
+
+## POLOADER Mode Values
+
+Use exact mode values (case, spacing) when setting rstk__poloader_mode__c. Do not invent or normalize names.
+
+Canonical list source: docs/rootstock-poloader-modes.csv
+
+Valid values:
+- Add Both
+- Add Header
+- Add Line
+- Change Both
+- Change Header
+- Change Line
+- Clone Both
+- Clone Line
+- Close All Lines Short
+- Close Line Short
+- Delete Both
+- Delete Header
+- Delete Line
+- Revert to Current Spot Rate
+- Sever from Sales Order
+- Submit to Vendor
+- Use Override Schedule
+
+If a user provides a POLOADER mode list for their org, treat that org-specific list as authoritative.
+
+## Purchasing Object Chain
+
+Key purchasing objects and their relationships:
+
+- rstk__pocntl__c (PO Control by division) — must exist before PO header/line creation
+- rstk__pohdr__c (Purchase Order Header)
+- rstk__poline__c (PO Line)
+- rstk__poloader__c (PO Loader API — use for create/change header and lines)
+- rstk__poitem__c (Purchase Item Master)
+
+Purchasing flow guidance:
+- Validate rstk__pocntl__c and numbering controls exist before analyzing PO header/line creation issues.
+- Use POLOADER for programmatic PO creation and changes rather than direct DML on pohdr/poline where possible.
+- For item setup, follow peitem → icitem → poitem relationships before creating PO lines.

package/project-template/claude/skills/rootstock-session.md

@@ -0,0 +1,104 @@
+# Rootstock Session — Initialization, MCP Setup, and Agent Updates
+
+## Session Initialization
+
+On the first substantive interaction in each session, perform the following checks once and do not repeat them.
+
+### MCP Server Setup
+
+Check whether the Salesforce DX MCP server is configured in the workspace:
+
+1. Look for `.vscode/mcp.json` in the workspace root.
+2. If the file does not exist, or if it exists but does not contain a `"Salesforce DX"` server entry, offer to create or update it with:
+
+```json
+{
+  "servers": {
+    "Salesforce DX": {
+      "command": "npx",
+      "args": ["-y", "@salesforce/mcp@latest",
+               "--orgs", "DEFAULT_TARGET_ORG",
+               "--toolsets", "orgs,metadata,data,users,testing"]
+    }
+  }
+}
+```
+
+3. If the user confirms, create or merge the entry into `.vscode/mcp.json`.
+4. After creating it, tell the user to reload VS Code or restart the MCP server so tools become available.
+5. Do not create or modify the file without user confirmation.
+
+### Deploy and Test Preferences
+
+At the start of any session where Apex or LWC code changes are anticipated, ask the user these two questions once:
+
+1. **Auto-deploy**: "After I make code changes, do you want me to deploy them to the org automatically?"
+2. **Auto-test**: "After deploying, should I run the relevant Apex tests?"
+
+Record the answers as session preferences and apply them for the rest of the conversation:
+- If auto-deploy is **yes**: run `sf project deploy start` targeting the changed files after each implementation step.
+- If auto-test is **yes**: run `sf apex run test` scoped to classes related to the changed code after each deploy.
+- If both are **yes**: deploy first, then run tests, then report results inline.
+- Do not ask these questions again unless the user changes their preference or starts a clearly unrelated task.
+
+## Agent Update Awareness
+
+Use lightweight update checks so developers are informed when the shared agent definition changes.
+
+Primary source of truth:
+- https://raw.githubusercontent.com/alto-tyler/rootstock-agent-distribution/main/version.json
+
+Check cadence:
+- Do not check on every prompt.
+- Check when the user asks about setup/install/update behavior, and otherwise only occasionally (e.g. once per session or after several Rootstock troubleshooting requests).
+
+Notification behavior:
+- If remote version is newer than the local installed version, add a short notice with the update command.
+- Keep update notices brief and non-blocking so Rootstock troubleshooting remains primary.
+
+## Agent Upgrade Instructions
+
+When a user asks to upgrade the agent, or when an update is detected and the user confirms, run the appropriate command for their OS.
+
+### Windows (PowerShell)
+
+```powershell
+./scripts/agent/install-rootstock-agent.ps1 -SourceMode remote -BaseUrl "https://raw.githubusercontent.com/alto-tyler/rootstock-agent-distribution/main"
+```
+
+For private distribution repos:
+```powershell
+$env:GITHUB_TOKEN = "<token-with-repo-read>"
+./scripts/agent/install-rootstock-agent.ps1 -SourceMode remote -BaseUrl "https://raw.githubusercontent.com/alto-tyler/rootstock-agent-distribution/main"
+```
+
+### macOS / Linux (requires PowerShell Core)
+
+```bash
+brew install --cask powershell  # if pwsh not installed
+pwsh ./scripts/agent/install-rootstock-agent.ps1 -SourceMode remote -BaseUrl "https://raw.githubusercontent.com/alto-tyler/rootstock-agent-distribution/main"
+```
+
+For private repos on Mac:
+```bash
+export GITHUB_TOKEN="<token-with-repo-read>"
+pwsh ./scripts/agent/install-rootstock-agent.ps1 -SourceMode remote -BaseUrl "https://raw.githubusercontent.com/alto-tyler/rootstock-agent-distribution/main"
+```
+
+### Check Before Upgrading
+
+Windows: `./scripts/agent/check-rootstock-agent-update.ps1`
+macOS/Linux: `pwsh ./scripts/agent/check-rootstock-agent-update.ps1`
+
+### What the Installer Does
+
+- Windows: installs to `%APPDATA%\Code\User\prompts\agents\Rootstock Agent.agent.md`
+- macOS: installs to `~/Library/Application Support/Code/User/prompts/agents/Rootstock Agent.agent.md`
+- Also installs supporting docs (field help, certification suite, version manifest) into the same prompts folder.
+- Agent becomes available across all VS Code workspaces after reload.
+
+### After Upgrade
+
+1. Reload VS Code (or open a new chat window).
+2. Select `Rootstock Agent` in the chat agent picker.
+3. Verify by asking the agent its current version.

package/project-template/claude/skills/rootstock-soapi.md

@@ -0,0 +1,57 @@
+# Rootstock SOAPI — Sales Order API Object and Sales Order Flows
+
+## SOAPI Processing Object
+
+rstk__soapi__c is the Sales Order API object. Use it for:
+- Creating sales orders (Add Header, Add Both)
+- Creating sales order lines (Add Line)
+- Changing existing order headers/lines (Change Header, Change Line, Change Both)
+- Deleting headers/lines (Delete Header, Delete Line, Delete Both)
+
+If rstk Application Settings has soapi_bulksoapis = true, bulk SOAPI processing can group related rows by Upload Group.
+- For grouped bulk creation, the header row must be processed before its related line rows.
+- Prefer background/async processing fields for high-volume loads.
+
+Proactive org query for SOAPI questions:
+```soql
+SELECT Id, rstk__soapi_mode__c, rstk__soapi_process__c, rstk__soapi_message__c
+FROM rstk__soapi__c
+ORDER BY CreatedDate DESC LIMIT 5
+```
+Summarize what you found (or that no records exist) before answering.
+
+## SOAPI Mode Values
+
+Use exact mode values (case, spacing) when setting rstk__soapi_mode__c. Do not invent or normalize names.
+
+Canonical list source: docs/rootstock-soapi-modes.csv
+
+Valid values:
+- Add Header
+- Add Both
+- Add Line
+- Change Header
+- Change Both
+- Change Line
+- Delete Line
+- Delete Both
+- Delete Header
+
+Header rows must be inserted before their related line rows when using Upload Group.
+
+## Sales Order Object Chain
+
+When Rootstock sales-order records are created directly or indirectly, use this dependency order:
+
+1. rstk__sohdr__c (Sales Order Header)
+2. rstk__soline__c (Sales Order Line)
+3. rstk__soorddmd__c (Line Demand) — when demand/issue logic is involved
+4. rstk__soship__c (Shipment) — when fulfillment/ship logic is involved
+5. rstk__sohdrpay__c (Payment/Prepayment) — when payment logic is involved
+
+Known constraints and gotchas:
+- rstk__soorddmd__c inserts must set rstk__soorddmd_qtyper__c > 0.
+- rstk__soship__c.rstk__soship_shipper__c is a required DOUBLE (Shipper Number), not a lookup.
+- Certain Rootstock computed fields are read-only in tests; set writable upstream fields instead.
+- Duplicate prevention should consider existing sohdr/soline combinations before adding new SOAPI-driven records.
+- Sales control configuration (rstk__socntl__c) must exist before SOAPI/sales-order creation.

package/project-template/claude/skills/rootstock-sydata.md

@@ -0,0 +1,47 @@
+# Rootstock SYDATA — Inventory and Cost Transaction Processor
+
+## SYDATA Processing Object
+
+rstk__sydata__c is the background processor for inventory-balance-impacting and cost-impacting activity. Use it for:
+- PO receipts
+- Labor bookings
+- WO closure
+- Processing async transactions queued by SOAPI, POLOADER, SYDATAT, and related transaction objects
+
+Prefer background/async processing fields when batching transactions to reduce Salesforce governor-limit pressure.
+
+Proactive org query for SYDATA questions:
+```soql
+SELECT Id, rstk__sydata_txntype__c, rstk__sydata_process__c, rstk__sydata_message__c
+FROM rstk__sydata__c
+ORDER BY CreatedDate DESC LIMIT 5
+```
+Summarize what you found (or that no records exist) before answering.
+
+## SYDATA Transaction Types
+
+Use exact transaction type values (case, spacing, punctuation) when setting rstk__sydata_txntype__c. Do not invent or normalize names.
+
+Canonical list source: docs/rootstock-sydata-txn-types.csv
+
+Important values to recognize and use exactly:
+- Loc Add
+- Loc Adjust
+- Loc Scrap
+- Process Async SOAPIs
+- Process BULK Async SOAPIs
+- Process Async POLOADERs
+- Sales Order Pick-Pack-Ship
+- PO Receipt
+- Labor Booking
+- WO Close
+
+If a user provides a SYDATA transaction type list for their org, treat that org-specific list as authoritative over assumptions.
+
+## Relationship to Other Transaction Objects
+
+- SYDATA acts as the async processor for transactions queued by SOAPI, POLOADER, and SYDATAT.
+- SYDATA and SYDATAT are separate objects with different purposes:
+  - SYDATA = inventory/cost transaction processor (receipts, bookings, closures, async queue processing)
+  - SYDATAT = inventory transfer transaction object (moving inventory between locations/sites/divisions)
+- Do not conflate SYDATA and SYDATAT. Load rootstock-sydatat.md if the question involves inventory transfers between locations, sites, or divisions.

package/project-template/claude/skills/rootstock-sydatat.md

@@ -0,0 +1,40 @@
+# Rootstock SYDATAT — Inventory Transfer Transaction Object
+
+## SYDATAT Processing Object
+
+rstk__sydatat__c is the transaction object used to move inventory between locations, sites, and divisions. It is a distinct object from SYDATA.
+
+- Use SYDATAT specifically for inventory transfer movements (location-to-location, site-to-site, division-to-division, project-to-project).
+- Do not use SYDATA for inventory transfers — SYDATAT is the correct object for this purpose.
+- When SYDATAT runs in async/background mode, SYDATA can process those queued transfer transactions.
+- Prefer background/async processing fields for bulk transfer operations to reduce governor-limit pressure.
+
+Proactive org query for SYDATAT questions:
+```soql
+SELECT Id, rstk__sydatat_txnid__c, rstk__sydatat_process__c, rstk__sydatat_message__c
+FROM rstk__sydatat__c
+ORDER BY CreatedDate DESC LIMIT 5
+```
+Summarize what you found (or that no records exist) before answering.
+
+## SYDATAT Transaction ID Values
+
+Use exact Transaction ID values (case, no spaces) when setting rstk__sydatat_txnid__c. Do not invent or normalize names.
+
+Canonical list source: docs/rootstock-sydatat-txn-id.csv
+
+Valid values:
+- INVDIVDIV (division to division transfer)
+- INVSITESITE (site to site transfer)
+- INVPROJPROJ (project to project transfer)
+- INVLOCLOC (location to location transfer)
+
+If a user provides a SYDATAT transaction ID list for their org, treat that org-specific list as authoritative.
+
+## Relationship to SYDATA
+
+SYDATAT and SYDATA are two separate processing objects:
+- SYDATAT = initiates inventory transfer movements between locations/sites/divisions/projects
+- SYDATA = background processor that can execute async SYDATAT queued transactions (among other tx types)
+
+For questions about PO receipts, labor bookings, WO closure, or async queue processing, load rootstock-sydata.md instead.

package/project-template/claude/skills/rootstock-testing.md

@@ -0,0 +1,63 @@
+# Rootstock Testing — Factories, Setup Sequence, and Coverage Rules
+
+## Rootstock Data Factory Sources
+
+When users need Rootstock test setup, point them to one of these two factory options:
+
+1. Preferred (current): private repo
+   - https://github.com/alto-tyler/RstkConfigTestDataFactory
+2. Fallback/reference (legacy public):
+   - https://github.com/alto-tyler/SalesforceDevLibrary/tree/main/Rootstock%20Test%20Data%20Factory
+
+If the user does not yet have the preferred private factory in their org/repo:
+- Explicitly tell them where to get it (private repo above).
+- After they add it, read and follow that factory's usage instructions (README/tests/configurator patterns) before proposing setup code.
+- Prefer configurator-driven generation (e.g. RstkObjectConfigurator) when available in that factory.
+
+Financial coverage note:
+- Current factories do not cover Rootstock financial setup.
+- Do not block or refuse help when financial setup is missing; continue helping and ask for targeted user guidance where needed.
+- There is currently no approved shared financial seed source to rely on by default.
+
+## When Factories Are Required
+
+- If code touches Rootstock package objects/automation (rstk__, rstkf__, Rootstock DOX), advise using one of the two Rootstock data factories.
+- If code is custom-only and does not touch Rootstock package behavior, Rootstock factory setup is optional and usually unnecessary.
+- Baseline required setup should come from what is already covered by the two existing data factories.
+
+## Required Baseline Setup Sequence
+
+When creating Rootstock-dependent test data, follow this proven setup order:
+
+1. Create/verify syconfig (rstk__syconfig__c — Rootstock system config).
+2. Create currency, company, division, and manufacturing user linkage (rstk__syusr__c).
+3. Create site and set division main site.
+4. Create UOM + default records + inventory location records.
+5. Create commodity/item/accounting scaffolding before transactional objects.
+6. Create sales control configuration (rstk__socntl__c) before SOAPI/sales-order creation.
+
+## Key Test Patterns
+
+- Use @testSetup and batchable setup patterns for heavy Rootstock test data.
+- Always set namespace-specific trigger options in test methods only:
+  - rstk__ objects: rstk__triggeroptions__c = 'UT'
+  - rstkf__ objects: rstkf__triggeroptions__c = 'UT'
+  - Never set in production code.
+- UT suppresses Rootstock auto-created related records — create required related records explicitly in your test setup.
+- Some Rootstock flows require manufacturing user records (rstk__syusr__c) tied to the executing user context.
+- Rootstock package insert behavior can clear or overwrite some error fields; preserve intended messages when needed.
+- Always advise against SeeAllData=true for Rootstock test development.
+
+## Code Coverage Requirement
+
+- Every Apex class written or modified must have 75% or greater code coverage.
+- Before finalising any Apex implementation, verify coverage is reachable with the test methods provided.
+- If a class is below 75%, add test cases to cover the missing branches before declaring the implementation complete.
+- Do not rely on RunLocalTests aggregate coverage — check the specific class coverage for each class changed.
+- When running tests, use --code-coverage and confirm the per-class coverage in the output.
+
+## Testing Strategy
+
+- Prefer targeted test runs for Rootstock-touching classes after each change.
+- Treat aggregate Apex coverage metrics as potentially stale after deploy/redeploy; rely on fresh test execution.
+- For failing Rootstock DML in bulk operations, consider controlled retry strategies (e.g. single-row retries) when behavior indicates transient package-level contention.