First Change

For a project hosted in Devbox, start at Devbox Access. The portal gives you the connection details and application URLs for your assigned development environment. Your code change happens in that workspace; the npm commands in Local Development build only this documentation site.

Before opening the editor

1. Choose the project and the behavior to change. Use the project directory to identify the owning repository. For a change that crosses applications, open the relevant business flow so you know which handoff you will verify.

2. Open Devbox Access and select your assigned environment. Check its name and owner, runtime status, SSH command, and project URLs. The portal is team-visible: a listed environment is not automatically yours to use. If you do not have an assigned environment or your SSH public key has not been registered, ask the platform team to provision access. See Devbox Access and Workspace.

3. Connect using the SSH command shown for that environment. Use the host and port from the portal, rather than a teammate's command or an example port. You arrive in the development shell. Run devbox-help for its available commands. If your assigned environment's services are sleeping, follow the wake instructions; if the environment is down, ask the platform team.

4. Open the owning repository under /workspace. For example, Magento lives at /workspace/menzzo and Logidav at /workspace/logidav in the documented layout. Connect your editor to the same SSH endpoint; JetBrains Gateway setup describes the supported PhpStorm workflow. Inspect the checkout before editing:

   # Example: Magento in your assigned development workspace
   cd /workspace/menzzo
   pwd
   git status --short --branch
   php -v

   Confirm the repository and intended branch with the owning team's instructions. Preserve existing changes; a workspace may already contain another task. The PHP wrapper selects the project's runtime from .php-version, so check it from inside the project directory instead of assuming a fixed version.

Make the change reviewable

5. Open the matching application URL from the portal. Reproduce the behavior in the same environment as your editor and SSH session. For example, use that environment's Magento URL for a change in /workspace/menzzo. Establish what happens before the change.
6. Create the change using the repository's branch and setup workflow. Read its README and contribution instructions. Use its documented checks and the project-specific setup links; do not run migrations, imports, queue replays, or a blanket reinstall merely to start working.
7. Verify the result in that environment. Run the checks appropriate to the changed code, then repeat the browser or API scenario using the same project URL. For cross-system work, verify the next relevant handoff in the linked flow as well. Record anything you could not verify.
8. Prepare the review. Check the diff for unrelated files and secrets, then describe the behavior changed, the environment used, the tests and browser checks, and remaining gaps. Verify your Git author and the account that will push before publishing the branch and opening the repository's normal pull request. A passing development check does not authorize a production change.

If the project instructions are incomplete

• Portal access, missing environment, SSH key, or an environment marked down: ask the platform team; do not substitute another developer's environment.
• Missing repository setup or test instructions: use the coverage matrix to find the gap and ask the owning project team for the supported workflow.
• A project not hosted in Devbox: follow its documented development environment instead; the Devbox project list is not a complete inventory of every Menzzo system.

The access and workspace sequence above is checked against the pinned Devbox source linked in the access guide. Live portal authentication, your assignment, current workspace state, and project-specific tests were not checked by this documentation update.