AI-assisted development

From a task to a verifiable result

AI-assisted development combines human judgement with agents that can read project context, change code, use tools and check results. The popular term “vibecoding” describes only part of this spectrum. We explain a workflow in which you can understand the current step, the next decision and the missing evidence even without DevOps experience.

The course addresses developers, technical project leads and experienced newcomers. You can read the cases and use the simulated lab before touching a real system. Real changes require authorised project access. Work through the course in several stages; the two migration cases are independent.

Our continuous example is an internal application for tasks, progress and notifications. This is a synthetic learning project. The placeholders below are not credentials. Replace them with verified details before asking an agent to act.

• Context and tools
• GitLab, tasks and progress
• Local and cloud access
• Case A: existing Proxmox application
• Case B: GitHub to GitLab CE
• Start a new project
• CI, containers and deployment
• DNS, TLS and recovery
• Four handbooks
• Prompt workshop

1. Distinguish context, instructions and tools

A good task describes the goal, current state, allowed changes and observable acceptance criteria. “Create a login” leaves essential questions unanswered. “A verified member can sign in with a passkey; guests cannot retrieve member files directly” can be tested. Project documents and existing code help the agent relate these criteria to the actual application.

AGENTS.md: How do we work in this project?

Record the Git root, architecture entry point, checks, ownership and sensitive-data boundaries. Codex combines global and project instructions using its documented discovery order. Keep the file concise and link maintained handbooks. Instructions guide behaviour; the operating system, platform and tools still enforce actual permissions. OpenAI: AGENTS.md.

Skills: Which repeatable procedure fits the task?

A skill bundles a procedure in SKILL.md with optional templates, references or scripts. An appropriate skill can structure a UI check or the maintenance of architecture diagrams. Check its origin, scope and required tools before use. A skill does not grant additional permissions. OpenAI: skills.

In a suitable Codex environment, you can explicitly name an available skill in the task, for example with $skill-name. The name must match an installed skill. The agent reads its instructions and checks applicability; mentioning a missing skill does not make it available.

MCP, tools and integrations: What can the agent actually do?

A tool is a specific callable capability: reading a file, controlling a browser or querying a job. MCP is a protocol through which supported clients can connect such tools and data sources. An integration connects a service to a workflow, for example GitLab through a CLI or an agent environment. Not every integration uses MCP. A visible tool description proves neither authentication nor access to your project. OpenAI: MCP.

We first choose the procedure, then the tools and finally narrowly scoped access. Documentation research may need read access; creating a merge request requires different permissions from production deployment.

2. Self-hosted GitLab CE as our shared working state

Git stores versioned source code. Our self-hosted GitLab CE adds tasks, merge requests, CI/CD and a registry. git push does not transfer all project management data. The Git learning path explains repositories, platforms and verification; the Git scenario lab lets you explore related decisions.

glab gives agents structured command-line access to GitLab. First verify the selected instance, repository and permissions. A newer CLI can expose different subcommands from an older installation. Check glab --version and the relevant command help. glab api provides additional REST and GraphQL access; a mutation is still a real change. GitLab CLI and API requests with glab.

A work item is a small agreement

Record the problem, intended behaviour, acceptance criteria, responsible person or agent, dependencies and exclusions. Use an available work-item type or an issue according to the installed GitLab and CLI versions. Advanced planning features must not be assumed to exist in GitLab CE. GitLab: work items.

Evidence makes progress visible: “open”, “in progress”, “blocked”, “in review” and “accepted” have distinct meanings. The agent updates the task with the completed step, commit, check result and next dependency. A passing job does not mean “live”. A blocked task identifies the specific missing evidence. We close a task when its acceptance criteria have actually been met.

3. Local and cloud agents do not share the same environment

A local agent may use existing SSH configuration, local tools and permitted network paths, subject to its execution environment. A cloud task does not automatically inherit them. In particular, a remote URL does not transfer ~/.ssh/config, private keys, internal DNS or a local VPN connection into the cloud.

Check each execution location separately: name resolution, routing, TCP port, TLS trust chain or SSH host key, authentication and project permissions. Then test a harmless read operation. GitLab/API over HTTPS, Git over SSH and the registry HTTPS endpoint can have different hostnames, ports and credentials. A successful clone therefore does not prove registry pull access.

Depending on the product and infrastructure, cloud access may use an authorised private network path, a secured intermediary or an execution environment inside the private network. We do not expose GitLab or the application to the public internet merely to make an agent reach it. Disabling certificate or SSH host-key verification is not an access design either.

Current Codex Cloud documentation distinguishes direct environment values from HTTPS network secrets used through a proxy for allowed destinations. This does not imply general SSH access. Private networking must be configured for the actual environment and checked in a new task. OpenAI: cloud environments.

An access matrix records the FQDN, port, network path, identity and allowed actions for GitLab/API, Git SSH, registry, test UI and target host. Credentials stay in protected secret files or suitable secret management. The agent reports whether the check worked, rather than revealing credential contents.

Prove access during the active agent phase

A successful setup step is insufficient. During the subsequent agent phase, repeat an authenticated API read using glab api projects/<URL_ENCODED_PROJECT_PATH>, list Git references with git ls-remote <READ_REMOTE_URL> and perform an authenticated registry metadata read, where supported by the installed CLI, for example docker manifest inspect <IMAGE_AT_DIGEST>. Replace placeholders first. Report only necessary results; neither URLs nor output may contain credentials. Git: ls-remote and Docker: manifest inspect.

An API header supplied through an HTTPS network secret does not automatically configure a Git credential helper, Base64-encoded HTTP authentication, SSH or the registry token exchange. Use a supported managed GitLab connection where available, or an appropriate agent host with minimal protected credential injection. Never write real tokens into cached configuration.

Bearer authentication may point to a separate registry authentication endpoint, and blob downloads may need additional hosts. Network permissions must cover the actual registry, authentication realm and any blob destinations. An unauthenticated 401 response at the registry endpoint does not prove a successful pull. GitLab: registry authentication.

4. Case A: adopt an internal Proxmox application without Git or TLS

Starting point: A small application runs in a Proxmox VM or container over internal HTTP. Some source code is in a Codex working directory under ~/.codex. There is no reliable Git history. The goal is a private project on self-hosted GitLab CE, reproducible deployment and a documented operating procedure. “Without TLS” describes the old state, not the future recommendation.

Step 1: understand the running state

Inventory the start mechanism, process or container, source directory, dependencies, database, file attachments, users, network ports and current URL. Check whether the VM and application actually correspond to the identified source copy. The result is a baseline map with open questions. Nothing is moved or restarted yet.

Step 2: separate source from agent runtime

~/.codex is not a source archive that can be copied wholesale. It may also contain history, configuration, logs or credentials. Identify the exact application folder and inspect symlinks and embedded Git repositories. Only approved application files enter a dedicated project directory. Preserve originals as recovery evidence.

Step 3: protect data and establish a recovery path

A source copy is insufficient to restore the running application. Back up the database using an appropriate method and identify persistent files and required configuration. A Proxmox snapshot can supplement this, but it does not replace a verified application-consistent backup. Test restoration separately and agree a rollback trigger.

Step 4: create a clean project baseline

Record origin and current state in the new project folder. Create .gitignore, a secret-free example configuration and AGENTS.md. Only after file review, initialise Git and explicitly stage source, tests and documentation. Databases, real .env files, agent history and backups stay outside Git. The first commit records the baseline; it does not claim the legacy application already passes every check.

Step 5: configure access and the GitLab project

Verify access to self-hosted GitLab CE and create a private project in the agreed namespace. The agent uses only authorised permissions. Add the correct remote and push the reviewed baseline. Verify visibility, default branch and main-branch protection in GitLab. Private storage does not make committed secrets acceptable.

Step 6: test away from production first

Document a local start using fixed dependencies and synthetic sample data. A meaningful behaviour test checks the main function; another checks the most important access case. Track missing tests as tasks. Introduce the container definition and CI workflow after that. Production data must not enter the build context.

Step 7: connect tests, builds and artifacts

CI checks the specific commit and builds an image for the target host architecture. Push the image to the private registry. Record commit, pipeline, test evidence and image digest together. Fix a failed check or record an unmet criterion; disabling the check is not progress.

Step 8: prepare the new operating path

Plan the service account, deployment directory, database, persistent mounts, secrets, health check and reverse proxy on the target host. Keep the old application running while checking the new version separately. Establish DNS, certificates and any private access for the future FQDN. The image contains the application; it is not a backup of its mutable data.

Step 9: switch in a controlled change

Before switching, obtain a current backup, a change window and a suitable data-transfer procedure. Plan database migrations rather than guessing during startup. Check the application directly and through its FQDN, proxy and TLS, including login, its main function and persistence. If the agreed rollback trigger is reached, restore the known working state.

Step 10: clean up after operational evidence exists

Record the actual active version and update architecture, user, developer and operator handbooks. Retire the old service after agreed observation and a complete recovery basis. Clean specific working directories; do not delete agent runtime or Proxmox volumes indiscriminately.

5. Case B: move from GitHub to self-hosted GitLab CE

Starting point: The project has a GitHub origin and existing history. It will be maintained on self-hosted GitLab CE. We are moving a working environment, not merely a URL. The application can continue running in its current location during migration.

Step 1: inventory source and platform data

Inspect local changes, remotes, default branch, relevant branches, tags, submodules and LFS. Separately inventory issues, pull requests and reviews, wiki, releases and attachments, CI workflows, variables/secrets, packages and container registry, webhooks, deploy keys, integrations and branch rules. These are not all part of the Git repository.

Step 2: decide how each category moves

Git can transfer history. A GitHub importer may handle platform metadata, depending on the available GitLab version, enabled import method and permissions. Current documentation also describes partially completed imports. Plan sampling and completeness checks rather than trusting a success message alone. GitLab: GitHub import.

Reconfigure secrets through protected storage and rotate them where necessary. GitHub Actions does not automatically become an equivalent GitLab CI workflow. Registry images, release files and links each need an explicit migration step. Preserve a documented archive or reference path for history that is not transferred.

Step 3: prepare the destination and backup

Back up the known source state and list references to transfer. Check the private GitLab project, namespace, permissions and capacity. Preserve the existing origin initially. A clearly named additional GitLab remote permits comparison without hiding the former working path.

Step 4: verify the transfer separately

Use the reviewed import method and transfer only intended branches and tags. Check LFS objects and submodules independently. A blind push --mirror into an already used destination can modify or delete its references; it is not a safe default. Git: push and mirror semantics.

Step 5: reconcile metadata and permissions

Compare representative issues, discussions, open PRs/MRs, wiki pages, releases and links. Check authorship and permissions. Record an alternative path for unsupported or failed transfers. Only then decide whether the platform migration is complete enough to change the working location.

Step 6: reconnect CI/CD deliberately

Translate the verification goals into .gitlab-ci.yml, connect suitable runners and reconfigure required secrets securely. A first run builds without production access. Another checks registry access and the later deployment procedure. Switch triggers and webhooks so that both platforms cannot accidentally launch the same production change.

Step 7: accept from a fresh clone

Create a new working copy solely from GitLab. Dependencies, LFS, tests and build must work from it. Attribute results to the commit and eventual image digest. This checks more than an existing working copy in which untracked files may silently make things work.

Step 8: switch the working location after acceptance

After reconciliation, declare GitLab the authoritative working platform. Then update remote names, documentation, project links and integrations deliberately. Keep the former origin readable initially, or archive it after the agreed retention period. Document where future contributions belong and how to recover during the transition.

6. A short path for a new project

1. Clarify the problem and acceptance criteria; describe a small first feature and excluded changes.
2. Choose a dedicated folder and private GitLab CE project. Add AGENTS.md, README, example configuration and outlines of all four handbooks.
3. Establish reproducible startup and a meaningful behaviour test using synthetic data.
4. Implement a small task-branch change, inspect the diff and open an MR with evidence.
5. Connect CI and registry with separate permissions. Before deployment, prepare data, secrets, FQDN, proxy, TLS and recovery.
6. After live acceptance, close the work item and update handbooks to reflect the actual state.

7. CI and deployment have different trust boundaries

Tests may run on unreviewed contributions. A job holding production credentials or using a privileged image builder needs a different trust boundary. Separate verification, trusted build and deployment according to risk, and grant production permissions only through the intended protected workflow. A runner tag alone does not establish this boundary; branch rules, runner configuration and actual job eligibility must agree. GitLab: runner security.

A builder with access to a Docker socket can control that Docker host. This is a broad trust privilege, not a secure sandbox. A separate builder or ephemeral isolated runner can change this boundary; the actual configuration determines the result.

A cache speeds work and may be absent or stale. It is neither release evidence nor a backup. Preserve test reports and build metadata as attributable artifacts; images belong in the registry. A digest identifies the retrieved image, but does not prove its correctness, trusted origin or permanent registry availability. GitLab: caching and artifacts.

The target pulls the verified image as <REGISTRY>/<PROJECT>@sha256:<DIGEST>. A scoped deployment identity differs from a personal development identity. Persistent databases and attachments use named volumes or deliberate directory mounts; secrets are supplied separately in protected storage. Recreating a container must not accidentally replace these data. GitLab: deploy tokens and Docker: volumes.

The build daemon and target daemon have separate storage. With Docker-in-Docker or BuildKit, cache may be elsewhere again. Even an image present on the same host is not an availability guarantee. Serialize concurrent deployments through a shared lock, such as an appropriate GitLab resource group, and record the environment status. A manual job is an execution decision; additional deployment approval features are not universally available in GitLab CE. GitLab: resource groups.

Where does the runner run, and what does the CD job report?

A dedicated deployment runner can be installed on the target host. Alternatively, a trusted runner connects through a restricted remote access path. We recommend running verification and build code separately from the production service; deployment access is limited to the intended project and environment. A runner on the target must not accept arbitrary merge-request jobs with production privileges.

A concrete sequence is: tests → build and push the image → record its digest → pull it on the target → verify backup and migration compatibility → start Compose with that digest → check health and the user journey. The CD job waits for these results and provides useful status output and a sanitised evidence report. An environment associates the deployment in GitLab; a resource_group serialises competing jobs. On failure, execute the verified recovery path and record its outcome. The job still finishes as failed. GitLab: environments.

Named volumes, anonymous volumes and directory mounts

A named volume has a deliberate name and a documented lifecycle. An anonymous volume receives a random name; it can outlive a container, but a new container does not automatically reuse it. We therefore avoid unexplained anonymous volumes for databases. During adoption, identify the actual mounted volume ID and its data before changing the definition. Commands such as down -v or global pruning do not belong in a routine release.

A bind mount connects a specific host directory to the container. Record host path, container path, UID/GID, read/write permissions, capacity and backup. Mount configuration read-only where possible. An incorrect or empty mount can obscure existing data, making a running application appear newly installed. A recreated container must access the same verified data. Prove this with a test record and a separate restoration exercise.

8. FQDN, reverse proxy, TLS and recovery

Protected variables and masking reduce accidental disclosure but cannot stop deliberate exfiltration by an authorised job. File-based Compose secrets are not automatically encrypted. Repository permissions, runner trust and protected storage must work together. Docker: Compose secrets.

An FQDN is the application's complete DNS name, such as app.example.org. DNS must resolve it to the intended access point from each permitted network. A reverse proxy receives the request and forwards it to the internal service. The certificate must match the requested name, so a working internal IP address does not prove correct browser access.

Traefik Compose labels describe the host rule, entry point, TLS resolver, service port and required Docker network. Reuse names from the existing proxy after checking them; do not create a second central ingress as a side effect. Network restrictions and authorisation keep a private service private even if it holds a publicly trusted certificate. Traefik: Docker routing.

A wildcard such as *.example.org covers suitable names at one level, not automatically the base domain or deeper names. ACME uses DNS-01 validation for wildcard certificates: a controlled TXT record demonstrates control over the domain. The application need not be publicly reachable, but a publicly verifiable DNS challenge and suitable domain remain necessary. Keep scoped DNS API credentials protected at the certificate service. Let's Encrypt: challenge types and Traefik: ACME.

Successful recovery restores operation but does not retroactively make the failed new deployment successful. Report release outcome and current operational state separately.

A health check answers a limited readiness question. Also check the real user path through proxy and TLS, login and persistence. Recovery involves image, configuration and data separately: an old image cannot undo an incompatible database migration. Before changing anything, establish migration compatibility, backup, restoration, acceptable downtime and the rollback trigger.

Separate secrets by purpose and lifecycle

• Initial configuration: Create the initial administrator through a protected bootstrap path. Avoid shared default passwords or credentials inside images. Revoke or rotate one-time credentials afterwards; document first login and custody transfer in the operator handbook.
• Testing: Use disposable accounts and synthetic data. End-to-end tests receive a separate minimally privileged identity through protected secret injection. Check screenshots, recordings, traces and reports for credentials before retention.
• Deployment: Registry pull, target host and GitLab API need different permissions. Use short-lived job credentials where supported; otherwise use scoped identities with rotation and recorded expiry. Do not pass a personal full-access identity to every job.
• Application operation: Separate internal database/service passwords and external API keys by service and environment. Only the consuming container receives each value. Supply values at runtime through appropriately owned files or suitable secret management; .env is not a vault and does not belong in the repository.
• Encryption and recovery: Verify passwords through an appropriate password-hashing function rather than reversible storage. Data that must be decrypted needs separately held keys. Plan key versions, rotation, recovery and revocation; an encrypted backup without a recoverable key is unusable. Do not store keys and backups together without protection.

Record each secret's purpose, consumer, storage, owner, validity, rotation and recovery path, never its value in the handbook. After exposure, revoke or rotate the credential; deleting it from the latest commit does not remove copies already made. OWASP: secret lifecycle.

9. Four handbooks evolve with the project

Documentation begins as orientation and becomes a verified operating record. Update claims after actual checks; no handbook should claim a successful restore that never happened.

• Architecture handbook: purpose, system context, components and trust boundaries; sequence diagrams for key flows; data model with ERD. Explicitly explain when no persistent model exists.
• User handbook: roles, main tasks, expected results, understandable errors and limitations, using actual UI labels.
• Developer handbook: entry points, local setup, source layout, tests, AGENTS.md, skills, integration and extension procedures. New people and AI agents can find their first useful verification step.
• Operator handbook: installation, configuration, secrets, data, DNS/TLS/proxy, monitoring, maintenance, backup, restoration, updates, migration and recovery, with ownership and verified evidence.

A context diagram shows who talks to which system. A sequence diagram explains a particular flow over time. An ERD explains entities and relationships. They answer different questions and should reflect the actual project rather than decorate it.

A supported integrated browser can annotate specific elements or text. This provides a more precise reference than “this looks odd”: the element, visible state and requested change stay together. Add viewport, language and expected behaviour, then recheck the actual updated interface. Features and support depend on the development environment. OpenAI: browser annotations.

10. Prompt workshop: practical task starters

Replace the placeholders, check scope and send only the relevant task. These templates do not imply permission to change other systems. Resolve an unclear access path or missing evidence first.

Planning

Read <PROJECT_ROOT>/AGENTS.md, the architecture and existing tests first.
Goal: <OBSERVABLE_GOAL>. Affected users: <AUDIENCE>.
Identify current behaviour, assumptions, data and interfaces. Separate facts from open questions.
Create a small plan with dependencies, acceptance criteria and appropriate evidence.
Boundaries: <EXCLUDED_CHANGES>. Do not change files or deploy yet.
Ask only for information that materially changes the next step.

Implementation

Implement approved step <PLAN_STEP> for <WORK_ITEM>.
Baseline: <BASE_COMMIT>. Ownership: <FILES_OR_MODULES>.
Inspect the working tree and other people's changes first; do not revert them.
Use existing components and access rules. Add a meaningful behaviour test.
Check the diff and result, update affected handbooks and report the commit and actual evidence.
Outside scope: <EXCLUDED_CHANGES>. Do not merge or deploy without task authorisation.

Debugging with a browser annotation

Reproduce annotated issue <ANNOTATION_REFERENCE> at <TEST_URL>.
Expected: <EXPECTED_BEHAVIOUR>. Observed: <ACTUAL_BEHAVIOUR>.
Viewport and language: <VIEWPORT_AND_LANGUAGE>.
Use the integrated browser if available in this environment. Separate observations from hypotheses.
Add an appropriate regression check and fix the cause with a small change.
Verify the affected area, keyboard use and an adjacent case.
Use synthetic data; keep passwords and tokens out of output and screenshots.

Testing and acceptance

Verify <FEATURE> at commit <COMMIT> against <ACCEPTANCE_CRITERIA>.
Include guest, regular member and authorised member where these roles exist.
Check direct file/API paths and the relevant rendering in the integrated browser.
Use isolated test data. Distinguish syntax, behaviour, CI, image and live acceptance.
Report passed, failed and unperformed checks with limitations.
Explain missing evidence rather than treating its absence as success.

Bounded diagnostic loop

Investigate <DEFECT> using at most <MAX_ITERATIONS> diagnosis–change–test iterations.
Per iteration: one justified hypothesis, one targeted change and an appropriate check.
If the same cause remains unresolved twice, new risks emerge or <STOP_CONDITION> occurs:
preserve the state, stop the loop and identify specific missing evidence.
Do not disable tests or safeguards broadly. Deployment is outside this task.
Update <WORK_ITEM> with findings, progress and the next decision.

Verify cloud access

Read-only check whether this execution environment can reach private GitLab CE at <GITLAB_HTTPS_URL>.
Identify available network/VPN capabilities, DNS, routing, TLS trust, authentication and project access.
Check Git SSH at <GIT_SSH_HOST>:<SSH_PORT> and registry <REGISTRY_HTTPS_URL> separately.
Verify SSH host keys against <VERIFIED_FINGERPRINT_SOURCE>; keep StrictHostKeyChecking enabled.
HTTPS network secrets are not SSH keys. Do not reveal raw secrets or copy them into the repository.
Test a harmless read operation. If access is missing, identify the minimum required connection.
Do not expose services, change firewalls or bypass certificate checks without authorisation.
During the active agent phase, separately repeat glab api, git ls-remote and an authenticated registry metadata read.
Check network access to the registry host, Bearer authentication realm and any blob hosts.
A setup login or API header does not guarantee Git helper, SSH or registry authentication. Never write real tokens into cached configuration.

Case A: Proxmox and a Codex working folder

Adopt <APPLICATION> on Proxmox <PROXMOX_TARGET> into private GitLab CE project <DESTINATION_PROJECT>.
Source hint: <EXACT_APPLICATION_FOLDER_UNDER_CODEX>. Never copy ~/.codex wholesale.
Phase 1 is read-only: inventory runtime, source provenance, symlinks, database, persistent files, secrets and networking.
Establish backup, restoration evidence, destination Git root and a reviewed file selection.
Before changes, describe the sequence, rollback trigger <ROLLBACK_TRIGGER> and four handbook outlines.
After adoption approval: baseline, private remote, tests and CI, registry digest, test operation, proxy/TLS and controlled cutover.
Preserve originals until acceptance. Explicitly mark unverified steps.

Case B: GitHub to GitLab CE

Plan migration from <GITHUB_PROJECT> to self-hosted GitLab CE <DESTINATION_PROJECT>.
Inventory Git references, local changes, LFS, submodules, issues/PRs/reviews, wiki, releases/attachments,
CI, secrets/variables, packages/registry, webhooks, integrations, permissions and branch rules.
For each category, identify the import method, required permissions, reconciliation and fallback.
Preserve the existing origin initially; do not blindly mirror-push into an in-use destination.
Keep secrets out of Git. Plan CI translation and prevent duplicate deployment triggers.
Acceptance: fresh GitLab clone, reference/metadata reconciliation, tests, build and controlled working-location change.
Production changes require a separately authorised step.

Start a new project

Start <PROJECT_NAME> for <AUDIENCE> with goal <OBSERVABLE_GOAL>.
Work only inside <PROJECT_ROOT>; inspect existing files and Git state first.
Create AGENTS.md, README, secret-free example configuration and four handbook outlines.
Build a small vertical feature using synthetic data and meaningful acceptance checks.
Plan a private project on <GITLAB_HTTPS_URL> under <NAMESPACE>.
Before connecting CI/deployment, establish permissions, runner trust, registry, data, proxy/TLS and recovery.
Deliver small verifiable steps rather than an untested complete solution.

CI/CD, work items and progress

Link <WORK_ITEM> to <DESTINATION_PROJECT> on self-hosted GitLab CE.
Check CLI/server capabilities and existing CI before assuming commands or features exist.
Separate untrusted verification jobs, trusted build and deployment; document Docker socket/host trust.
Keep commit, pipeline, job, test reports and image digest attributable. Cache is not a release source.
Coordinate deployment through <ENVIRONMENT> and <DEPLOYMENT_LOCK>; do not assume premium approval features in CE.
Update task status from actual evidence. Keep failed, blocked and unverified distinct.

Deployment, proxy and TLS

Prepare authorised deployment of <IMAGE_AT_DIGEST> to <TARGET_HOST> under <DEPLOYMENT_DIRECTORY>.
Check registry pull access from the target, architecture, free space, service identity and protected secrets.
Inventory persistent database/file mounts. Back up data and verify recovery for <MIGRATION_PLAN>.
Use existing proxy <PROXY> and FQDN <APPLICATION_FQDN>; check DNS, networking, port and TLS.
Traefik labels must match the existing network, resolver and service port.
For wildcard <CERTIFICATE_NAMES>, protect DNS-01 permissions and check name coverage and renewal.
Coordinate <DEPLOYMENT_LOCK>. After switching, check health, proxy/TLS, login, main function, persistence and version.
At <ROLLBACK_TRIGGER>, restore a known working state with compatible data; do not perform global cleanup.

Four maintained handbooks

Update the four handbooks for <PROJECT_ROOT> from the actual code and evidence at <EVIDENCE_PATHS>.
Architecture: context, components, trust boundaries, key sequences and an ERD of the real data model.
User: roles, main workflows, errors and current UI terminology.
Developer: local setup, rules, modules, tests and extension paths for people and AI agents.
Operator: installation, configuration/secrets, proxy/TLS, data, maintenance, backup/restore, migration and recovery.
Version diagram sources and inspect their rendering.
Label assumptions and unperformed restore/live checks. Link tasks, versions and actual evidence.

Continue learning and apply the workflow

Explore decisions in the lab and compare them with the two case sequences. The simulation performs no real Git, network or deployment actions. Check the workflow before applying it to your own project. The Git presentation expands on branches, reviews and CI/CD.

Sources checked on 19 October 2026. Capabilities depend on product, version, licence and environment. The case sequences and prompt templates describe our ECDA workflow; they are not evidence that a real target system has already been migrated or accepted.