Add 3s API POST delay and standardize status messages

[Copilot]

Implements a hidden 3-second delay before API calls and normalizes status message formatting across the application.

Changes

Hidden API delay

• Added 3s await before postToMeshMapperAPI() in postApiAndRefreshMap()
• User sees "Posting to API" status for ~4s total (3s delay + API call time)
• No visible countdown or UI changes

setStatus("Posting to API", STATUS_COLORS.info);

// Hidden 3-second delay before API POST
await new Promise(resolve => setTimeout(resolve, 3000));

try {
  await postToMeshMapperAPI(lat, lon, heardRepeats);

Status message standardization

Standardized all 25 status messages to follow consistent conventions:

Removed trailing ellipsis from 8 messages:

• "Connecting…" → "Connecting"
• "Disconnecting..." → "Disconnecting"
• "Sending manual ping..." → "Sending manual ping"
• "Sending auto ping..." → "Sending auto ping" (both instances)
• "Waiting for GPS fix..." → "Waiting for GPS fix"
• "Finalizing heard repeats..." → "Finalizing heard repeats"

Consolidated duplicate messages:

• "GPS data old, trying to refresh position" → "GPS data too old, requesting fresh position" (both auto and manual modes)
• "Auto ping sent" → "Ping sent" (consolidated with manual ping message)
• "Failed to connect" / "Connection error" → "Connection failed" (unified error format)

Fixed capitalization:

• "geo fenced region" → "geofenced region" (proper compound word)

Standardized tone:

• "Please wait" → "Wait" (consistent direct, technical tone)

Fixed typo:

• "Ping skipping" → "Ping skipped"

Standardization rules applied:

• No trailing punctuation (ellipsis removed)
• Sentence case capitalization
• Present progressive tense (-ing) for ongoing actions
• Past tense for completed actions
• Consistent "X failed" format for all error messages
• Consistent direct tone (technical, no polite language)
• Proper compound words

Documentation update

Rewrote STATUS_MESSAGES.md:

• Replaced Location: with Used in: (function names) and Source: (file paths)
• Added standardization rules section
• Documented all 25 status messages with consistent formatting (reduced from 28 by consolidating duplicates)
• Noted 3s delay in "Posting to API" entry

Original prompt

You are working in the GitHub repo: MrAlders0n/MeshCore-GOME-WarDriver.

Goal: implement two changes (one behavior change, one “status messaging” consistency pass) while preserving existing functionality except where specified.

========================
TASK 1 — Add hidden 3s delay before API post

Find the async function named postApiAndRefreshMap.

In this function, there is a point where we update a UI/status value/message to “Posting to API” (or equivalent). Immediately after that status update occurs, add a 3-second delay BEFORE the code that actually performs the API POST request.

Requirements:

• The user must NOT see a countdown/timer.
• The user should simply see the existing “Posting to API” status during the full 3 seconds.
• After the 3-second delay completes, proceed with the normal API POST and the rest of the existing workflow.
• Implement delay in a clean async/await way (e.g., await new Promise(r => setTimeout(r, 3000))).
• Ensure error handling and existing control flow remains intact.

Acceptance criteria:

• When postApiAndRefreshMap runs, “Posting to API” appears, then ~3 seconds later the API call occurs.
• No visible timer or additional UI elements are added.
• All existing behavior after the API call remains the same.

========================
TASK 2 — Standardize status messages in CODE, then update docs

There is a markdown documentation file:
files/STATUS_MESSAGES.md

I want you to standardize status messages used throughout the CODEBASE (not just the docs), and then update files/STATUS_MESSAGES.md so it accurately reflects the new standardized messages.

Steps:

1. Inventory current status messages in the codebase

   • Search the repository for all user-facing status strings/messages (anything shown in UI/status banners/toasts/loading states, etc.).
   • Focus especially on anything that looks like status updates (e.g., “Posting to API”, “Refreshing map…”, “Scanning…”, etc.).
   • Build a list of the distinct messages and where/how they are set (function name and file path).

2. Define a single consistent style and apply it everywhere
   Standardization rules to apply (unless there’s a strong reason not to):

   • Use consistent capitalization (pick one: Title Case OR Sentence case; apply consistently).
   • Use consistent punctuation (either no trailing periods for short statuses OR always use periods—choose one and apply consistently).
   • Use consistent tense/voice (prefer short, action-oriented present-progressive like “Posting to API”, “Refreshing map”, “Loading data”).
   • Remove unnecessary variability (e.g., “Posting to the API” vs “Posting to API” → pick one).
   • Keep messages short and readable.
   • Do NOT remove dynamic values if they are meaningful to the user (e.g., counts), but format them consistently.
   • If there are multiple messages that mean the same thing, consolidate them to a single canonical phrase.

3. Refactor code safely

   • Update the actual string literals in code to the new standardized phrases.
   • If the project has a central place for status messages/constants, consider introducing or using it to avoid future drift (only if it’s low-risk and clearly improves consistency).
   • Ensure the app still functions the same and statuses still appear at the correct times.

4. Update documentation AFTER code changes

   • Update files/STATUS_MESSAGES.md to reflect the final set of standardized messages actually used in code.
   • Remove any messages that no longer exist and add any new/renamed ones.
   • Remove “Location:” because code is dynamic.
   • Instead, for each status message include:
     • “Used in:” the function name(s) that set the status
     • “Source:” file path(s)
   • If you cannot confidently determine where a message is used, mark it explicitly as “Used in: (needs verification)” rather than guessing.
   • Make the markdown formatting consistent and professional (uniform template per message, consistent headings/bullets/spacing).

Acceptance criteria:

• All user-facing status messages in the codebase follow a single, consistent style.
• files/STATUS_MESSAGES.md matches the post-change reality of the codebase.
• “Location:” is removed and replaced with “Used in:” (function name) and “Source:” (file path).

========================
DELIVERABLES

• Commit(s) implementing Task 1 and Task 2.
• In your final response, provide:
  • A brief summary of what changed.
  • A list of standardized status messages (old → new) where applicable.
  • Pointers to the relevant files changed.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[MrAlders0n]

@copilot Go back and look over the status messages again, below are two examples, these messages mean the same thing, we dont need two different ones for the same reason. Please standarize and make alll status messages follow same structure and feel

"GPS data too old, requesting fresh position".
"GPS data old, trying to refresh position"

[Copilot]

@copilot Go back and look over the status messages again, below are two examples, these messages mean the same thing, we dont need two different ones for the same reason. Please standarize and make al...

Consolidated the duplicate GPS messages. Both auto and manual ping modes now use the same standardized message: "GPS data too old, requesting fresh position". Updated in commit 75e8535.

Changes:

• Line 1514 (auto mode): Changed from "GPS data old, trying to refresh position" → "GPS data too old, requesting fresh position"
• Line 1567 (manual mode): Already used "GPS data too old, requesting fresh position" ✓
• Updated STATUS_MESSAGES.md to document single consolidated message with both source locations
• Total unique messages reduced from 28 to 27

[MrAlders0n]

@copilot Can you go back through all 27 status messages and make sure they use consistent wording, tone, capitalization, and punctuation—and that there are no remaining duplicates (different messages that mean the same thing)? If any overlap, consolidate them into a single standardized message and update both the code and STATUS_MESSAGES.md accordingly.

[Copilot]

@copilot Can you go back through all 27 status messages and make sure they use consistent wording, tone, capitalization, and punctuation—and that there are no remaining duplicates (different message...

Completed comprehensive consistency review of all 25 status messages. Updated in commit a4479a2.

Changes made:

1. Consolidated duplicate "Auto ping sent" → "Ping sent" (both manual and auto now use same message)
2. Fixed capitalization "geo fenced region" → "geofenced region" (proper compound word)
3. Standardized tone "Please wait" → "Wait" (consistent direct, technical tone throughout)

Final consistency achieved:
✅ No trailing punctuation
✅ Sentence case capitalization
✅ Present progressive (-ing) for ongoing actions
✅ Past tense for completed actions
✅ Consistent "X failed" error format
✅ Consistent direct tone (no polite language)
✅ Proper compound words
✅ No duplicate messages

Total messages: 25 unique patterns (reduced from 28)

• Connection: 7 messages
• Ping Operation: 6 messages
• GPS: 2 messages
• Countdown Timers: 6 patterns
• API/Map: 2 messages
• Auto Mode: 3 messages

All messages now follow identical wording, tone, capitalization, and punctuation standards. Documentation updated accordingly.