Establish a privacy-safe support and feature-demand feedback loop

[lightcloud00]

Outcome

Convert voluntary customer feedback into a bounded product and revenue signal without collecting parking histories or exact locations.

Dependencies

• Final support channel and public domain in Acquire final domain and replace candidate canonical/support URLs #10
• Legal/support review in Finalize legal, privacy, App Store metadata, and screenshots #8

Plan

• Publish support categories: bug, directions, meter reminder, garage details, purchase/restore, price/value, feature request, privacy, and accessibility.
• Add a prominent warning not to send exact parking coordinates, photos, license plates, receipts, or other sensitive data unless support explicitly needs a redacted example.
• Define severity, reproducibility, request count, user job, paid/free impact, and resolution fields.
• Produce a monthly anonymized summary with no customer identifiers or message quotations.
• Link repeated requests to existing GitHub issues; search open and closed issues before opening a new one.
• Feed validated demand into Run a quarterly parking-app trend and competitor evidence review #21 and the revenue scorecard without treating anecdotes as conversion data.

Guardrails

• No in-app behavioral tracking or silent upload.
• No public posting of customer messages.
• Security/privacy reports follow a private escalation path rather than a public issue.

Acceptance

• Support page, templates, retention policy, and triage cadence are documented.
• One dry-run request is handled end-to-end and redacted.
• Monthly output links decisions, not raw personal data.

---

Scope / non-scope

Only the work and evidence already described in this issue are in scope. Merge, deployment, provider or store mutation, spend, billing, customer contact, device acceptance, indexing, and release remain separate gates unless this issue explicitly includes them and fresh proof is recorded.

Evidence and closure

Close only from exact current-source evidence plus the applicable independent readback. Keep local, GitHub/CI, provider, deployment, device, store, commerce, indexing, traffic, and revenue evidence distinct; one does not imply another.

Owner / lane

The repository delivery lane owns ordinary implementation and verification. The operator owns only actions explicitly marked as operator-only or protected.

Resolution plan

• Verified: 2026-08-25T05:34:23Z against main@04a6cd5e808720983471ee9595fd40bc94e1f0fe (commit time 2026-08-25T00:53:29Z).
• Source basis: Original issue body, all 0 comment(s), current default-branch tree, disposition-appropriate source-path checks, and referenced pull-request states.
• Disposition: Operator or external gate - execute only the bounded proof steps and stop at protected actions.
• Outcome: Convert voluntary customer feedback into a bounded product and revenue signal without collecting parking histories or exact locations.

Current evidence and corrected premise

The issue remains open and requires the resolution steps below.
All 0 issue comment(s) were read. There are no comments.

Resolution steps

1. Refresh the authoritative external state and bind it to the exact account, app, build, deployment, or provider identity.
2. Reconcile that readback with the issue-authored work below and identify the smallest remaining action.
3. Prepare the protected action, rollback, and failure receipt without exposing credentials or inferring authority.
4. Stop for the required operator decision or action, then execute it once through the owning workflow.
5. Validate the official readback and map it to every acceptance item before closure.

Grounded issue-authored detail

Scope / non-scope

Only the work and evidence already described in this issue are in scope. Merge, deployment, provider or store mutation, spend, billing, customer contact, device acceptance, indexing, and release remain separate gates unless this issue explicitly includes them and fresh proof is recorded.

Tests and acceptance

Acceptance

• Support page, templates, retention policy, and triage cadence are documented.
• One dry-run request is handled end-to-end and redacted.
• Monthly output links decisions, not raw personal data.

---

Dependencies and stop gates

Dependencies

• Final support channel and public domain in Acquire final domain and replace candidate canonical/support URLs #10
• Legal/support review in Finalize legal, privacy, App Store metadata, and screenshots #8
• Do not close this issue until every acceptance item is mapped to exact merged-head evidence.

Next AI first action

Only the work and evidence already described in this issue are in scope. Merge, deployment, provider or store mutation, spend, billing, customer contact, device acceptance, indexing, and release remain separate gates unless this issue explicitly includes them and fresh proof is recorded.

[lightcloud00]

Verified issue disposition — blocked_external

This is the current managed disposition for lightcloud00/parknudge#24 at default-branch 5c3d185143a2.

Current evidence

• Current stable snapshot for Establish a privacy-safe support and feature-demand feedback loop #24 at 5c3d185143a2 keeps the issue open with body hash 355ba0eda829; the validated grounded planner classified it as blocked_external.

Files or owner actions

• For Establish a privacy-safe support and feature-demand feedback loop #24, bind the issue title 'Establish a privacy-safe support and feature-demand feedback loop' to one existing source path or named owner action before implementation.

Bounded plan

• For Establish a privacy-safe support and feature-demand feedback loop #24: Resolve the recorded targeted-source diagnostic or bind a canonical checkout before any implementation attempt.
• For Establish a privacy-safe support and feature-demand feedback loop #24: Complete every read-only and local source check that does not require the external owner or protected system.
• For Establish a privacy-safe support and feature-demand feedback loop #24: Bind the remaining decision to the exact issue surfaces: Establish, privacy-safe, support, feature-demand, feedback, loop.
• For Establish a privacy-safe support and feature-demand feedback loop #24: Record the required owner input as one explicit question with a recommended default and impact of deferral.
• For Establish a privacy-safe support and feature-demand feedback loop #24: Continue the portfolio queue; resume this issue only when the named external proof or decision arrives.

Commands

• Run git grep -n -F Establish main for Establish a privacy-safe support and feature-demand feedback loop #24 and retain sanitized output.
• Run git grep -n -F privacy-safe main for Establish a privacy-safe support and feature-demand feedback loop #24 and retain sanitized output.
• Run git grep -n -F support main for Establish a privacy-safe support and feature-demand feedback loop #24 and retain sanitized output.
• Run git grep -n -F feature-demand main for Establish a privacy-safe support and feature-demand feedback loop #24 and retain sanitized output.
• Run git grep -n -F feedback main for Establish a privacy-safe support and feature-demand feedback loop #24 and retain sanitized output.
• Run python3 -m pytest -q for Establish a privacy-safe support and feature-demand feedback loop #24 and retain sanitized output.

Acceptance tests

• For Establish a privacy-safe support and feature-demand feedback loop #24: [ ] Support page, templates, retention policy, and triage cadence are documented.
• For Establish a privacy-safe support and feature-demand feedback loop #24: [ ] One dry-run request is handled end-to-end and redacted.
• For Establish a privacy-safe support and feature-demand feedback loop #24: [ ] Monthly output links decisions, not raw personal data.
• For Establish a privacy-safe support and feature-demand feedback loop #24: [ ] Support page, templates, retention policy, and triage cadence are documented.
• For Establish a privacy-safe support and feature-demand feedback loop #24: [ ] One dry-run request is handled end-to-end and redacted.
• For Establish a privacy-safe support and feature-demand feedback loop #24: [ ] Monthly output links decisions, not raw personal data.

Risks

• For Establish a privacy-safe support and feature-demand feedback loop #24, a false source binding could widen the change or invalidate this plan; Revert only the exact task-branch change after capturing source and runtime identity; never reset or restore an owner worktree.

Stop gates

• For Establish a privacy-safe support and feature-demand feedback loop #24: no issue close, reopen, body edit, pull-request, branch, or merge mutation while implementing this plan
• For Establish a privacy-safe support and feature-demand feedback loop #24: the managed plan comment and disposition-specific readiness labels are the only authorized issue mutations in the planning lane
• For Establish a privacy-safe support and feature-demand feedback loop #24: no push, protected-branch update, force-push, or merge
• For Establish a privacy-safe support and feature-demand feedback loop #24: no deploy, upload, App Store Connect, TestFlight, or public release
• For Establish a privacy-safe support and feature-demand feedback loop #24: no credential value disclosure, rotation, billing, or provider change
• For Establish a privacy-safe support and feature-demand feedback loop #24: no owner-worktree restore, reset, checkout, process signal, or queue reorder

Named owner action

• Gus must complete or coordinate the protected action 'Establish a privacy-safe support and feature-demand feedback loop' for Establish a privacy-safe support and feature-demand feedback loop #24, then attach sanitized evidence at proof/parknudge-24/acceptance.json.

Proof target

• proof/parknudge-24/acceptance.json

Retry trigger

• Retry Establish a privacy-safe support and feature-demand feedback loop #24 only after proof/parknudge-24/acceptance.json records the title-specific external action as complete.

---

Ledger schema: aos.github-issue-plan-coverage.v1 · issue body: 355ba0eda829