NWP SHOPIFY ENGINEERING — MASTER INVOCATION CHANGE REQUEST [Describe the functionality, theme, layout, integration, or engineering change.] SUCCESS CRITERIA [Describe the expected behavior and appearance. Attach references if applicable.] MISSION Implement this change in the canonical New Wave Print Shopify codebase using the established GitLab workflow. Work at maximum safe velocity: use fast focused tests during development, reserve full certification for the completed candidate, and do not expand CI/CD work unless it directly blocks engineering. AUTHORITATIVE CONTEXT - GitLab: https://gitlab.com/persianflux-group/nwp - Local repository: /Users/kshams/Documents/ChatGPT/NWP - Canonical first-party Shopify source: shopify/theme/ - Shopify store: e422c0-6f.myshopify.com - Theme foundation: Prestige 11.4.0 - Protected live theme: 162192752881 - Protected durable draft: 162192883953 - Last-known engineering-readiness SHA: 75d5dd4e90c6e72ede030afaf79c55531d85c298 - Last-known GitLab main SHA: 1f3c94468e1136dca8c1f2b70fecdaaa223a7b9c - GitLab main becomes canonical only after reviewed changes are merged. - Shopify editor state, store resources, and app-managed code are separate from first-party Git source and must not be silently mixed together. STARTUP VERIFICATION 1. Read AGENTS.md and the following files before editing: - README.md - shopify/DELIVERY-WORKFLOW.md - shopify/SHOPIFY-STANDARDS.md - shopify/QA-CHECKLIST.md - shopify/RELEASE-LOCK.json - shopify/package.json 2. Inspect the current local worktrees, branch, working-tree status, remotes, GitLab main, open MRs, and latest CI state. Fetch remote refs read-only. 3. Never overwrite, reset, discard, or absorb unrelated user changes. 4. Verify whether the readiness SHA is contained in GitLab main or an approved remote MR branch. If it remains local-only: - Do not silently fall back to stale main. - Preserve and revalidate the readiness commit. - Push only its codex/* branch and create or update a Draft MR. - Do not merge it without explicit authorization. - Base feature engineering on the verified readiness SHA while clearly reporting the baseline relationship. 5. Create an isolated branch/worktree named codex/nwp-<short-change-name>. One writer owns implementation and commits. Parallelize independent audits, tests, and reviews when supported. AUTHORITY GRANTED BY THIS INVOCATION You may: - Inspect the repository, GitLab, and read-only Shopify state. - Create an isolated local branch/worktree. - Edit version-controlled source and tests. - Install locked dependencies. - Run local development servers and verified unpublished development previews. - Run tests, audits, packaging, and static analysis. - Create local commits. - Push only the new codex/* feature branch. - Create or update a Draft GitLab MR. You may not: - Push directly to main. - Merge an MR. - Upload a theme to Shopify. - Modify the live theme or durable draft. - Publish, delete, rename, or retarget a Shopify theme. - Modify Locksmith, apps, tokens, permissions, products, orders, navigation, store settings, or GitLab project settings. - Copy/paste code into Shopify’s web editor. - Store or expose secrets, passcodes, or raw credentials. Those actions each require separate explicit authorization. IMPLEMENTATION RULES - Treat Git as the source of truth for first-party theme code. - Make the smallest complete root-cause change; no patches, hacks, or duplicated ownership. - Preserve the approved dark NWP visual system unless the change request explicitly replaces it. - Preserve the menu order unless explicitly changed: Home → Explore → Private Collections → Contact Us - Respect Prestige architecture, Shopify Liquid conventions, accessibility, responsive behavior, RTL, reduced motion, and existing design tokens. - Do not import app-generated or Locksmith-managed bytes into first-party source. - Do not rebuild the workflow while feature engineering remains unblocked. - If Shopify Admin state is required, model and report it separately instead of pretending it is committed code. FAST DEVELOPMENT LOOP Install: npm --prefix shopify ci Run the verified development environment only after confirming it cannot target either protected theme: npm run dev During implementation: npm run shopify:test:header npm run shopify:test:fast Use the narrowest relevant test first. Add regression coverage for every root-cause behavior changed. CANDIDATE GATES Before declaring the change ready for review: npm --prefix shopify run check:source npm --prefix shopify run policy npm run check npm --prefix shopify run audit git diff --check Commit the complete candidate, confirm the worktree is clean, then run: npm --prefix shopify run package:verify The full suite must cover Chromium, WebKit, and Firefox. Failures must be diagnosed and corrected rather than bypassed. SAFARI REQUIREMENT Actual Safari is mandatory; Playwright WebKit is supporting coverage, not a substitute. For local Safari certification: npm run shopify:test:safari:certify If blocked, report the exact prerequisite. Safari → Settings → Developer → Allow remote automation may need to be enabled. A release candidate must later be tested in actual desktop Safari and mobile Safari against the exact frozen Shopify preview. GITLAB DELIVERY 1. Keep commits focused and reviewable. 2. Push only the codex/* branch. 3. Create or update a Draft MR. 4. Include: - Objective and root cause - Exact candidate SHA - Files changed - Test and audit evidence - Visual evidence when applicable - Known limitations - Confirmation that no Shopify production state changed 5. Do not mark the MR ready, merge it, or deploy it without explicit authorization. RELEASE PATH — SEPARATELY AUTHORIZED Draft MR → CI green → independent review → merge authorization → protected-main SHA → temporary-preview authorization → one new unpublished theme → identity verification and freeze → pullback equivalence → actual Safari and full QA → durable-draft authorization → final publication authorization Never skip or combine these gates. WORKING STYLE - Begin with a concise verified-state summary and implementation plan, then act. - Do not ask questions that repository inspection can answer. - Ask only when a missing decision would materially change the implementation. - Keep progress updates concise and evidence-based. - Prefer maximum parallelism for independent read-only work, but prevent conflicting edits. - Continue until the requested engineering change is complete or a genuine authorization boundary is reached. FINAL REPORT Return: - Outcome - Exact branch and commit SHA - Root cause addressed - Files changed - Tests and results - Safari status - Package digest when produced - Draft MR link, if created - Git/worktree state - Any deferred release gates - Explicit confirmation of every external system that was or was not changed > The patient was reevaluated at bedside prior to discharge and remained clinically appropriate for outpatient management, with no indication for inpatient hospitalization at this time. All ED evaluations, diagnostic results, clinical impressions, and treatment recommendations were reviewed and explained, and the patient verbalized understanding. The discharge plan, medication management, and appropriate follow-up arrangements were discussed and established to support a safe transition of care. Strict return precautions were provided for any new, worsening, or concerning symptoms; all questions were answered and concerns addressed.