feat(demos/migration): reorganize into use-cases/ + add general talk track with variants#126
Conversation
…track with variants - Move mulesoft-to-spring-boot-demo.md into use-cases/ subdirectory - Add general.md: Cloud-only coarse-grained migration talk track (orient/convert/verify/fan-out universal pattern) - Add general.platform.md: Desktop + Cloud variant using Cascade, Agent Command Center, Spaces, and one-click PR checkout
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| <a id="the-pattern"></a> | ||
| ## The Pattern | ||
|
|
||
| Every framework migration follows the same five-step sequence, regardless of |
There was a problem hiding this comment.
🚩 Uses of "every" in procedural descriptions are borderline but acceptable
Both new files use "every" in several places: general.md:21 ("Every framework migration follows the same five-step sequence"), general.md:130 ("Every subsequent conversion follows this playbook"), general.platform.md:145 ("Every subsequent Cloud session follows this playbook"), general.platform.md:156 ("every child session's status"). REVIEW.md flags overstatement language ("every", "all", "always") specifically "when describing probabilistic tools like DeepWiki or AI analysis." These uses describe the demo methodology/procedure itself rather than AI analysis output quality or coverage, so they don't clearly trigger the rule. However, since the migration IS performed by an AI agent, a strict reading could argue these overstate what Devin reliably does. Worth a reviewer judgment call.
Was this helpful? React with 👍 or 👎 to provide feedback.
| ## The Pattern | ||
|
|
||
| Every framework migration follows the same five-step sequence, regardless of | ||
| source or target technology: | ||
|
|
||
| ### 1. Orient | ||
|
|
||
| Devin reads the legacy codebase, maps endpoints/flows/components, and identifies | ||
| framework-specific constructs. It builds an internal model of the API surface: | ||
| route paths, request/response schemas, middleware, data access patterns, and | ||
| authentication flows. | ||
|
|
||
| ### 2. Convert one unit live | ||
|
|
||
| Translate one endpoint, controller, or component to the target framework — | ||
| complete with tests. This first conversion establishes the mapping between old | ||
| and new: naming conventions, dependency injection style, error handling idioms, | ||
| and DTO patterns. | ||
|
|
||
| ### 3. Contract verification | ||
|
|
||
| Tests run against an API specification (OpenAPI, WSDL, or contract tests) to | ||
| prove behavioral parity. The spec is the source of truth — endpoint existence, | ||
| request/response schemas, HTTP status codes, and error formats must match. | ||
|
|
||
| ### 4. Catch divergences | ||
|
|
||
| When contract tests fail, Devin investigates the source, identifies the gap | ||
| between legacy behavior and the new implementation, and fixes it. This loop | ||
| repeats until the converted unit passes all contract checks. | ||
|
|
||
| ### 5. Fan out in parallel | ||
|
|
||
| Child sessions convert remaining units concurrently using the proven playbook | ||
| from steps 1–4. Each child works independently — its own VM, its own branch, its | ||
| own PR — following the same conversion procedure. | ||
|
|
There was a problem hiding this comment.
🚩 Substantial preamble before first executable prompt
The demos/AGENTS.md rule says demo docs should "Lead straight into the guide with prompts and user instructions. Keep preamble minimal — no long orientation before the first step." In general.md, the first paste-into-Devin prompt doesn't appear until line 95, after two full conceptual sections ("The Pattern" with 5 subsections and "The Verification Loop"). Similarly, general.platform.md reaches its first prompt at line 94. However, since these are general pattern documents (not specific use-case walkthroughs), the conceptual framing may be justified — the reader needs to understand the universal pattern before seeing templated prompts with placeholders. The MuleSoft-specific use-case doc is the concrete walkthrough. This is a judgment call for the reviewer.
Was this helpful? React with 👍 or 👎 to provide feedback.
- Update broken links in catalog/repos.md (old path → use-cases/ path) - Remove 'open its own PR' from prompts (violates repo rule) - Replace 'guarantees' with 'approach' (overstatement language)
1 participant
Summary
Restructures
demos/migration/to separate the specific MuleSoft worked example from a new general-purpose migration talk track:use-cases/subdirectory — existingmulesoft-to-spring-boot-demo.mdmoved here viagit mvgeneral.md(Cloud variant) — coarse-grained framework/API migration demo covering the universal orient → convert → verify → fan-out pattern, contract verification loop, sample prompts, and scaling via playbooks + child sessionsgeneral.platform.md(Desktop + Cloud variant) — same content reframed for Desktop as orchestration layer: Cascade for local exploration, delegate to Cloud, Agent Command Center Kanban for parallel monitoring, one-click PR checkout for review, Spaces for workstream organizationBoth general docs reference the MuleSoft use-case as a worked example and cross-link to each other as variant alternates.
Link to Devin session: https://partner-workshops.devinenterprise.com/sessions/8f7ada01b7364c6092787929e328203a
Requested by: @bsmitches