# Barkday Continuity Roadmap

Last updated: 2026-05-04

This note reconciles the current Barkday direction with older master notes and project notes. It is a continuity guide, not a full master-note replacement and not an implementation plan.

## Current Baseline

- Barkday is app-first: the core value is the calculator, Bark Day planning, care guidance, training, enrichment, and a positive celebratory experience.
- GitHub Pages is staging/testing and the current public hosting path.
- The v2 gift feed is canonical. See `docs/decisions/DEC-20260504-01-v2-gift-runtime-feed.md`.
- Approved-only gift display is present. Missing `publishStatus` must not make bulk/API candidates visible.
- API and bulk product output is candidate inventory, not live recommendation inventory.
- Gift recommendations are optional and additive. They must not displace Barkday's core care, training, enrichment, life-stage, and bonding purpose.
- Barkday(TM) name/trademark baseline is documented in `README.md` and maintainer notes.

## Gift and Affiliate System

- V2 gifts are canonical. Root `dog-gifts.json` remains legacy compatibility only.
- Gift source should remain rebuildable from v2 source inputs into `data/dog-gifts-catalog.json` and `data/dog-gifts-merged.json`.
- Candidate rows should remain `review`, `draft`, or `retired` until explicitly promoted to `approved`.
- Amazon Associates, PA-API, Chewy links, Amazon storefront options, and other affiliate/store paths remain compliance-sensitive topics.
- Affiliate disclosure must remain clear and near gift surfaces before affiliate interaction.
- Do not fetch new product data or add products without routing through the candidate and curation pipeline.

## Paid Model - On Hold

- Older notes describe Plus, Pro, Breeder, Cloudflare Worker/KV, JWT, Stripe, Play Billing, premium JSON, dog-count limits, litter mode, and abuse controls.
- Treat those paid-tier notes as future reference, not current marching orders.
- Paid implementation is paused until affiliate/program compliance, app-store policy, user-trust, and launch-timing concerns are resolved.
- Do not plan or implement Plus/Pro/Breeder gates in the next development cycle.
- Do not move proprietary JSON, add license checks, add payment endpoints, or add premium data loaders as the next active implementation path.
- The old paid-tier architecture may still be useful later if Barkday has a stable free launch, clear policy review, and a durable value proposition for heavy users.

## Affiliate and Monetization Compliance Gate

- Open question: whether Amazon affiliate links remain safe if the app later becomes paid, partially paid, or gated in any way.
- Current conservative assumption: affiliate links remain optional, clearly disclosed, and not hidden behind a paywall.
- Before paid work resumes, review current official Amazon Associates/PA-API rules, Google Play policy, and Apple App Store policy.
- Avoid monetization structures that risk Amazon demonetization, app-store rejection, misleading affiliate placement, or user trust damage.
- Long-term income must be compliant and durable, not a quick launch shortcut.
- Partner perks or discounts may be considered later, but gift access itself should remain public unless policy review explicitly supports a different approach.

## PA-API and Official API Parking Lot

- The official Amazon API path has been explored conceptually.
- Secrets and signing material must stay server-side. The public app shell must not call Amazon APIs directly.
- PA-API output should feed candidate generation and local/server-side curation, not direct display.
- Future work should connect PA-API `SearchItems`/`GetItems` outputs to the candidate pipeline and preserve ASIN, affiliate URL, source title, and source features for traceability.
- Rate limits, content freshness, image/content caching, and offer display rules must be solved before any Amazon-enriched runtime data is shown.

## Launch Strategy Parking Lot

- Current leaning: launch free or free-to-try first if paid work would double the launch window.
- Paid model may later focus on breeders, designers, trainers, multi-dog households, or heavy users who receive real value.
- Barkday certificate printing remains a positive hook and a potential free-advertising mechanism.
- The certificate angle should feel celebratory and useful, not extractive.
- GitHub Pages can continue serving as staging/testing while production origin, app links, service worker scope, and wrapper behavior are verified deliberately.

## Aging Model and Bark Day Logic

- The current baseline is the 15/9 model: about 15 Bark Days in the first human year and 9 in the second.
- Existing weight/size-aware curves and smoothing remain baseline until a specific curve task starts.
- Older aging-model notes preserve useful future ideas: post-24-month breed modifiers, size scaling, curve registry, piecewise overrides, and breed-specific curve labels.
- Future curve work should support:
  - default 15/9 curve behavior
  - weight or size scaling
  - post-24-month breed modifiers
  - a small curve registry such as `curves.json`
  - future breed-specific curve overrides when evidence is strong
- Do not implement curve registry, Labrador overrides, or taxonomy `age_rate`/`size_scale` fields until scoped as a separate data/model task.

## Mixed-Breed DNA and Breed Logic Parking Lot

- Mixed-breed support should start with the top three breed percentages, not an unbounded breed list.
- Embark/Wisdom-style paste parsing is future work and should include manual review/correction before applying recommendations.
- Weighted logic should consider size, age-rate, energy, chew tendency, health, training, exercise, care, and enrichment guidance.
- Designer/companion hybrid cohort work is separate from DNA-mix mode:
  - designer/hybrid cohort can use curated known breed-group content
  - DNA-mix mode should weight user-provided breed percentages
- Breed group and top-breed data should support recommendations without replacing the calculator baseline.
- Mixed-breed DNA work remains planned until data shape, safety text, UI review, and launch priorities are settled.

## Non-Gift Launch Content

Before a release candidate, review non-gift recommendation content for:

- health and wellness
- training and enrichment
- diet and nutrition
- exercise needs
- play and bonding
- helpful gear
- age and life-stage messaging

This content needs safety review. Barkday should frame recommendations as general guidance only, not veterinary advice, diagnosis, treatment, or guaranteed outcomes.

### Guardian Education Principle

See `docs/principles/guardian-education-and-veterinary-guidance.md`.

Barkday does not diagnose, prescribe, or replace veterinary care. It should help guardians observe patterns, track changes, ask informed questions, and seek qualified veterinary guidance or a second opinion when symptoms, explanations, or treatment response do not make sense.

Health and care guidance should stay practical and empowering without reducing every recommendation to passive "ask your vet" language.

## Deployment and Protected Data

- Private, premium, or protected data should not live in the public repository or shipped app shell.
- Public runtime data can be remotely fetched, but proprietary overlays should stay behind a protected endpoint if they are ever created.
- The app-store wrapper path still needs readiness testing, including external opening behavior for affiliate links, production domain/scope alignment, and store policy review.
- Do not treat old paid-hosting notes as permission to start production backend work before policy and launch sequencing are resolved.

## Historical or Superseded Findings

Treat these as verify-only unless current symptoms remain:

- old raw gift-feed findings from before the v2 runtime feed decision
- old chewer enum bug and `strong`/`power` mismatch
- old service-worker JSON cache warning
- old affiliate disclosure warning
- broken button fixes
- dog age calculator fixes
- data update checks
- popup modal/result UI work
- calendar notification improvements
- chart value and milestone comparison questions
- custom 404 image handling
- save-result button necessity and placement
- slider usability adjustments
- markdown/readme cleanup topics

If symptoms recur, reproduce against current `main` and fix the current code path rather than reapplying old chat snippets.

## Next Recommended Stages

1. Finish and freeze the gift curation gate.
2. Inventory all runtime data and classify each source as public, candidate, generated, protected, or legacy.
3. Classify public versus protected content before adding premium/proprietary overlays.
4. Clean and safety-review non-gift launch content.
5. Plan the mixed-breed DNA feature around explicit input shape and weighted recommendation rules.
6. Review affiliate/app-store policy before paid model work resumes.
7. Verify wrapper/store behavior against the intended production origin.
8. Prepare a release candidate with validation, local browser checks, and deployment-path checks.

## Older Notes Status

- `docs/Master_Note_v0_Barkday_Aging-Model_Integration_Master_Note.md`: useful future aging-model reference; not active scope.
- `docs/Master_Note_v1—Designer_Companion_Hybrid_Cohort.md`: useful designer/hybrid reference; separate from DNA-mix mode.
- `docs/Master_Note_v2—Paid_Tier_&_Hosting_Gate_(Single_Codebase).md`: paid-tier reference only; on hold.
- `docs/Master_Note_v3—Monetization_Limits_&_Abuse_Prevention.md`: monetization/limits reference only; on hold.
- `docs/Barkday_MASTER-NOTE_v2025-10-09-1.md`: broad historical master note; some paid/API sections are superseded by this on-hold guidance.
- `docs/Data expansion plan.md`: valuable data governance and launch-content guidance; still useful.
- `docs/barkday_code_review_2025-10-26.md`: historical review; verify findings only against current symptoms.
- `docs/principles/guardian-education-and-veterinary-guidance.md`: core wording standard for health, care, training, and wellness content.

## Resume Point

## Next Recommended Stages

1. Confirm the gift curation gate remains stable during normal validation.
2. Inventory all runtime data and classify each source as public, candidate, generated, protected, or legacy.
3. Classify public versus protected content before adding premium/proprietary overlays.
4. Clean and safety-review non-gift launch content.
5. Plan the mixed-breed DNA feature around explicit input shape and weighted recommendation rules.
6. Review affiliate/app-store policy before paid model work resumes.
7. Verify wrapper/store behavior against the intended production origin.
8. Prepare a release candidate with validation, local browser checks, and deployment-path checks.