Add AGENTS.md guidance to check all workspace metadata files when fixing appConfigExamples structure
Nobody has claimed this yet.
Assessment
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Newbie friendliness
- 86/100
- Issue type
- Documentation
- Clarity
- Clearly specified
- Activity status
- Active
- Domain
- documentation
Research direction
Read the AGENTS.md section "Working with Workspaces" and the existing overlay/patch guidance first. Inspect the workspace metadata/*.yaml files and use grep to understand the shared appConfigExamples pattern; done means a paragraph explains checking all sibling files before completing a structural fix.
Written by the indexing model from the issue text.
Description
What happened
PR #3225 (Aug 10) fixed a broken appConfigExamples structure (flat baseUrl string instead of nested cluster object) in one metadata file (kserve-kubeflow-connector-backend.yaml), but two sibling metadata files in the same workspace (model-catalog.yaml, techdoc-url-reader.yaml) had the identical broken pattern. Issue #3221 even noted one sibling had the same pattern, but the code agent only fixed the primary file. All three files contribute to the same merged app-config.dynamic-plugins.yaml at deployment time, so any one broken file poisons the merged config. This caused 8 days of continuous smoke test failures (Aug 10–18) until the retro agent caught it via issue #3310, leading to fix PR #3312.
What could go better
The code agent had no repo-specific guidance telling it that metadata files within a workspace share a deployment config namespace and that structural fixes must be applied across all siblings. The general-purpose code agent behavior (agents#129) would help, but repo-specific AGENTS.md guidance is immediately actionable and provides the domain context that metadata files in a workspace are merged at deployment time. Existing issue #3222 covers guidance for NEW plugin additions (validating against upstream config.d.ts), and #3299 covers E2E config variants — but neither addresses the scenario of fixing EXISTING metadata structure across sibling files. Confidence: high — the root cause (incomplete fix) and the fix pattern (check all siblings) are well-established by the PR #3225 → #3312 sequence.
Proposed change
Add a paragraph to the AGENTS.md section "Working with Workspaces" (or as a subsection under the existing overlay/patch guidance) with guidance like:
Fixing appConfigExamples structure: When fixing a structural issue in any
metadata/*.yamlfile'sappConfigExamples(e.g., correcting nesting, fixing schema violations), always check ALL othermetadata/*.yamlfiles in the same workspace for the same pattern. All plugins in a workspace contribute to the mergedapp-config.dynamic-plugins.yamlat deployment time — a structural bug in any one file can break the entire deployment even if other files are correct. Usegrepor equivalent to search for the broken pattern across all metadata files before considering the fix complete.
This is a repo-level fix that does not depend on the agent-layer improvement tracked in fullsend-ai/agents#129.
Validation criteria
The next time a code agent fixes an appConfigExamples structural issue in a workspace metadata file, it should check and fix all metadata/*.yaml files in the same workspace with the same pattern. Verify on the next 3 code agent PRs that touch workspace metadata — the agent should demonstrate awareness of sibling files in its PR description or commit message.
Generated by retro agent from https://github.com/redhat-developer/rhdh-plugin-export-overlays/pull/3312
- Dominant language
- TypeScript
- Stars
- 9
- Forks
- 72
- Avg merge
- 3d 9h
- Merged PRs (30d)
- 133
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from redhat-developer/rhdh-plugin-export-overlays
-
documentation non-workspace-changes ready-for-triage ready-to-code
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
redhat-developer/rhdh-plugin-export-overlays#3815 · 3 comments ·
-
documentation non-workspace-changes ready-for-triage ready-to-code
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
redhat-developer/rhdh-plugin-export-overlays#3810 · 3 comments ·
-
Add AGENTS.md review guidance: Prettier/ESLint/TypeScript violations in e2e-tests are CI-blocking Opendocumentation ready-for-triage ready-to-code
Difficulty 1/5 Under an hour Newbie friendliness 88/100
redhat-developer/rhdh-plugin-export-overlays#3792 · 3 comments ·
-
e2e-failure ready-to-code
Difficulty 1/5 Under an hour Newbie friendliness 88/100
redhat-developer/rhdh-plugin-export-overlays#3789 · 1 comment ·
-
e2e-failure ready-to-code
Difficulty 1/5 Under an hour Newbie friendliness 88/100
redhat-developer/rhdh-plugin-export-overlays#3788 · 1 comment ·
All issues in redhat-developer/rhdh-plugin-export-overlays
Similar issues
-
calcite-components needs triage refactor
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Esri/calcite-design-system#15203 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 91/100
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficulty 1/5 Under an hour Newbie friendliness 95/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Automattic/studio#4908 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100