Move the application.
Preserve the business rules.

Twelve reviewed native views, paired by application. Select any image for its original-size crop. Quoted account references in the Teams policy and reservation images are visibly redacted. Screenshots illustrate interfaces; the recorded behaviour, state and audit checks establish outcomes. They do not prove a different generated revision is deployed.

Showing 6 examples.

01

LIVE DEMO / COMMAND + APPROVALS

Maintenance approvals

A request-to-decision workflow with role checks, repeated actions and conflicting-decision protection.

Slack

Request command and shared approval card.

Teams

Native command, Adaptive Cards and correctly targeted private responses.

Unchanged domain service. Matching recorded state and audit. Local replay: 8 scenarios / 42 steps.

Select to enlarge

Select to enlarge

What the migration taught us

Native Teams slash commands can carry targeted thread context. Private responses need the trusted channel-root reference. Those lessons became reusable checks instead of being rediscovered for every bot.

02

LIVE DEMO / PRIVATE LOOKUP

Policy lookup

Versioned, approved policy answers with explicit refusals for unknown or retired topics.

Slack

Private /policy responses.

Teams

Native command with the same private answer contract.

3 live operations per platform. Local replay: 6 scenarios / 18 transport-variant steps.

Select to enlarge

Select to enlarge

What was preserved

The original domain text, topic handling, access decisions and refusal messages. The bot does not call a language model to invent policy answers at runtime.

03

LIVE DEMO / CONTROLLED LIFECYCLE

Delivery exceptions

Inspect, escalate and resolve an exception without bypassing role permissions or transition order.

Slack

Private lookup and Escalate / Resolve actions.

Teams

Native command and private Adaptive Card actions.

5 main-flow live operations per platform plus an employee-role phase. Local replay: 7 scenarios / 39 steps.

Select to enlarge

Select to enlarge

A useful failed draft

The model initially reused a public-card pattern from another example. Exact visibility checks rejected it. The corrected target restored the source's private behaviour; visual similarity alone would not have caught the problem.

04

LIVE DEMO / INTENTIONAL UX REDESIGN

Manager approvals dashboard

The source was reviewed inside Slack before its interface was redesigned for a Teams personal tab.

Slack

A stacked App Home queue, status dropdown and separate rejection modal.

Teams

Counters, search, filters, request details, inline rejection reason and decision audit.

Matching live decisions and audit. Separate domain verifier: 12 scenarios / 14 steps, including spoofed client identity.

Select to enlarge

Select to enlarge

Redesign without rewriting policy

Self-approval and above-limit decisions remain refused. Rejections still require a reason. The UI changed; the original service remained responsible for every business decision. Historical access used explicitly demo-only short-lived links, not production SSO.

05

LIVE DEMO / API INTEGRATION

Stock reservations

An asynchronous HTTP-backed reservation workflow with actor-bound request keys, stock limits and safe retries.

Slack

Private /reserve responses using an authenticated synthetic HTTP backend.

Teams

Native /reserve command and private confirmations through the unchanged service.

Six live commands per platform. Three unique receipts; exact stock and audit parity. Local replay: 7 scenarios / 42 transport steps, plus real HTTP and concurrent-callback checks.

Select to enlarge

Select to enlarge

When confirmation is lost after commit

A real delayed HTTP response produced an unknown-outcome message, not a false rollback. Retrying the same key confirmed the original reservation without another stock deduction. A separate real 429 required an explicit same-key retry. Both platforms used independent fresh backend instances with identical seed data; this is not a production inventory integration.

06

LIVE DEMO / SHORTCUT + DIALOG

Service-desk intake

A global shortcut and two-step Slack modal became a private launcher and native Teams dialog.

Slack

Global shortcut, title/category form, review step and private ticket confirmation.

Teams

/intake launcher, editable validation errors, review and private SD-1 confirmation.

Cancellation creates no ticket. The completed ticket and audit match Slack exactly. Local replay: 6 scenarios / 32 transport steps, with additional native client review.

Select to enlarge

Select to enlarge

A deliberate platform difference

Explicit Cancel invokes the preserved service and bypasses required inputs. Teams X-close does not emit Slack's view_closed callback: no ticket is created, but the transient draft remains subject to its five-minute semantic expiry. This client shows the final result inside the dialog until Close is selected. Identical dialog cleanup is not claimed.

More patterns. Including an honest failed result.

This separate GPT-5.4 mini batch tested an API integration, a multi-step intake flow, and event-driven notifications with a digest. Reservations and intake reached reviewed local acceptance and separate live Slack/Teams proof. Notifications did not.

A local pass was not enough. The notification source worked in Slack. Additional review then found that the Teams adapter bypassed the source service for unknown identity and empty input, inventing different refusal text. Its final approved repair introduced an SDK return-type compilation error. The operator declined another attempt; no generated code was hand-fixed, no Teams notification success is claimed, and all 86.27 credits remain in the ledger.

The two accepted apps total 166.236315 managed credits. This batch is separate from the earlier 198.358950-credit portfolio run. Coordinating conversation, kit/fixture/harness engineering, live testing and documentation are excluded and not assigned a zero cost. A vendor-without-source test also remained blocked without invoking a model.

Publication boundary: this public site and repository contain documentation and reviewed screenshots only. The two-recipe v0.2 toolkit, experimental extension code, source fixtures, generated apps and ZIP remain private.

A developer toolkit, not a hosted migration service.

The privately prepared toolkit contains a controller, source examples, recipes, checks and documentation for running a supported-pattern portfolio locally. The table documents that architecture; it is not a download offering. Reproducing the approach requires authorised source, an approved Copilot account and application-owner decisions.

No toolkit source, ZIP or ready-to-install Teams app is published here. This repository contains only the website and case-study documentation, including reviewed cropped screenshots. Original private captures, browser recordings, credentials, tenant registrations and the live demo host are excluded.

What can it migrate today?

Support is based on the application's source and behaviour, not just its name in Slack. The privately packaged v0.2 release has two recipe families: command/action bots and one approvals-dashboard contract. Both expect trusted JavaScript/Node source, a separable business service and reviewed acceptance cases.

Demonstrated does not mean bundled. The six live examples are historical evidence, not six ready-to-install templates. The stable ZIP contains five synthetic source fixtures and two recipes. The later reservations/intake work and unsuccessful notification extension are separate experiments; their extension code and fixtures are not in that ZIP.

“Supported” means the pattern has a defined generation and verification path. It does not guarantee first-pass model success, complete business equivalence or production readiness. Unsupported entries are reported as blocked/manual-review/vendor-alternative work, not silently marked migrated.

Installable tooling. Not an automatic migration.

An engineer receiving the private kit can set up its supported local workflow. Installing it does not discover Slack apps, make arbitrary source compatible, or deploy a working Teams application. The public documentation repository cannot run the kit: it contains no toolkit source or ZIP.

Clean-folder testing is not a new-customer guarantee. The exact private release is tested separately from the development workspace, on the existing Windows workstation and approved Copilot account. A different user, clean machine, operating system and customer tenant still require their own pilot. See what was actually exercised.

A Slack workspace export is not application source. The kit does not connect to Slack and automatically discover, download and migrate every installed app. Inventory import and source preparation are operator-led. Source replay executes code, so never treat the local runner as a sandbox for unreviewed customer repositories or production credentials.

Test the package. State the limits.

The readiness exercise starts from a fresh extraction of the actual private v0.2 ZIP, not the development workspace or an old generated app. All 65 manifest-listed files are checked against their original hashes. The archive and generated targets are not hand-patched to make the exercise pass.

Installation passed; fresh generation is not guaranteed. The new policy-bot target failed compilation after its initial implementation and three allowed repairs. The controller rejected it and did not mark it migrated. This is direct evidence against describing the current package as “install it and everything works”, even though earlier policy demonstrations succeeded.

The dashboard's first domain-level pass missed lost decision messages, incomplete clearing of private data, malformed records and a late-response expiry race. A model repair fixed those; a second fixed the remaining stuck busy state. The external browser harness used synthetic Teams context and intercepted HTTP, not a real tenant or production SSO. All failed and successful attempts are included in the cost ledger.

Cost per asset. Cost of operating the kit.

The new 200-credit allowance covered two synthetic assets and bounded repairs. Native usage was reconciled across nine runner invocations and two resumed worker sessions. Failed attempts are included; cumulative session totals are not counted again on every resume.

113.942810 credits remained from the unchanged 200-credit allowance. No paid clarify or discuss invocation occurred in this particular run; recording the scope answer was deterministic. Investigation through the two model assessments is included above. The outside conversation and review are a different, unallocated scope.

86.057190 is the managed migration-run cost, not the total cost of this exercise. For repeatable budgeting, use the runner's discuss command for metered app or shared investigation, track external work separately, and estimate from a representative pilot including failures and repairs. Do not multiply only the successful dashboard price by the number of Slack apps.

These generation costs are not per end-user Teams request; the sample business services are deterministic. Earlier evidence remains separate: the 24 September three-app local batch (198.358950 credits), the coverage batch including its stopped notification failure (252.508065), and the historical worker-only measurements use different scopes. None is silently added to this test.

A controller around the agent.

The portfolio preview replaces manual coordination with durable app jobs and explicit gates. It does not remove business ownership or pretend every installed Slack app is convertible.

The preview is sequential and resumable. App workspaces and file-only tools provide scoped work, not a hostile-code sandbox. Only reviewed, trusted source should be replayed.

Who does what at each gate?

What comes out of a migration?

.portfolio-runs\<portfolio>\
  state.json
  report.json
  report.md
  apps\<app>\kit\
    sources\<app>\
    runs\<app>\<revision>\
      assessment.json
      teams\
      implementation.md
      verification.json
  invocations\<invocation>\
    invocation.json
    events.jsonl
    usage.json

Move reviewed generated code into its destination repository through normal change control. Supplying hosting, production identity/authorisation, durable storage, registrations, consent, secrets, client acceptance and rollout/rollback remains separate engineering work.

Three new targets. A complete managed ledger.

The controller generated fresh versions from separate source workspaces, recorded clarification and investigation, and brought all three through independent local verification and operator acceptance. Resuming the accepted batch made no further model calls.

Stage columns are rounded. The approved allowance was 1,000 credits. Kit development, outside coordination/review, the browser harness, public documentation, staff time and hosting are separate, excluded scopes. These are not full project prices.

The gates mattered. Delivery exhausted its default attempt limit and required explicit user-approved extensions; it passed on attempt seven. Browser review rejected a dashboard that had already passed domain checks. Its malformed-response handling and retry path were corrected before acceptance. No generated target was manually repaired by the coordinator.

New bot outputs passed source/target transport replay. The new dashboard passed domain checks plus a five-scenario local browser harness with synthetic Teams context and intercepted HTTP. Earlier real-client evidence does not imply these new revisions were deployed.

Nine accepted GPT-5.6 migrations, including the operating cost.

Three fresh samples each of Equipment Loans, Store Operations and Manager Approvals were generated from unchanged synthetic Slack sources. Every final sample passed its independent browser suite and native Teams parity review. Failed attempts, repairs, coordinator usage and the supervising conversation are included through the frozen accounting cutoff.

*The all-in mean is a transparent planning allocation, not a native per-app coordinator meter. Coordinator cost is divided only within the batch it coordinated; shared parent setup, supervision, testing and reporting is divided equally across all nine accepted migrations.

No reset hid the expensive setup. The supervising conversation had already consumed 1,370.881050 GPT-6 Astra credits before it was switched to GPT-5.6 Sol. Those credits remain in the all-in total. The 50,000-credit ceiling was not approached.

Acceptance scope: every Equipment Loans and Store Operations sample passed 14 browser scenarios and a real Teams personal-tab lifecycle with exact Slack business-state/audit parity. Every Manager Approvals sample passed nine browser scenarios and native approve/reject/refusal/audit parity, including one-use ticket rejection. Failed and superseded attempts remain charged. Human time, licences, subscriptions and infrastructure are not AI-credit units. Static publication after the frozen cutoff launches no migration workers and is outside this fixed benchmark record.

Six additional patterns: 18 GPT-5.6 samples

Three fresh samples were run for every remaining documented pattern. Maintenance Approvals, Policy Lookup, Delivery Exceptions, API Reservations and Service-desk Intake passed local and native Teams acceptance. Operations Notifications passed local acceptance only; it was never hosted and is not claimed as a completed migration.

*Coordinator and parent usage was measured for the batch rather than per migration. The allocated all-in means add an equal 97.868941-credit share of that overhead to each direct worker mean. Failed startup and rejected attempts remain in the ledgers. See the detailed accounting and acceptance boundary.

Non-UI event-driven extension: six fresh migrations

Two additional non-dashboard archetypes test more demanding integration behaviour. Procurement Status Assistant combines private commands, synthetic upstream purchase-order webhooks and Adaptive Card actions. On-call Incident Router ingests monitoring events, deduplicates and routes incidents, then supports acknowledgement, escalation and resolution actions. Each archetype was built once as a synthetic Slack source and migrated independently three times.

*Each archetype's source/maintenance cost is divided across its three migrations. Shared kit, coordinator and parent usage totals 1,084.122720 credits and is divided equally across all six migrations: 180.687120 each. Procurement: `353.653060 migration + 44.374453 source + 180.687120 shared = 578.714633`. On-call: `271.343553 + 55.753607 + 180.687120 = 507.784280`. A timed-out Procurement implementation remains charged at 146.504260 credits. See the detailed evidence.

Complexity changes the average. The five earlier command/workflow patterns had direct means of roughly 87–150 credits. The two new event-driven patterns averaged 271–354 because they add webhook validation, event deduplication, protected HTTP transport, card-action authorization and deeper recovery tests. The 179.354282-credit broader average is a mixed planning figure, not a promise that every non-UI migration costs the same.

Two new full applications: accepted code, blocked installation

Store Opening Readiness and Product Recall Coordination were designed as new substantial Slack applications, source-built, analysed for maintenance, migrated through the kit and independently tested. Both final Teams targets passed 15 browser scenarios and protected-host lifecycle parity, including one-use-ticket rejection. Migration Examples Lab 1.4.0 was built, but actual tenant installation could not be completed: the approved Teams renderer was unresponsive and the approved CLI identity lacked Microsoft Graph AppCatalog scope.

Not counted as completed migrations. The code-generation and protected-host gates passed, but the package was not installed into the tenant and the apps were not exercised as actual installed Teams personal tabs. The Store live Slack capture also did not complete create and sign-off. These gaps are shown rather than converted into success.

*For planning only, reusable kit, coordinator and parent costs are split equally between the two applications; direct app worker costs remain app-specific. Every failed and superseded attempt is charged. Human engineering, tenant administration, licences, hosting, durable storage, security, monitoring and support remain separate non-AI categories. See the full result and production boundary.

Two more full-application archetypes: source recreation and migration separated

Supplier Onboarding Hub and Major Incident Command were added to test substantially different data, roles and lifecycle complexity. Both passed deterministic source and Slack-handler integration tests, exact source/target integrity, real Chromium acceptance and protected-host lifecycle parity. Supplier passed 18 browser scenarios; Major Incident passed 17. Packages were prepared but not tenant-installed, and live Slack client operation was unavailable, so these remain controlled engineering benchmarks rather than completed tenant migrations.

*Source recreation is analysis plus source implementation and repairs. It is a one-time cost only when the Slack application must first be reconstructed or built for the benchmark; it should not be added to a source-available migration estimate. The direct-worker subtotal is source recreation + maintenance analysis + repeatable migration. Shared AI overhead is each app's equal share of 75.032320 kit + 500.632620 coordinator + 157.402280 parent credits. Failed and superseded attempts remain charged. Tenant upload/install, installed personal-tab execution and live Slack-client operation were not performed. See the detailed result.

Consistency pair: quality CAPA and workforce certification

The same benchmark was repeated with Quality Nonconformance & CAPA and Workforce Certification Tracker. Both passed 19 real Chromium scenarios, strict authentication and Origin checks, complete protected-host lifecycles, exact state/audit parity and one-use-ticket rejection. Packages remain prepared-not-installed and live Slack-client operation was not available.

The four-app planning allocation is reasonably consistent. All four landed within about ±10% of the 1,144-credit mean despite materially different workflows. This is evidence for a controlled synthetic scope, not a universal fixed price. No GBP value is published because AI credits do not define a universal pound conversion; apply the actual billing-plan rate separately.

The second pair's shared overhead is `(68.699320 kit + 217.682580 coordinator + 193.590260 parent) / 2 = 239.986080` per app. Quality arithmetic: `229.232760 + 39.293680 + 648.411320 = 916.937760`, then `+ 239.986080 = 1,156.923840`. Workforce arithmetic: `188.429020 + 39.856560 + 559.210480 = 787.496060`, then `+ 239.986080 = 1,027.482140`. See the detailed consistency result.

Earlier worker-only evidence

The figures below are retained as historical worker-session evidence. Their narrower scopes exclude coordination and should not be compared directly with the all-in benchmark above.

*Assessment includes assessment corrections. Stage values are rounded. The earlier corrected maintenance run used GPT-5.6 Sol and consumed 327.52824 credits, excluding earlier separate prototype attempts. Different workloads and scopes make this unsuitable as a controlled model comparison.

Start small. Review. Then repeat.

These commands require the private kit root; they are not runnable from this documentation-only repository. Read the prerequisites and stage dependencies, check that the source fits a shipped recipe, and review the exact-release evidence first.

1. Install and check before allowing model work

npm ci --ignore-scripts
npm test
npm --prefix .\portfolio test
npm --prefix .\portfolio run migrate -- doctor

These checks make no migration-model calls. doctor returning ready: true is a CLI compatibility result, not proof of sign-in, model entitlement or production readiness.

2. Review the inventory, then start a paid run

Do not run the bundled example unchanged without reviewing its allowance. Its budgetCredits: 1000, invocationCredits: 75 and four default attempts per stage permit new paid work. Choose an approved budget, app list, source root and scope first. The release-test allowance is a separate record, not a default for another user.

npm --prefix .\portfolio run migrate -- init examples\pilot.json
npm --prefix .\portfolio run migrate -- run ..\.portfolio-runs\three-app-pilot
npm --prefix .\portfolio run migrate -- status ..\.portfolio-runs\three-app-pilot

Answer the reported questions, inspect each source-backed assessment, and approve its exact hash before implementation. The kit's operator guide explains approval, metered discussion, retry, recovery and acceptance.

The example launches fresh model work, not a free playback of historical evidence. Native credit caps are soft; in-flight work can overshoot. No automatic tenant deployment or GitHub publication occurs.

npm --prefix .\portfolio run migrate -- discuss STATE_DIR APP QUESTION_FILE
npm --prefix .\portfolio run migrate -- answer STATE_DIR APP QUESTION_ID "Decision" "Reviewer"
npm --prefix .\portfolio run migrate -- approve STATE_DIR APP PLAN_SHA256 "Reviewer"
npm --prefix .\portfolio run migrate -- run STATE_DIR
npm --prefix .\portfolio run migrate -- request-repair STATE_DIR APP "Review finding" "Reviewer"
npm --prefix .\portfolio run migrate -- accept STATE_DIR APP "Reviewer"
npm --prefix .\portfolio run migrate -- check STATE_DIR
npm --prefix .\portfolio run migrate -- report STATE_DIR

Before you point it at a real portfolio.