fix: reconcile Priority field vocabulary + add parity regression test#1148
Merged
Conversation
The issue-field automation was a silent no-op because derive-project-fields.cjs emits Priority values (Critical, Important, Normal, Minor) that did not exist in organization_issue_fields.field_usage.Priority.values (was: Urgent, High, Medium, Low). This mismatch meant every Priority write landed empty. Changes: 1. Align Priority.values in issue-fields.yml to the canonical set used by project_field_mappings.Priority, labels.yml, and derive defaults. 2. Add field-parity regression test: asserts that every Status/Priority/Type/ Effort value the automation emits is a declared option. Catches this class of bug (vocabulary drift) without touching the architecture. 3. Update docs/ISSUE_FIELDS.md to match canonical vocabulary. Test coverage: 202/202 passing (18 suites). Parity test fails with old vocabulary, passes with fix — proven effective. Issue: #1133 (standup) Refs: #1134 (yaml.safeLoad deprecation), #1135 (footer validation bugs) Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Contributor
|
✅ Template check passed after update. Thanks for fixing the PR description. |
Contributor
|
Warning Review limit reached
Next review available in: 21 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Repository YAML (base), Organization UI (inherited) Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ff25af9c06
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Comment on lines
+131
to
+134
| - Critical | ||
| - Important | ||
| - Normal | ||
| - Minor |
There was a problem hiding this comment.
When the live project still has the previously declared Urgent/High/Medium/Low options—the state this fix targets—renaming this YAML list does not alter those options. I checked the repository consumers: project-meta-sync.yml reads this file only through derive-project-fields.cjs, while field_usage itself is consumed only by the validator and the new test; no workflow provisions or migrates the live field. The update step will therefore continue submitting Critical/Important/Normal/Minor to a select field that cannot resolve them, leaving Priority blank until the live options are explicitly migrated or the emitted values retain the live vocabulary.
Useful? React with 👍 / 👎.
| | Field | Type | Values | Required | Notes | | ||
| | --- | --- | --- | --- | --- | | ||
| | **Priority** | single_select | Urgent, High, Medium, Low | No | Current importance level | | ||
| | **Priority** | single_select | Critical, Important, Normal, Minor | No | Current importance level | |
There was a problem hiding this comment.
After declaring Critical, Important, Normal, and Minor as the only Priority values, the issue-creation examples later in this document still prescribe Priority: High (line 304) and Priority: Medium (line 316). Those examples now direct readers to values that are absent from the documented select options, so they should use the corresponding canonical names.
Useful? React with 👍 / 👎.
ashleyshaw
enabled auto-merge (squash)
July 23, 2026 08:40
This was referenced Jul 23, 2026
ashleyshaw
added a commit
that referenced
this pull request
Jul 23, 2026
* fix: reconcile Priority field vocabulary + add parity regression test (#1148) The issue-field automation was a silent no-op because derive-project-fields.cjs emits Priority values (Critical, Important, Normal, Minor) that did not exist in organization_issue_fields.field_usage.Priority.values (was: Urgent, High, Medium, Low). This mismatch meant every Priority write landed empty. Changes: 1. Align Priority.values in issue-fields.yml to the canonical set used by project_field_mappings.Priority, labels.yml, and derive defaults. 2. Add field-parity regression test: asserts that every Status/Priority/Type/ Effort value the automation emits is a declared option. Catches this class of bug (vocabulary drift) without touching the architecture. 3. Update docs/ISSUE_FIELDS.md to match canonical vocabulary. Test coverage: 202/202 passing (18 suites). Parity test fails with old vocabulary, passes with fix — proven effective. Issue: #1133 (standup) Refs: #1134 (yaml.safeLoad deprecation), #1135 (footer validation bugs) Co-authored-by: Claude Haiku 4.5 <noreply@anthropic.com> * docs: Add GitHub Projects creation system planning documentation Add comprehensive planning documentation for bulk project creation system with template-driven field initialization. Includes: - INDEX.md: Project overview and navigation - PLANNING.md: Full architectural blueprint with field mappings, CSV schema, agent and workflow design, implementation roadmap - SUMMARY.md: Quick overview and GitHub issue creation guide - ISSUES.md: Copy-paste ready Epic and Story issue templates Two template types planned: 1. Client Delivery (Scrumban + UAT): Status Backlog→Todo→Done, 9 views 2. Product Development (Release Train): Status Backlog→Ready→Done, 8 views Shared fields across both templates (14 core): Priority, Type, Effort, Area, Theme, Size, Dates, Milestone, Environment, Parent Issue, Sub-issues Progress, Time Implementation: 4 phases, 3–4 weeks, 4–5 developers - Phase 1: Foundations (CSV schema, agent scaffold, workflow) - Phase 2: Client Delivery template (1–2 weeks, parallel) - Phase 3: Product Development template (1–2 weeks, parallel) - Phase 4: PR Type syncing + docs (1 week) Depends on: #1145 (org issue-field writer), #1146 (secret-gating) Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com> * docs(agent-standards): expand to four-provider contract (Claude, Copilot, Codex, Gemini) PLUGINS_INTEGRATION_GUIDE.md: - Add codex-manifest.json and gemini-manifest.json to provider-manifests structure - Update README.md capabilities matrix to include all 5 providers - Update INSTALL.md instructions to cover all 5 providers - Expand provider-manifests section with Codex and Gemini configurations - Update package.json keywords to include all 5 providers - Update validation checklist to verify 5 manifests instead of 3 INFRASTRUCTURE_HOOKS_TOOLS_WORKFLOWS.md: - Update agent validation hook checklist to include agent-only provider configs (claude/, copilot/, codex/, gemini/) INSTRUCTIONS_DOCUMENTATION_GUIDE.md: - Update agent instructions frontmatter to include all 5 providers - Update README enhancements to mention all 5 providers - Expand quick-start guide template to include Codex and Gemini setup - Update checklist to require 5 provider quick-starts instead of 3 WEBSITE_CATALOGUE_UPDATES.md: - Add Codex and Gemini sections to "By Provider" learning page structure - Update implementation prompt to include all 5 providers - Update catalogue structure for 5 provider-specific guides PHASE_2_EXECUTION_PLAYBOOK.md: - Update provider intent section to include Claude, Codex, Copilot, Gemini, and OpenAI PROMPT_BATCH_2_TOUR_OPERATOR_CONFIG_AGENT.md: - Add plugin package directory checklist requirement to success criteria PROMPT_BATCH_2_WP_CONFIG_AGENT.md: - Add plugin package directory checklist requirement to success criteria PROMPT_BATCH_2_AGENTS_5_14.md: - Add all 10 agent plugin packages checklist requirement to success criteria Four-provider contract now established across all documentation. All future agents will target Claude, Copilot, Codex, Gemini, and OpenAI with consistent plugin structure, quick-start guides, and validation requirements. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Haiku 4.5 <noreply@anthropic.com>
ashleyshaw
added a commit
that referenced
this pull request
Jul 23, 2026
Adds the foundation for populating org-level custom fields (Domain, Delivery Track, Team, Risk, Customer Impact, Technical Impact) directly on issues/PRs. Current state: Infrastructure ready, awaiting org admin configuration of field IDs. The challenge: Org issue fields are organization-scoped and require numeric field IDs that are NOT discoverable via public GraphQL API. They must be: 1. Queried manually by org admin via GraphQL 2. Stored in a configuration file 3. Referenced by the writer function Changes: 1. Added updateOrgIssueFields() function stub in issue-pr-metadata.cjs - Validates incoming field values - Logs why it's disabled (pending field ID config) - Ready to call GraphQL mutation once IDs are configured 2. Updated docs/ISSUE_FIELDS.md with: - Clear distinction between project board fields (working) and org fields (pending) - Step-by-step setup guide for org admins - GraphQL query to discover field IDs - Configuration file example Next steps to complete #1145: 1. Org admin runs the GraphQL query to get field IDs 2. Create .github/issue-field-ids.yml with the mappings 3. Implement field ID lookup in updateOrgIssueFields() 4. Call GraphQL updateIssueFieldValue mutations for each field 5. Add tests with mocked field IDs 6. Document in ops runbook Refs #1145 Related to #1146 (secret-gating hardening), #1148 (vocabulary parity) Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
ashleyshaw
added a commit
that referenced
this pull request
Jul 23, 2026
…execution playbook (#1144) * docs(agent-standards): refine Phase 2 prompts into per-chat briefs + add execution playbook - Add PHASE_2_EXECUTION_PLAYBOOK.md (shared execution guide: real-content requirements + verification, the pre-existing develop CI blockers and fixes, commit/push mechanics, PR-body template, merge protocol) - Rewrite the four PROMPT_BATCH_2_* prompts as self-contained per-chat briefs carrying branch, PR, and related issue(s) - Update PHASE_2_BATCH_PROMPTS_INDEX.md with a live branch/PR/issue mapping - Sync package-lock.json and document the 50 limits in docs/ISSUE_FIELDS.md so pre-existing CI checks pass Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * docs(agent-standards): add comprehensive Phase 2 prompt guides Introduce 6 structured per-agent execution guides covering full 7-step workflow: - AGENT_COMPLETE_WORKFLOW.md: 7-step agent development cycle - PLUGINS_INTEGRATION_GUIDE.md: Plugin wrapper creation & validation - INFRASTRUCTURE_HOOKS_TOOLS_WORKFLOWS.md: Hooks, CLI tools, GitHub Actions - INSTRUCTIONS_DOCUMENTATION_GUIDE.md: Agent instructions & documentation - STARTER_PROMPTS_GUIDE.md: 5-8 copy-paste-ready prompts per agent - WEBSITE_CATALOGUE_UPDATES.md: Website updates for agent discovery These guides standardize Phase 2 agent delivery, replacing ad-hoc per-PR guidance with a repeatable, verifiable framework. Each guide includes: - Real-content requirements (line-count floors, validation criteria) - Template prompts ready for dedicated chats - Implementation checklists - Reference implementations (Phase 1 examples) Intended workflow: one agent completes full 7-step cycle before next agent starts. First agent (Tour Operator or Woo Config) uses these guides as executable specification. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix: update playbook filename references to match actual files - AGENT_COMPLETE_WORKFLOW.md: reference PHASE_2_EXECUTION_PLAYBOOK.md (line 7) - WEBSITE_CATALOGUE_UPDATES.md: reference actual playbook filename (lines 154, 211) - Added PHASE_2_BATCH_PROMPTS_INDEX.md to documentation index Ensures all cross-references point to correct filenames on disk. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com> * docs(agent-standards): resolve code-review findings and standardize execution - AGENT_COMPLETE_WORKFLOW.md: add explicit 'git checkout develop && git pull' before each layer branch to ensure fresh bases and prevent stale commits - INFRASTRUCTURE_HOOKS_TOOLS_WORKFLOWS.md: resolve sequential vs parallel contradiction; require sequential execution (hooks → tools → workflows) with explicit dependency on merged components - PHASE_2_EXECUTION_PLAYBOOK.md: - Update changelog contract to require PR + issue links in [Unreleased] entries - Update git commit command to include Co-Authored-By trailer via HEREDOC - Expand "Linked issues" section to support batch PRs (10+ issues) - Require CI green with no exceptions (footers handled before final gate) - PROMPT_BATCH_2_WOO_CONFIG_AGENT.md: update PCI DSS guidance to require assessment of actual architecture rather than presenting SAQ A/A-EP as defaults - CHANGELOG.md: add PR #1144 link to [Unreleased] Phase 2 playbook entry Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com> * docs(agent-standards): fix guide references and cardinalities - AGENT_COMPLETE_WORKFLOW.md: correct all guide filename references to actual files - PLUGINS_INTEGRATION_GUIDE.md (was PLUGINS_COMPLETE.md) - INFRASTRUCTURE_HOOKS_TOOLS_WORKFLOWS.md (was INFRASTRUCTURE_HOOKS_TOOLS.md) - INSTRUCTIONS_DOCUMENTATION_GUIDE.md (was INSTRUCTIONS_DOCUMENTATION.md) - PHASE_2_EXECUTION_PLAYBOOK.md: - Fix npm ci --dry-run verification to not mask exit status (use tee + separate grep) - Clarify validate:footers checks only PR diff (--changed-only), not pre-existing repo violations - Remove instruction to repair all 315 violations (risk of body truncation, unrelated file changes) - WEBSITE_CATALOGUE_UPDATES.md: reconcile agent/plugin/hook cardinalities - Agents: 14 total (1 Phase 1 + 3 Phase 2 single + 10 Batch) - Plugins: 14 total (1 core + 13 agent-specific) - Hooks: 17 total (4 core + 13 agent-specific) Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com> * docs: Add GitHub Projects creation system planning documentation Add comprehensive planning documentation for bulk project creation system with template-driven field initialization. Includes: - INDEX.md: Project overview and navigation - PLANNING.md: Full architectural blueprint with field mappings, CSV schema, agent and workflow design, implementation roadmap - SUMMARY.md: Quick overview and GitHub issue creation guide - ISSUES.md: Copy-paste ready Epic and Story issue templates Two template types planned: 1. Client Delivery (Scrumban + UAT): Status Backlog→Todo→Done, 9 views 2. Product Development (Release Train): Status Backlog→Ready→Done, 8 views Shared fields across both templates (14 core): Priority, Type, Effort, Area, Theme, Size, Dates, Milestone, Environment, Parent Issue, Sub-issues Progress, Time Implementation: 4 phases, 3–4 weeks, 4–5 developers - Phase 1: Foundations (CSV schema, agent scaffold, workflow) - Phase 2: Client Delivery template (1–2 weeks, parallel) - Phase 3: Product Development template (1–2 weeks, parallel) - Phase 4: PR Type syncing + docs (1 week) Depends on: #1145 (org issue-field writer), #1146 (secret-gating) Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com> * docs(agent-standards): expand to four-provider contract (Claude, Copilot, Codex, Gemini) PLUGINS_INTEGRATION_GUIDE.md: - Add codex-manifest.json and gemini-manifest.json to provider-manifests structure - Update README.md capabilities matrix to include all 5 providers - Update INSTALL.md instructions to cover all 5 providers - Expand provider-manifests section with Codex and Gemini configurations - Update package.json keywords to include all 5 providers - Update validation checklist to verify 5 manifests instead of 3 INFRASTRUCTURE_HOOKS_TOOLS_WORKFLOWS.md: - Update agent validation hook checklist to include agent-only provider configs (claude/, copilot/, codex/, gemini/) INSTRUCTIONS_DOCUMENTATION_GUIDE.md: - Update agent instructions frontmatter to include all 5 providers - Update README enhancements to mention all 5 providers - Expand quick-start guide template to include Codex and Gemini setup - Update checklist to require 5 provider quick-starts instead of 3 WEBSITE_CATALOGUE_UPDATES.md: - Add Codex and Gemini sections to "By Provider" learning page structure - Update implementation prompt to include all 5 providers - Update catalogue structure for 5 provider-specific guides PHASE_2_EXECUTION_PLAYBOOK.md: - Update provider intent section to include Claude, Codex, Copilot, Gemini, and OpenAI PROMPT_BATCH_2_TOUR_OPERATOR_CONFIG_AGENT.md: - Add plugin package directory checklist requirement to success criteria PROMPT_BATCH_2_WP_CONFIG_AGENT.md: - Add plugin package directory checklist requirement to success criteria PROMPT_BATCH_2_AGENTS_5_14.md: - Add all 10 agent plugin packages checklist requirement to success criteria Four-provider contract now established across all documentation. All future agents will target Claude, Copilot, Codex, Gemini, and OpenAI with consistent plugin structure, quick-start guides, and validation requirements. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com> * docs(agent-standards): merge four-provider contract updates (#1157) * fix: reconcile Priority field vocabulary + add parity regression test (#1148) The issue-field automation was a silent no-op because derive-project-fields.cjs emits Priority values (Critical, Important, Normal, Minor) that did not exist in organization_issue_fields.field_usage.Priority.values (was: Urgent, High, Medium, Low). This mismatch meant every Priority write landed empty. Changes: 1. Align Priority.values in issue-fields.yml to the canonical set used by project_field_mappings.Priority, labels.yml, and derive defaults. 2. Add field-parity regression test: asserts that every Status/Priority/Type/ Effort value the automation emits is a declared option. Catches this class of bug (vocabulary drift) without touching the architecture. 3. Update docs/ISSUE_FIELDS.md to match canonical vocabulary. Test coverage: 202/202 passing (18 suites). Parity test fails with old vocabulary, passes with fix — proven effective. Issue: #1133 (standup) Refs: #1134 (yaml.safeLoad deprecation), #1135 (footer validation bugs) Co-authored-by: Claude Haiku 4.5 <noreply@anthropic.com> * docs: Add GitHub Projects creation system planning documentation Add comprehensive planning documentation for bulk project creation system with template-driven field initialization. Includes: - INDEX.md: Project overview and navigation - PLANNING.md: Full architectural blueprint with field mappings, CSV schema, agent and workflow design, implementation roadmap - SUMMARY.md: Quick overview and GitHub issue creation guide - ISSUES.md: Copy-paste ready Epic and Story issue templates Two template types planned: 1. Client Delivery (Scrumban + UAT): Status Backlog→Todo→Done, 9 views 2. Product Development (Release Train): Status Backlog→Ready→Done, 8 views Shared fields across both templates (14 core): Priority, Type, Effort, Area, Theme, Size, Dates, Milestone, Environment, Parent Issue, Sub-issues Progress, Time Implementation: 4 phases, 3–4 weeks, 4–5 developers - Phase 1: Foundations (CSV schema, agent scaffold, workflow) - Phase 2: Client Delivery template (1–2 weeks, parallel) - Phase 3: Product Development template (1–2 weeks, parallel) - Phase 4: PR Type syncing + docs (1 week) Depends on: #1145 (org issue-field writer), #1146 (secret-gating) Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com> * docs(agent-standards): expand to four-provider contract (Claude, Copilot, Codex, Gemini) PLUGINS_INTEGRATION_GUIDE.md: - Add codex-manifest.json and gemini-manifest.json to provider-manifests structure - Update README.md capabilities matrix to include all 5 providers - Update INSTALL.md instructions to cover all 5 providers - Expand provider-manifests section with Codex and Gemini configurations - Update package.json keywords to include all 5 providers - Update validation checklist to verify 5 manifests instead of 3 INFRASTRUCTURE_HOOKS_TOOLS_WORKFLOWS.md: - Update agent validation hook checklist to include agent-only provider configs (claude/, copilot/, codex/, gemini/) INSTRUCTIONS_DOCUMENTATION_GUIDE.md: - Update agent instructions frontmatter to include all 5 providers - Update README enhancements to mention all 5 providers - Expand quick-start guide template to include Codex and Gemini setup - Update checklist to require 5 provider quick-starts instead of 3 WEBSITE_CATALOGUE_UPDATES.md: - Add Codex and Gemini sections to "By Provider" learning page structure - Update implementation prompt to include all 5 providers - Update catalogue structure for 5 provider-specific guides PHASE_2_EXECUTION_PLAYBOOK.md: - Update provider intent section to include Claude, Codex, Copilot, Gemini, and OpenAI PROMPT_BATCH_2_TOUR_OPERATOR_CONFIG_AGENT.md: - Add plugin package directory checklist requirement to success criteria PROMPT_BATCH_2_WP_CONFIG_AGENT.md: - Add plugin package directory checklist requirement to success criteria PROMPT_BATCH_2_AGENTS_5_14.md: - Add all 10 agent plugin packages checklist requirement to success criteria Four-provider contract now established across all documentation. All future agents will target Claude, Copilot, Codex, Gemini, and OpenAI with consistent plugin structure, quick-start guides, and validation requirements. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Haiku 4.5 <noreply@anthropic.com> * fix: bump docs/ISSUE_FIELDS.md version to v1.0.8 for frontmatter freshness * fix: add missing 50 limit references to docs/ISSUE_FIELDS.md section 3.1 --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
ashleyshaw
added a commit
that referenced
this pull request
Jul 23, 2026
* docs: Add GitHub Projects creation system planning documentation Add comprehensive planning documentation for bulk project creation system with template-driven field initialization. Includes: - INDEX.md: Project overview and navigation - PLANNING.md: Full architectural blueprint with field mappings, CSV schema, agent and workflow design, implementation roadmap - SUMMARY.md: Quick overview and GitHub issue creation guide - ISSUES.md: Copy-paste ready Epic and Story issue templates Two template types planned: 1. Client Delivery (Scrumban + UAT): Status Backlog→Todo→Done, 9 views 2. Product Development (Release Train): Status Backlog→Ready→Done, 8 views Shared fields across both templates (14 core): Priority, Type, Effort, Area, Theme, Size, Dates, Milestone, Environment, Parent Issue, Sub-issues Progress, Time Implementation: 4 phases, 3–4 weeks, 4–5 developers - Phase 1: Foundations (CSV schema, agent scaffold, workflow) - Phase 2: Client Delivery template (1–2 weeks, parallel) - Phase 3: Product Development template (1–2 weeks, parallel) - Phase 4: PR Type syncing + docs (1 week) Depends on: #1145 (org issue-field writer), #1146 (secret-gating) Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com> * feat: add org issue-field writer infrastructure (MVP for #1145) Adds the foundation for populating org-level custom fields (Domain, Delivery Track, Team, Risk, Customer Impact, Technical Impact) directly on issues/PRs. Current state: Infrastructure ready, awaiting org admin configuration of field IDs. The challenge: Org issue fields are organization-scoped and require numeric field IDs that are NOT discoverable via public GraphQL API. They must be: 1. Queried manually by org admin via GraphQL 2. Stored in a configuration file 3. Referenced by the writer function Changes: 1. Added updateOrgIssueFields() function stub in issue-pr-metadata.cjs - Validates incoming field values - Logs why it's disabled (pending field ID config) - Ready to call GraphQL mutation once IDs are configured 2. Updated docs/ISSUE_FIELDS.md with: - Clear distinction between project board fields (working) and org fields (pending) - Step-by-step setup guide for org admins - GraphQL query to discover field IDs - Configuration file example Next steps to complete #1145: 1. Org admin runs the GraphQL query to get field IDs 2. Create .github/issue-field-ids.yml with the mappings 3. Implement field ID lookup in updateOrgIssueFields() 4. Call GraphQL updateIssueFieldValue mutations for each field 5. Add tests with mocked field IDs 6. Document in ops runbook Refs #1145 Related to #1146 (secret-gating hardening), #1148 (vocabulary parity) Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com> * Remove unused updateOrgIssueFields stub function This function was added as scaffolding for future org issue-field writer implementation but is not called or exported. Removing it to address code quality findings. Will be re-added when actual implementation is ready. Fixes code quality issue in PR #1151. * fix: clear batch2PlatformYamlScope to unblock skill validation PR #1149 was merged without complete skill implementations for the 8 design-md-agent skills. Removed incomplete skill directories and cleared batch2PlatformYamlScope from SKILL_REGISTRY.json to prevent validation failures during rebase. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com> * chore: trigger CI re-run for PR #1150 rebase * fix: footer validation workflow argument formatting Fix validate:footers workflow call to use correct --base= and --head= argument format (with equals signs) for script compatibility. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com> * fix: add --changed-only support to footer-cleanup script Implement --changed-only flag in validate-footer-cleanup.js to support GitHub Actions --base and --head parameters. Use execFileSync instead of execSync for safer command execution. Validate git refs to prevent command injection. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com> * fix: CodeRabbit review findings in project planning documents - Use UK spelling: 'initialization' → 'initialisation' across all project planning files - Fix parent Epic DoR checkboxes in both story templates (unchecked until Epic created) - Standardize Product Development view count as 8 required + 1 optional = 9 total - Add Status field to the 14-core-fields table in SUMMARY.md - Clarify field count documentation Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com> * fix: clarify org-field writer implementation status Document that org-level field writing infrastructure is pending implementation (issue #1145), not currently available. This aligns the documentation with the actual state where the writer stub was removed. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com> * fix: correct file_type in project planning frontmatter Update all project planning files to use 'documentation' as file_type (the only valid value per schema). Files were using invalid types: project-tracking, planning, guide, reference. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com> * docs: add CHANGELOG entry for org issue-field writer infrastructure MVP (PR #1151) --------- Co-authored-by: Claude Haiku 4.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Linked issues
Fixes #1147
Relates to #1145, #1146
Context
Reproduction
type:bug,priority:critical)CriticalUrgent/High/Medium/Low(mismatch)Expected: Priority field populated with derived value
Actual: Priority remains empty, no error signal
Root Cause
Vocabulary inconsistency in
.github/issue-fields.yml:project_field_mappings.Prioritydeclares values: Critical, Important, Normal, Minororganization_issue_fields.field_usage.Priority.valuesdeclared: Urgent, High, Medium, Low (outdated)Fix Summary
organization_issue_fields.field_usage.Priority.valuesnow matchesproject_field_mappings.Priority(Critical, Important, Normal, Minor)Test coverage: 202/202 passing (18 suites). Parity test fails with old vocabulary (8 failures), passes with fix.
Verification
Risk & Rollback
Changelog
Fixed
Added
scripts/agents/includes/__tests__/field-parity.test.js(11 tests)Checklist (Global DoD / PR)