Skip to content

Migrate from gpt-5.5 to claude-opus-4.8#63

Closed
meerakurup wants to merge 1 commit into
microsoft-foundry:mainfrom
meerakurup:main
Closed

Migrate from gpt-5.5 to claude-opus-4.8#63
meerakurup wants to merge 1 commit into
microsoft-foundry:mainfrom
meerakurup:main

Conversation

@meerakurup

Copy link
Copy Markdown
Contributor

Description

Adds a new Forgebook recipe for migrating a Chat Completions workload from gpt-5.5 to claude-opus-4-8 on Microsoft Foundry.

The notebook teaches a side-by-side migration pattern: keep the existing GPT-5.5 path live, add Claude behind the same adapter contract, compare both providers with eval gates, then promote only after schema/tool parity, structured output retry rate, quality, and latency checks pass.

New content and contributor registration:

  • Added meerakurup as a new author in authors.yaml, including name, title, avatar, and GitHub profile.
  • Registered the new notebook in registry.yaml with slug, path, title, description, date, author, and allowed tags.
  • Added notebooks/migrate-gpt-5-5-to-claude-opus-4-8.ipynb.
  • Included runnable examples for:
    • OpenAI Chat Completions baseline
    • Anthropic Messages call on Foundry
    • Provider-neutral adapter
    • Tool schema translation
    • Structured output validation and retry
    • Streaming normalization
    • Promotion gates and rollout guidance

Review focus

Please focus review on:

  • Product accuracy for Claude on Microsoft Foundry, especially endpoint shape, auth audience, SDK usage, Marketplace billing, and model/deployment naming.
  • Whether the migration guidance is correctly positioned as side-by-side validation before user-facing rollout.
  • Adapter design and whether the Conversation / Response contract is a reasonable reusable pattern.
  • Eval gate thresholds and whether schema/tool parity, structured output retry rate, quality, and latency are framed correctly.
  • Notebook runnability, including prerequisites, .env configuration, quota assumptions, and common error recovery.
  • Registry metadata, tags, author entry, and title/description quality for the Forgebook site.

Checklist

Notebook contributions

Skip if this PR only touches site code.

  • Recipe author is an approved Microsoft Forgebook author, or this contribution has maintainer approval
  • Recipe was drafted or validated through the internal authoring workflow
  • Foundry PM, engineering, or DX reviewer has checked product accuracy and positioning
  • Notebook added to notebooks/ directory
  • Entry added to registry.yaml with all required fields (slug, path, title, authors)
  • Approved author entry exists in authors.yaml (with at least name and title)
  • Tags are from the allowed list in tags.yaml
  • Registry validation passes: cd scripts && npx tsx validate-registry.ts
  • Notebook runs cleanly end-to-end
  • Cell outputs cleared before committing
  • No site-specific metadata inside the notebook
  • No secrets, tenant-specific values, or private endpoints are committed
  • Images stored in notebooks/media/<slug>/ with descriptive alt text
  • Data files stored in notebooks/data/<slug>/ when applicable

Site changes

Skip if this PR only adds a notebook.

  • Site builds without errors: cd site && npm run build
  • No TypeScript errors: cd site && npx astro check

@meerakurup
meerakurup requested a review from a team as a code owner June 30, 2026 21:58
@meerakurup meerakurup closed this Jul 7, 2026
nicholasdbrady added a commit that referenced this pull request Jul 8, 2026
…tributors (#67)

* Fix fork PR preview deploy via workflow_run split, gated to forgebook-contributors

Fork-based PRs always get a read-only GITHUB_TOKEN on pull_request events,
regardless of the author's actual repo/team write access, causing the
gh-pages deploy step to 403 (seen on PR #63 and #66).

- preview.yml: trimmed to unprivileged build/validate/test; uploads the
  built site and PR metadata as artifacts instead of deploying directly.
- preview-deploy.yml (new): workflow_run consumer with write access; only
  ever touches the pre-built static artifact, never PR code. Gates the
  actual gh-pages deploy + preview comment on forgebook-contributors team
  membership, via a maintainer-owned PAT (FORGEBOOK_TEAM_READ_TOKEN secret)
  since the default GITHUB_TOKEN can't read team membership.
- preview-cleanup.yml (new): moved the PR-close cleanup job here on
  pull_request_target, since it has the same fork-token problem but is safe
  to run privileged (no PR code execution, just deletes a directory on the
  maintainer-controlled gh-pages branch).
- CONTRIBUTING.md: note that auto-deployed previews require team
  membership; others still get build/test signal plus a comment.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Fix CodeQL code-injection findings: pass step outputs via env, not inline template

github-script steps interpolated step outputs directly into the JS source
via ${{ }} template expressions, which CodeQL flags as a code-injection
risk since the value flows from a workflow_run artifact. Switched all
occurrences (pr_number and author) to pass through env: and read via
process.env instead, which is the standard mitigation.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

---------

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant