Prepare the AGA application stack for migration from Azure to a single VM with PostgreSQL. Establish a complete source baseline in GitHub and a straightforward way to carry later Azure changes into the migrated stack. Complete this task end to end using your available Azure, GitHub and local source access. Handle repository setup, source recovery, commits, branches, merging, tagging and pushing yourself. Make routine decisions and continue working; ask only when missing access or an unresolved business-rule conflict prevents completion. Finish with links and a short status summary, not a list of Git commands for me to run. Use the tools, shell, paths and existing Azure/GitHub sign-ins available in this agent session. Adapt commands to the environment you actually have; do not require a change of operating system or assume Unix paths. Find an existing local checkout before cloning another copy, and preserve its uncommitted work before changing branches. If a required tool or sign-in is missing, explain the specific action needed once and continue independent work while waiting. This task captures and publishes source. Keep Azure production running as it is: do not change deployments, data, settings, credentials, schedules or routing, and do not start the migration yet. 1. Establish the repository and source map Start with https://github.com/gurujeetkhalsa/aga and fetch its current default branch. Prefer keeping the stack together in this repository, with clearly named folders for missing apps. Reuse another existing repository when it already owns an app. Create additional repositories only when needed; new repositories should be public and under gurujeetkhalsa. If you cannot write there, continue capturing source and request the missing access or intended owner. Preserve the visibility of existing repositories. More information about the app inventory and GitHub comparisons is available at https://azure-git-status.jonas.usgo.org. Use that page as background, then query Azure and GitHub to establish their current state. The October 9, 2026 source inventory found these matches: - aga-bayrate -> bayrate-app/ plus shared bayrate/ - aga-chapter-rewards-admin -> chapter-rewards-admin-app/ - aga-chapter-rewards-display -> chapter-rewards-display-app/ - aga-chapter-rewards-automation -> chapter-rewards-automation-app/ - aga-clubexpress-mail -> clubexpress-mail-app/ - aga-clubexpress-sso-probe -> clubexpress-sso-probe-app/ - aga-membership-functions -> membership-data-app/; aga-lookup-app/ and tdlists-app/ are reference folders for parts of this app - aga-ratings-explorer-display -> ratings-explorer-display-app/ - aga-ratings-explorer -> ratings-explorer-app/ (legacy mixed deployment) - aga-ratings-explorer-sgf-20260407t2105 -> a different, older staging variant of ratings-explorer-app/ These apps had no matching deployable GitHub folder: - aga-chapter-finder-update - aga-events - aga-news-archive-viewer - aga-ratings-sgf-upload - go-weiqi-baduk-news-index - aga-membership-functions3 (legacy rating-history chart and SVG) Query Azure now to list every Function App in the AGA subscription, including stopped apps, and record its name, resource group, hostname, Python version and deployment package location. Also list the SQL servers/databases and the storage accounts used by those apps. Compare that list with the app names above; include newly discovered apps and mark any listed app that is no longer present. Do not infer that a stopped or low-traffic app can be omitted. Create docs/azure-source-map.md with one row per Azure app. Each row must identify its Azure name and resource group, GitHub repository, exact folder containing its deployed source, normal development folder, imported shared modules, SQL tables/procedures/views/functions/triggers it uses, and the file describing its configuration and deployment commands. Use links to those folders and files. Where a dependency cannot be determined, label it unknown and explain what remains to be checked. Save a separate deployed-source copy under azure-baseline// for each app, including its own application modules and assets. For example, put the code from aga-ratings-explorer in azure-baseline/aga-ratings-explorer/ and the code from aga-ratings-explorer-sgf-20260407t2105 in azure-baseline/aga-ratings-explorer-sgf-20260407t2105/. These two deployments differ even though both resemble ratings-explorer-app/; retain both copies. Record which shared source modules each package contains and where their maintained copies live. Record database definitions under sql/azure-baseline//.sql and link each app to the definitions it calls. Do not replace one deployed app's files with another app's version just because their filenames match. 2. Recover deployed source and preserve current work Recover each app's actual active deployment, including Python, HTML/JS/CSS, necessary assets, dependencies, host configuration and deployment scripts. Identify the active release rather than simply choosing the newest ZIP. Investigate the classic aga-membership-functions3 app separately: its source retrieval previously returned HTTP 404. Recover its original source if the deployment interface is unavailable; do not invent a replacement and call it recovered. Compare deployed source, GitHub and any relevant local development source available to you. Preserve newer local or GitHub work in committed, clearly labeled paths or branches if it is not deployed. The baseline must distinguish code actually running in Azure from work in progress, rather than mixing them and claiming the result represents production. Preserve existing history, assets and behavior, including current workshop QR destinations. Avoid unrelated refactoring. 3. Capture the database and configuration contracts Export the complete live SQL schema through read-only queries: tables, columns, defaults, computed columns, keys, constraints, indexes, sequences, procedures, views, functions, triggers and application permission definitions. Organize definitions by schema and object so later changes produce useful diffs. Separate application definitions from SQL tooling and replication support. Include source-controlled SQL migrations where available; record any live objects absent from them. Export directly from live SQL metadata; do not assume a data mirror contains every table. The October 9 mirror omitted integration.news_archive_article_member_match. GitHub's procedure export also lacked these live procedures: - clubexpress.sp_approve_chapter_finder_update_request - clubexpress.sp_complete_chapter_finder_update_push_attempt - clubexpress.sp_reject_chapter_finder_update_request - clubexpress.sp_start_chapter_finder_update_push_attempt - dbrepl_meta.ensure_capture - rewards.sp_apply_bayrate_reward_reconciliation - rewards.sp_post_chapter_transfer Capture configuration variable names and nonsecret behavior settings, routes, auth requirements, schedules, enablement flags, queues, storage containers and external integration contracts. Document where required credentials are supplied using placeholders. Commit no secret values, signed URLs, private keys, database rows, mailbox content, receipts or other production user data. Exclude installed dependencies, environments, caches and generated runtime data. Inspect staged changes for credentials and user data before publishing to public repositories. 4. Publish the PREMIGRATION baseline Use a branch named migration for the recovered source and supporting documentation. Inspect any existing branch first and preserve its work. Create main from the current default branch if main does not exist; retain the old branch and its history. Commit the baseline and push migration. Merge into main when it can be done without unresolved conflicts, create an annotated PREMIGRATION tag on the resulting baseline commit, and push main and the tag. Once published successfully, make main the default branch so GitHub opens on the current source. For additional repositories, use the same branch/tag convention and record the exact baseline commit for each in the main repository's source map. If branch protection prevents merging, push migration and open the required pull request; report the baseline as pending rather than complete. If a merge has conflicts, preserve both versions, resolve straightforward source-layout conflicts yourself, and ask only about genuinely ambiguous behavior. Never force-push or discard work. Do not move or replace an existing PREMIGRATION tag; preserve its identity and record subsequent captures as follow-up commits. Do not label an incomplete recovery as a complete baseline. Source that cannot be recovered, required assets that are missing, and unresolved database definitions must be explicit in the source map and final status. 5. Make later changes easy to reconcile Commit docs/azure-source-map.md and a short AGENTS.md that let another agent immediately find the source, shared dependencies, database definitions and deployment instructions for each current service. Include package hashes, capture timestamps and per-repository baseline commits. Keep the copies under azure-baseline/ identifiable as captured Azure source; explain which folders are intended for subsequent development of the single-instance stack. Provide a repeatable read-only capture command, plus docs/reconcile-azure-changes.md explaining how to use it. Prefer a portable implementation, such as a Python helper that works on Windows and Linux; document its dependencies and use paths appropriate to the environment. The command should download current deployed app code and export current SQL definitions into a separate comparison directory, leaving the baseline and development files intact. In docs/reconcile-azure-changes.md, instruct the next agent to compare three versions: the Azure source and SQL definitions at PREMIGRATION, the new Azure capture, and the implementation changed for the VM migration. Identify what changed in Azure since PREMIGRATION and reapply those intended changes to the migrated implementation. Do not copy the whole Azure app over the migrated code. Translate database changes into explicit, ordered PostgreSQL migrations, including dependency order and any necessary data transformation, and retain the corresponding Azure definitions for comparison. Do not apply those migrations to production during this task. Keep authentication, scheduled-job ownership, queue processing and external side effects in that reconciliation procedure. Record interim work that is not yet deployed separately. Define how the final migration will reconcile production data after schema conversion; ordinary ongoing data changes are not captured by a source-code diff. Make the reconciliation procedure self-contained so an agent can perform it from the repository with the appropriate credentials. Leave no hidden dependence on your chat history or a temporary working directory. 6. Check completeness and finish Check that every captured app has its entry points, imports, dependencies and assets and can be packaged from the committed source. Use existing checks where useful in an isolated environment with production writes and outbound integrations disabled. Do not send mail, create Zoom meetings, consume production queues or run live mutation routes as checks. Finish with: - A link to the main repository's source map and reconciliation instructions. - A compact table of Azure app, source location and recovery status. - The PREMIGRATION tag and exact baseline commit for each repository, plus any pending pull requests. - Any remaining blocker, missing source or unresolved difference, stated plainly. The result should let the migration agent begin work directly from GitHub, and let the Azure development agent later bring interim code and database changes into the new stack with one request to follow the committed reconciliation instructions. 7. Submit the result When the operation is complete, POST a brief plain-text outcome to https://azure-git-status.jonas.usgo.org/result with Content-Type: text/plain; charset=utf-8. Include whether the baseline is complete, the main repository/source-map link, the PREMIGRATION revision and any remaining blockers. State partial completion honestly. Include no credentials or production user data. Submit the actual outcome once using an HTTP client available in your environment. For example, in PowerShell: $result = @" "@ Invoke-WebRequest -UseBasicParsing -Uri 'https://azure-git-status.jonas.usgo.org/result' -Method Post -ContentType 'text/plain; charset=utf-8' -Body ([System.Text.Encoding]::UTF8.GetBytes($result)) -TimeoutSec 60 Confirm that the endpoint returns HTTP 200. If submission fails or times out, state that in your final response and do not automatically repeat a request whose acceptance is uncertain.