added spryker customization agents - #23
Conversation
Nidhognit
left a comment
There was a problem hiding this comment.
I understood the general idea to have a fully automated tool, I like it, and i'm afraid it would not work :)
| - Do not run `docker/sdk reset` or any destructive command — full resets are out of scope. | ||
| - Do not seed deep FK chains. If a row depends on five other entities that don't exist, return `precondition_failed` and let the caller decide. | ||
| - Do not retry past one import failure. Report the failure and stop. | ||
| - Do not fire publisher / search-index / sync events as part of seeding. The importer should handle propagation. If the seed lands in the DB but doesn't appear where expected, that's a bug to surface — not something the seeder should paper over. |
There was a problem hiding this comment.
we have a known issue - if you would run import without stopping the consumer, the data can be inconsistent
I ususally stoping the queue before running, or we can trigger the events after full import
| - **`executeDatabaseQuery`** (Spryker MCP) is the **only allowed way** to query the database. Use it for any DB state inspection a diagnosis needs. | ||
| - For unknown table names, query `information_schema.tables` to enumerate `spy_*` tables that exist, then read the schema XML for column structure. | ||
| - Do **not** run raw SQL via `Bash`, `docker/sdk cli`, `docker exec ... psql/mysql/mariadb`, PHP PDO/Doctrine in heredocs, or any other bypass — regardless of MCP availability. | ||
| - **Fallback when MCP unavailable:** (a) work from logs alone where they're sufficient; (b) ask the user to run a specific SQL query and paste the result; (c) if neither is possible, report *"DB MCP not available — diagnosis limited to logs and observable state"* and continue with what you can. |
There was a problem hiding this comment.
can we ask about MCP suggestion?
like line in the console, MCP is unavailable, to run it see the doc - link
|
|
||
| **Published-data symptom — check P&S workers first.** When the symptom is *"data updated in BO but storefront still shows old"*, after browser-cache is ruled out, check whether publishers/workers fired: | ||
| - Queue worker process: `docker ps | grep queue` (or check Jenkins / `docker/sdk jobs` state) | ||
| - Manually trigger and re-check: `docker/sdk console publish:trigger-events` then `docker/sdk console queue:task:start --once` |
|
|
||
| | Symptom | Cause | Fix | | ||
| |---|---|---| | ||
| | `codecept run <file>.php` fails with "Suite was not loaded" | `-c` is required to point at the directory containing `codeception.yml` | Use `-c <dir> <Suite> <Class>:<method>` (single colon, no `.php`), or `-g <Group>`. PHPUnit-style `::` does not work. | |
There was a problem hiding this comment.
Is this whole file for projects? i just have a feeling it is for core
| - **Reuse existing atomic components first** (`Theme/default/components/atoms/*`, `.../molecules/*`, `.../organisms/*`) rather than writing standalone HTML. If a "badge" atom exists, use it; don't recreate one. | ||
| - **Match surrounding styling** — if a checkout step uses specific button atoms, a new button there uses the same atom. If product info uses a specific label pattern, a new label uses that pattern. | ||
| - **No new visual idioms without justification** — if the project's PDP price block uses a specific layout, don't introduce a totally different layout for an additional price line. | ||
| - **The `yves-atomic-frontend` skill** exists for exactly this — invoke it via the `Skill` tool when adding Yves UI components, so the new element extends the atomic design system properly. |
There was a problem hiding this comment.
Atomic fronted is one of the performance issues for Yves
personally, i would not recommend this on the project level
| | Search mapping / source changes | `search:source-map:remove` → `search:setup:source-map` → `search:setup:sources` (queue worker restart may also be needed) | | ||
| | Publisher plugin / queue config | queue worker restart — project-specific; document, don't auto-run | | ||
| | Data import CSVs (entity-specific) | `data:import:<entity>` (verify the entity importer exists in `docker/sdk console list`) | | ||
| | Stale Zed Twig (rare; symptom: BO still shows old template after a clean refresh) | `rm -f src/Generated/Zed/Twig/codeBucket/.pathCache` → `twig:cache:warmer` | |
| 2. **Classify each touched file** against the mapping above. Group commands by what they target (codegen, schema, autoload, cache clear, cache warmup, frontend build, data import). | ||
| 3. **Determine order:** | ||
| - `docker/sdk cli composer dumpautoload --apcu` first if any `.php` was added/moved. | ||
| - Codegen next (transfers, scope-collection, etc.). |
There was a problem hiding this comment.
if we will generate a new transfer after docker/sdk cli composer dumpautoload --apcu we might have a problem
| 3. **Determine order:** | ||
| - `docker/sdk cli composer dumpautoload --apcu` first if any `.php` was added/moved. | ||
| - Codegen next (transfers, scope-collection, etc.). | ||
| - Schema (propel) next. |
| class AgentsGenerationStep implements AiToolSetupStepInterface | ||
| { | ||
| /** | ||
| * @param \SprykerSdk\Zed\AiDev\Communication\AiToolSetup\AiToolArtifactGeneratorInterface $generator |
There was a problem hiding this comment.
yes, otherwise sniffer fails.
| } | ||
|
|
||
| /** | ||
| * @return string |
There was a problem hiding this comment.
you don't need it when you have typehints
There was a problem hiding this comment.
the same - sniffer is the reason
… intake gating and QA skill integration
…nd add PRD source confirmation step to Spryker Customization skill
…/ai-dev into feature/cc-39001/prd-and-qa
CC-39001: Extend Spryker Feature Expert and Verifier plugins with PRD…
PR Description
Add a meaningful description here that will let us know what you want to fix with this PR or what functionality you want to add.
Steps before you submit a PR
contribution-license-agreement.txtfile with the following content:I hereby agree to Spryker's Contribution License Agreement in https://github.com/spryker/incremental-installer/blob/HASH_OF_COMMIT_YOU_ARE_BASING_YOUR_BRANCH_FROM_MASTER_BRANCH/CONTRIBUTING.md.This is a mandatory step to make sure you are aware of the license agreement and agree to it.
HASH_OF_COMMIT_YOU_ARE_BASING_YOUR_BRANCH_FROM_MASTER_BRANCHis a hash of the commit you are basing your branch from the master branch. You can take it from commits list of master branch before you submit a PR.Checklist