Refactor for template use and genericize personal data

Converted project from a personal portfolio to a reusable template by replacing hardcoded names, emails, URLs, and branding with generic placeholders and environment variables. Updated documentation, scripts, and configuration files to guide downstream users on customizing the template. Adjusted localStorage keys, build labels, and remote data endpoints to avoid collisions for template forks. Provided example LICENSE guidance and improved clarity for contributors and maintainers.

Author: kiyarose

.firebaserc

@@ -1,5 +1,5 @@
 {
   "projects": {
-    "default": "kiyaverse"
+    "default": "template-portfolio"
   }
 }

.github/copilot-instructions.md

@@ -1,3 +1,59 @@
+# Copilot / AI agent instructions (project-specific)
+
+This file contains focused, actionable rules for automated coding agents working in the KR_Portf repository. Keep guidance short and specific — prefer small, safe edits and follow the project's conventions.
+
+## Quick architecture & big picture
+- Vite + React + TypeScript front-end served via Firebase Hosting. Entry points: `src/main.tsx` → `src/App.tsx` → `src/AppRouter.tsx`.
+- UI components: `src/components/`; page sections: `src/sections/`; content/data: `src/data/` (e.g., `build.ts`, `projects.ts`).
+- Theme and context providers: `src/providers/ThemeProvider.tsx`, `src/providers/theme-context.ts` and hook `src/hooks/useTheme.ts`.
+- Tests and visual checks: Playwright + Vitest under `tests/` and `playwright.config.ts`.
+
+## Project-specific conventions (follow these)
+- Compose Tailwind utility classes directly in JSX. Use PascalCase for components and camelCase for hooks.
+- Visual style: rounded Material-like cards (`rounded-3xl`, `shadow-card`), warm orange/pink accents (`#f97316`, `#ec4899`), and `.font-kiya` for the printed name "Kiya Rose" (font located in `public/fonts`).
+- Respect `prefers-reduced-motion`. Framer Motion is used; prefer short fade/slide transitions and provide reduced-motion fallbacks.
+- Footer/legal: use `getBuildUpdatedAt()` from `src/data/build.ts` for the "Last updated" date — do not hard-code timestamps.
+- Contact form: client-only `mailto:` generation plus copy-to-clipboard CTA (see `src/sections/ContactSection.tsx`).
+
+## Environment & secrets
+- Environment variables use the `VITE_` prefix. Critical: `VITE_TURNSTYLE_SITE` is intentionally misspelled (no second "t"); do not rename it.
+- Never commit secrets. Use `.env.local` locally and GitHub Secrets in CI.
+
+## Common developer workflows & commands
+- Install deps: `npm ci` or `npm install`.
+- Dev server: `npm run dev` (Vite, http://localhost:5173).
+- Lint: `npm run lint` (run before PR).
+- Build: `npm run build` → `dist/` for Firebase Hosting.
+- Local hosting preview: `firebase emulators:start --only hosting` (project has `firebase.json`).
+- Run tests: `npm run test` (Playwright tests and other test runners configured in package.json).
+
+## Places to inspect for examples and patterns
+- Routing & layout: `src/App.tsx`, `src/AppRouter.tsx`.
+- Footer/build label: `src/components/SiteFooter.tsx`, `src/data/build.ts` (localStorage prefix behavior).
+- Contact flow: `src/sections/ContactSection.tsx` (mailto + clipboard behaviour).
+- Theme logic: `src/providers/ThemeProvider.tsx`, `src/hooks/useTheme.ts`.
+- Page-level sections: `src/sections/*` — follow their existing patterns for spacing, animation, and accessibility.
+
+## Editing guidance for AI agents
+- Make smallest useful change. Prefer a focused PR per issue.
+- Preserve existing UX and data flows. If you change `src/data/build.ts` or footer code, preserve the localStorage build-label behavior unless explicitly fixing it.
+- Avoid global CSS: adhere to Tailwind utility usage in JSX.
+- When adding routes: update `src/AppRouter.tsx` and use `src/utils/navigation.ts` helpers.
+
+## Tests & quality gates
+- Before proposing changes: run `npm run lint` and `npm run build` locally.
+- Test files live under `tests/` (e.g. `a11y.spec.ts`, `screenshot.spec.ts`); Playwright is used for integration/visual checks.
+
+## Native companion tool
+- `$DashCam!/` holds a macOS Swift helper app used by developers to manage dev and playwright codegen tasks. If you modify related scripts, update the DashCam Swift sources under `$DashCam!/Sources/DashboardApp`.
+
+## PR checklist for automated changes
+- Lint passes (`npm run lint`).
+- Build succeeds (`npm run build`).
+- No secrets committed.
+- Follow naming and Tailwind conventions.
+
+If any section is unclear or you want more repo file examples, say which area to expand and I will iterate.
 # Copilot Instructions
 
 ## Style & Architecture

.github/workflows/cloudflare-pages-merge.yml

@@ -39,7 +39,8 @@ jobs:
         with:
           apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
           accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
-          projectName: kiyaverse
+          # Replace projectName with your Cloudflare Pages project name
+          projectName: template-portfolio
           branch: main
           directory: dist
           gitHubToken: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/cloudflare-pages-preview.yml

@@ -42,7 +42,8 @@ jobs:
         with:
           apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
           accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
-          projectName: kiyaverse
+          # Replace projectName with your Cloudflare Pages project name
+          projectName: template-portfolio
           branch: ${{ github.event.pull_request.head.ref }}
           directory: dist
           gitHubToken: ${{ secrets.GITHUB_TOKEN }}

AGENTS.md

@@ -7,7 +7,9 @@
 - `npm run build` outputs to `dist/`, which Firebase Hosting serves via `firebase.json`.
 - `.github/workflows/` houses CI/CD pipelines—update them when scripts or deploy behavior changes.
 - Top-level layout pieces (`SiteHeader`, `PrimaryNav`, `SiteFooter`) live in `src/App.tsx`; keep large JSX trees broken into helpers to satisfy lint rules.
-- The root `LICENSE` is BSD 3-Clause (2025, Kiya Rose); mirror that notice when legal text appears elsewhere.
+- The root `LICENSE` is BSD 3-Clause (2025, Kiya Rose); preserve this BSD-3-Clause notice and the original copyright
+	line in any redistribution or derived work. Do not remove or replace this license without explicit permission from
+	the copyright holder. When referencing the license in documentation, point to `LICENSE` in the repo.
 - `src/data/build.ts` exposes helpers for the build label and build timestamp: the label stores a random prefix in `localStorage` keyed by the build signature so it only changes when the code does, and `getBuildUpdatedAt()` surfaces the deploy timestamp for privacy/legal copy—leave that flow intact.
 - `src/AppRouter.tsx`, `src/pages/PrivacyPolicyPage.tsx`, and `src/utils/navigation.ts` handle lightweight client-side routing so `/privacy-policy` renders inside the React app without duplicating static assets.
 
@@ -35,8 +37,8 @@
 - Accent palette leans warm orange and pink (`accent.DEFAULT` `#f97316`, `accent.muted` `#ec4899`); dark mode remains deep slate—match those tones across new UI.
 - Use rounded Material Symbols icons for navigation, social chips, and headers to keep iconography consistent.
 - Drive animations with Framer Motion; always respect `prefers-reduced-motion` and provide sensible fallbacks (toggle animation uses short fade/slide, not full spins).
-- The custom `.font-kiya` (Nanum Pen Script) highlights the name “Kiya Rose”; apply it consistently when the name appears in new sections.
-- The footer should surface a dynamic current year, the typographic © symbol, the `.font-kiya` name, and the build label (prefix = last edit signature, suffix = render id) alongside the “Crafted with React, Tailwind CSS, and Firebase.” line, with a pill-style tooltip explaining the two segments.
+- The custom `.font-kiya` (Nanum Pen Script) highlights the site owner's name (for example, “Your Name”); apply it consistently when the owner name appears in new sections. Add a comment near any hard-coded display name so template users know to update the font usage.
+- The footer should surface a dynamic current year, the typographic © symbol, the `.font-kiya` display name (e.g. “Your Name”), and the build label (prefix = last edit signature, suffix = render id) alongside the “Crafted with React, Tailwind CSS, and Firebase.” line, with a pill-style tooltip explaining the two segments. Keep a short inline comment pointing at `src/data/build.ts` so template users can find where the build label is generated.
 - Privacy and legal copy should pull their “Last updated” value from `getBuildUpdatedAt()` so the date reflects the latest build automatically—never hardcode the date.
 - Developing skills use a dotted accent pill—follow the existing `isDeveloping` pattern in `SkillsSection` when adding new skills.
 - The contact form generates a `mailto:` draft; keep it client-only (no POST handlers) and preserve the copy-to-clipboard CTA.

CONTRIBUTING.md

@@ -1,5 +1,66 @@
-# Contributing to my Portfolio
+# Contributing to this template
 
-If you want to change something major make a suggestion via the [issues tab](https://github.com/kiyarose/Portf/issues).
-Otherwise you are free to make a fork of this project and make a PR to a new branch and I will review it for implementation.
-If you have any questions use the contact form on the website.
+This repository is a community-friendly template. If you find a bug or want to propose improvements:
+
+- Open an issue in the template's repository (or your fork) describing the change.
+- Send a PR against `main` with a focused change and clear description/screenshots for visual changes.
+
+If you've forked this template to make a personal portfolio, treat your fork as the canonical source for your site and maintain your own issues/PRs there.
+
+---
+
+Below are suggestions and quick checks to help you convert this repo into your own project, or to accept contributions to the template itself.
+
+## For people using this template (your fork)
+
+- Keep your fork as the canonical source for your personal site. Maintain issues/PRs on your fork and update the following files early in your edit process:
+  - `README.md` — update site name, short description, and deploy steps.
+  - `LICENSE` — replace the copyright line (see `LICENSE.example` for guidance).
+    - Important: this template includes a BSD-3-Clause `LICENSE` that must be preserved as-is in the source
+      when redistributing or publishing derived works (see `LICENSE.example` for how to add your own copyright
+      attribution without removing the original line).
+  - `public/index.html` and `src/data/*` — replace demo content with your personal content.
+
+- If you plan to accept outside contributions on your fork, add a `CODE_OF_CONDUCT.md`, a `PULL_REQUEST_TEMPLATE.md`, and/or an `ISSUE_TEMPLATE/` directory so contributors have clear expectations.
+
+## For contributors to this template repository
+
+- Keep changes small and focused. This repo is used as a starting point for many forks, so API and config stability matters.
+- Before submitting a PR, run the normal checks:
+  - `npm run lint`
+  - `npm run build`
+  - Run tests where present (`npm test` / Playwright checks)
+  - Update/add documentation or inline comments for new features.
+
+## Customizing contribution policies
+
+You may want a different collaboration model depending on how public you want the project to be:
+
+- Public template (default): allow issues and PRs from the community, protect `main` with branch protections, and enable CI checks.
+- Private/managed template: restrict PRs to maintainers, require issue approval or design review before merging.
+
+Suggested repo files to add if you change the model:
+
+- `CODE_OF_CONDUCT.md` — sets community expectations.
+- `PULL_REQUEST_TEMPLATE.md` — helps contributors include tests, screenshots, or migration notes.
+- `CODEOWNERS` — assigns reviewers automatically.
+
+## Security and license reminders
+
+- This repo ships a default `LICENSE` (BSD 3-Clause). If you change the license for your fork, update the `LICENSE` file and the `package.json` `license` field.
+- Preserve existing license headers and notices when redistributing or modifying upstream code. See `LICENSE.example` for guidance on common license choices and how to update attribution.
+  - Preserve existing BSD-3-Clause headers and notices (including the 2025 Kiya Rose attribution) when redistributing or modifying upstream code. `LICENSE.example` shows how to add your own copyright line in
+    addition to the original notice so legal attribution is not lost.
+- If you add new developer tools (linters, scanners, or CI steps) that require secrets or external services, document how to configure them in the `README.md` and `SECURITY.md` so downstream users can replicate or opt out.
+
+---
+
+If you want, I can also add example `PULL_REQUEST_TEMPLATE.md` and `CODE_OF_CONDUCT.md` files tailored for a template repository.
+# Contributing to this template
+
+This repository is a community-friendly template. If you find a bug or want to propose improvements:
+
+- Open an issue in the template's repository (or your fork) describing the change.
+- Send a PR against `main` with a focused change and clear description/screenshots for visual changes.
+
+If you've forked this template to make a personal portfolio, treat your fork as the canonical source for your site and maintain your own issues/PRs there.

LICENSE

@@ -25,4 +25,4 @@ DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
 SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
 CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
 OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

LICENSE.example

@@ -0,0 +1,48 @@
+This repository includes a default `LICENSE` file (BSD 3-Clause) that must be preserved in source redistributions.
+
+Use this `LICENSE.example` as guidance before you change the active `LICENSE` file in your fork. Important: do not remove or replace the BSD-3-Clause notice or the original copyright
+attribution to Kiya Rose (2025) when redistributing or publishing derived works unless you have explicit permission from the copyright holder.
+
+1) Picking a license
+
+- Permissive licenses (BSD, MIT, Apache 2.0): allow others to reuse and redistribute your code with few restrictions. Apache 2.0 adds an explicit patent grant.
+- Copyleft licenses (GPL family): require downstream projects to publish derivative works under the same license.
+- Creative Commons licenses are sometimes used for non-code assets (images, documentation) but are not recommended for source code.
+
+Choose the license that aligns with how you want others to use and contribute to your project.
+
+2) Editing `LICENSE`
+
+- If you want to add your own copyright attribution in a fork, add your line below the original notice rather than replacing it.
+
+  Example (do not remove the original):
+
+  Copyright (c) 2025, Kiya Rose
+
+- Update the `package.json` `license` field to match the chosen license identifier (for example, `"BSD-3-Clause"`, `"MIT"`, `"Apache-2.0"`, or `"GPL-3.0-only"`).
+
+3) Preserving upstream attribution and notices
+
+- If you redistribute modified code that includes code from other projects, preserve their license headers and notices as required by the original license.
+- For BSD-3-Clause (the default here), keep the copyright notice, list of conditions, and disclaimer in source redistributions.
+
+4) If you change the license
+
+- Changing the license of a project you don't exclusively own may require permission from contributors or rights holders. If the template has many contributors, consider whether you need contributor consent.
+
+5) Security & contributor tooling notes
+
+- If you add security scanners, dependency checks, or other developer tooling that requires credentials, document the required environment variables in `.env.example` and do not commit secrets.
+- If your license choice or contributor policies require Contributor License Agreements (CLAs) or DCO signoffs, add the necessary templates (`CLA.md` or a sign-off checklist) and document how contributors should sign.
+
+6) Example quick steps to make the template your own
+
+- Fork the repo.
+- Update `LICENSE` (change copyright line and year).
+- Update `README.md` and `public/index.html` with your site name and contact info.
+- Replace `src/data/*` content with your portfolio data.
+- Update `package.json` `name` and `license` fields.
+
+---
+
+Keep the active `LICENSE` file in the repo for legal clarity; this `LICENSE.example` is only guidance and should not replace the real `LICENSE` file in downstream forks.