Skip to content

Streamline operator summaries and PR validation UX #381

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
efraespada merged 2 commits into from
Sep 15, 2026
Merged

Streamline operator summaries and PR validation UX #381

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
37a3c1b
codex-operator-summary-ux: streamline operator summaries
efraespada Sep 15, 2026
91ff6d6
codex-operator-summary-ux: aggregate routine action results
efraespada Sep 15, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion build/api/index.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6153,7 +6153,7 @@ Write every human-readable sentence in {{targetLocale}}. Preserve code identifie
3. Use the issue description below for context and intent.
4. Provide \`overview\` as one to three sentences that state the outcome and why it matters.
5. Provide \`whatChangedHeading\` as the plain-text {{targetLocale}} equivalent of "What changed" and \`changes\` as two to six short, outcome-oriented items. Do not inventory files, use-case names, internal categories, or every implementation step.
6. Provide \`validationHeading\` as the plain-text {{targetLocale}} equivalent of "Validation" and \`validation\` with only commands, automated checks, or manual scenarios supported by available evidence. Never claim a check passed unless the evidence says it did, and never infer that result from the presence of test files or commands. When no execution evidence is available, say concisely in {{targetLocale}} that validation was not run or was not available.
6. When execution or manual-verification evidence is available, provide \`validationHeading\` as the plain-text {{targetLocale}} equivalent of "Validation" and \`validation\` with only the supported commands, automated checks, or manual scenarios. Never claim a check passed unless the evidence says it did, and never infer that result from the presence of test files or commands. When no verification evidence is available, set both fields to \`null\`; do not add a “not run” placeholder.
7. Set \`reviewNotesHeading\` and \`reviewNotes\` to \`null\` unless reviewers need material migration, security, performance, compatibility, rollout, manual-verification, risk, or follow-up context. Otherwise use the localized plain-text heading and one to four concise items. {{relatedIssueInstruction}}
8. Keep the description practical and normally under 4,000 characters. It must never exceed 12,000 characters. Do not use emoji, horizontal separators, generic checklists, empty headings, repeated statements, placeholder text, or unsupported "no impact" claims.
9. Return one JSON object with exactly \`outputLocale\`, \`overview\`, \`whatChangedHeading\`, \`changes\`, \`validationHeading\`, \`validation\`, \`reviewNotesHeading\`, \`reviewNotes\`, and \`closesLinkedIssue\`. Every content field is plain text except Markdown links, code spans, refs, and commands inside content values. The application renders the Markdown structure; do not include headings, bullet prefixes, a preamble, meta-commentary, or code fence in the values.
Expand Down
49 changes: 33 additions & 16 deletions build/cli/index.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -41457,9 +41457,9 @@ exports.PULL_REQUEST_DESCRIPTION_RESPONSE_SCHEMA = {
maxItems: 6,
items: { type: 'string', minLength: 1, maxLength: 1000 },
},
validationHeading: { type: 'string', minLength: 1, maxLength: 100 },
validationHeading: { type: ['string', 'null'], minLength: 1, maxLength: 100 },
validation: {
type: 'array',
type: ['array', 'null'],
minItems: 1,
maxItems: 8,
items: { type: 'string', minLength: 1, maxLength: 1000 },
Expand Down Expand Up @@ -45372,9 +45372,9 @@ function renderPullRequestDescriptionContent(payload, targetLocale, linkedIssueN
const rawContent = [
parsed.overview,
parsed.whatChangedHeading,
parsed.validationHeading,
...(parsed.validationHeading ? [parsed.validationHeading] : []),
...parsed.changes,
...parsed.validation,
...(parsed.validation ?? []),
...(parsed.reviewNotesHeading ? [parsed.reviewNotesHeading] : []),
...(parsed.reviewNotes ?? []),
];
Expand All @@ -45383,19 +45383,21 @@ function renderPullRequestDescriptionContent(payload, targetLocale, linkedIssueN
}
const overview = sanitizeBlock(parsed.overview);
const whatChangedHeading = sanitizeInline(parsed.whatChangedHeading);
const validationHeading = sanitizeInline(parsed.validationHeading);
const validationHeading = parsed.validationHeading === null
? null
: sanitizeInline(parsed.validationHeading);
const changes = parsed.changes.map(sanitizeInline);
const validation = parsed.validation.map(sanitizeInline);
const validation = parsed.validation?.map(sanitizeInline) ?? null;
const reviewNotesHeading = parsed.reviewNotesHeading === null
? null
: sanitizeInline(parsed.reviewNotesHeading);
const reviewNotes = parsed.reviewNotes?.map(sanitizeInline) ?? null;
const allContent = [
overview,
whatChangedHeading,
validationHeading,
...(validationHeading ? [validationHeading] : []),
...changes,
...validation,
...(validation ?? []),
...(reviewNotesHeading ? [reviewNotesHeading] : []),
...(reviewNotes ?? []),
];
Expand All @@ -45406,15 +45408,17 @@ function renderPullRequestDescriptionContent(payload, targetLocale, linkedIssueN
return { kind: 'invalid', reason: 'sentence-count' };
}
if (hasDuplicates(changes, targetLocale)
|| hasDuplicates(validation, targetLocale)
|| (validation !== null && hasDuplicates(validation, targetLocale))
|| (reviewNotes && hasDuplicates(reviewNotes, targetLocale))) {
return { kind: 'invalid', reason: 'duplicate-item' };
}
const sections = [
overview,
`## ${whatChangedHeading}\n\n${renderList(changes)}`,
`## ${validationHeading}\n\n${renderList(validation)}`,
];
if (validationHeading && validation) {
sections.push(`## ${validationHeading}\n\n${renderList(validation)}`);
}
if (reviewNotesHeading && reviewNotes) {
sections.push(`## ${reviewNotesHeading}\n\n${renderList(reviewNotes)}`);
}
Expand All @@ -45433,18 +45437,31 @@ function parseContent(payload) {
return undefined;
}
const changes = stringArray(payload.changes, 2, 6);
const validation = stringArray(payload.validation, 1, 8);
if (typeof payload.overview !== 'string'
|| payload.overview.length > 1500
|| typeof payload.whatChangedHeading !== 'string'
|| payload.whatChangedHeading.length > 100
|| typeof payload.validationHeading !== 'string'
|| payload.validationHeading.length > 100
|| !changes
|| !validation
|| typeof payload.closesLinkedIssue !== 'boolean') {
return undefined;
}
let validation;
let validationHeading;
if (payload.validation === null) {
if (payload.validationHeading !== null)
return undefined;
validation = null;
validationHeading = null;
}
else {
const parsedValidation = stringArray(payload.validation, 1, 8);
if (!parsedValidation
|| typeof payload.validationHeading !== 'string'
|| payload.validationHeading.length > 100)
return undefined;
validation = parsedValidation;
validationHeading = payload.validationHeading;
}
let reviewNotes;
let reviewNotesHeading;
if (payload.reviewNotes === null) {
Expand All @@ -45466,7 +45483,7 @@ function parseContent(payload) {
overview: payload.overview,
whatChangedHeading: payload.whatChangedHeading,
changes,
validationHeading: payload.validationHeading,
validationHeading,
validation,
reviewNotesHeading,
reviewNotes,
Expand Down Expand Up @@ -79482,7 +79499,7 @@ Write every human-readable sentence in {{targetLocale}}. Preserve code identifie
3. Use the issue description below for context and intent.
4. Provide \`overview\` as one to three sentences that state the outcome and why it matters.
5. Provide \`whatChangedHeading\` as the plain-text {{targetLocale}} equivalent of "What changed" and \`changes\` as two to six short, outcome-oriented items. Do not inventory files, use-case names, internal categories, or every implementation step.
6. Provide \`validationHeading\` as the plain-text {{targetLocale}} equivalent of "Validation" and \`validation\` with only commands, automated checks, or manual scenarios supported by available evidence. Never claim a check passed unless the evidence says it did, and never infer that result from the presence of test files or commands. When no execution evidence is available, say concisely in {{targetLocale}} that validation was not run or was not available.
6. When execution or manual-verification evidence is available, provide \`validationHeading\` as the plain-text {{targetLocale}} equivalent of "Validation" and \`validation\` with only the supported commands, automated checks, or manual scenarios. Never claim a check passed unless the evidence says it did, and never infer that result from the presence of test files or commands. When no verification evidence is available, set both fields to \`null\`; do not add a “not run” placeholder.
7. Set \`reviewNotesHeading\` and \`reviewNotes\` to \`null\` unless reviewers need material migration, security, performance, compatibility, rollout, manual-verification, risk, or follow-up context. Otherwise use the localized plain-text heading and one to four concise items. {{relatedIssueInstruction}}
8. Keep the description practical and normally under 4,000 characters. It must never exceed 12,000 characters. Do not use emoji, horizontal separators, generic checklists, empty headings, repeated statements, placeholder text, or unsupported "no impact" claims.
9. Return one JSON object with exactly \`outputLocale\`, \`overview\`, \`whatChangedHeading\`, \`changes\`, \`validationHeading\`, \`validation\`, \`reviewNotesHeading\`, \`reviewNotes\`, and \`closesLinkedIssue\`. Every content field is plain text except Markdown links, code spans, refs, and commands inside content values. The application renders the Markdown structure; do not include headings, bullet prefixes, a preamble, meta-commentary, or code fence in the values.
Expand Down
Loading