Update doc prompts to not duplicate implementation note

.github/prompts/audit-docs.prompt.md

@@ -236,10 +236,38 @@ Execute **all three phases** in order.
 
 - **Mandatory File Citations (The "Proof of Work" Rule):**
     - **Strict Requirement:** You are forbidden from describing technical logic without citing the source file.
-    - **Placement:** Do not break the reading flow with inline citations. Place links at the very end of the specific section or paragraph.
-    - **Format:** `Implementation: [filename](./path/to/file)`
+    - **Citation Hierarchy (Prefer Inline First):**
+        1. **Inline (preferred):** Weave the link naturally into the prose so it reads as part of the sentence. This keeps the reading flow intact for human readers.
+            - ✅ Token validation is handled in [`auth.ts`](../src/auth.ts), which checks the Authorization header on every request.
+            - ✅ See [`CONTRIBUTING.md`](../CONTRIBUTING.md) for setup steps.
+        2. **Footer fallback (`Implementation:`):** Use `Implementation: [filename](./path/to/file)` **only** when the context makes inline linking unnatural — for example, when the surrounding text is a bullet list or a table where no prose sentence exists to embed the link.
+            - ✅ Use footer when documenting a list of behaviors with no natural sentence to link from.
+    - **No Redundant Citations:** Never link the same file twice in rapid succession. If it is already linked inline, do not add a footer citation below it.
+        - ❌ WRONG: `See [CONTRIBUTING.md](../CONTRIBUTING.md). Implementation: [CONTRIBUTING.md](../CONTRIBUTING.md)`
     - **Enforcement:** If you cannot find the file to link, **do not write about that logic.** You may not document code you cannot link to.
 
+- **File Reference Linking (STRICTLY ENFORCED - ZERO TOLERANCE):**
+    - **Absolute Rule:** EVERY file reference in documentation MUST be a clickable hyperlink to that file.
+    - **What Counts as a File Reference:** Any mention of a specific filename, regardless of context:
+        - Source code files (`.ts`, `.js`, `.go`, `.py`, etc.)
+        - Configuration files (`.json`, `.yaml`, `.env`, `.toml`, etc.)
+        - Documentation files (`.md`, `.txt`, `README`, etc.)
+        - Scripts (`.sh`, `.ps1`, etc.)
+        - Data files (`.csv`, `.xml`, `.sql`, etc.)
+        - Build files (`Dockerfile`, `Makefile`, `package.json`, etc.)
+    - **Required Format:** Use markdown link syntax: `[filename](relative/path/to/file)`
+    - **Examples of Violations:**
+        - ❌ WRONG: "The config.json file contains server settings"
+        - ✅ RIGHT: "The [`config.json`](../config.json) file contains server settings"
+        - ❌ WRONG: "See server.ts for the implementation"
+        - ✅ RIGHT: "See [`server.ts`](../src/server.ts) for the implementation"
+        - ❌ WRONG: "Authentication logic is in auth/middleware.ts"
+        - ✅ RIGHT: "Authentication logic is in [`auth/middleware.ts`](../auth/middleware.ts)"
+        - ❌ WRONG: "Set environment variables in .env"
+        - ✅ RIGHT: "Set environment variables in [`.env`](../.env)"
+    - **Non-Existent Files:** If you reference a file that doesn't exist in the repository, re-evaluate the statement that relies on that file. Ensure that it is still accurate and verifiable. If not, remove the statement or correct it to reflect the actual codebase.
+    - **Path Verification:** Before writing a file reference, verify the file exists and use the correct relative path from the documentation file's location.
+
 - **High-Density, Low-Volume:**
     - Avoid "Wall of Text." Use bullet points and headers to break up density.
     - Do not narrate code line-by-line. Explain _why_ it exists (architecturally) and _how_ the system uses it.
@@ -406,6 +434,9 @@ For any pre-existing content you modified:
 - _Did I inline a full struct or class definition? (If yes → Replace with link)._
 - _Did I insert NEW subjective words? (If yes → Remove them. Preserved existing ones are OK)._
 - _Did I cite the file for the logic I explained? (If no → Find file or remove text)._
+- _Did I link inline where the prose naturally allowed it, rather than defaulting to a footer `Implementation:` line?_
+- _Did I add a redundant `Implementation:` footer for a file already linked inline in the same paragraph? (If yes → Remove the footer.)_
+- _Did I reference ANY file (source, config, docs, scripts) without making it a clickable link? (If yes → SEVERE VIOLATION: Add the link immediately or delete the reference.)_
 - _Did I create a Mermaid diagram where appropriate for complex systems?_
 - _Did I exclude observability from Mermaid diagrams (unless documenting observability systems)?_
 - _Did I choose the most appropriate Mermaid diagram type for the structure?_
@@ -415,6 +446,7 @@ If you find any:
 
 - **Hallucinations or unverified statements** → Delete immediately, no exceptions
 - **Statements without exact file citations** → Add citation or delete statement
+- **Unlinked file references** (any filename mentioned without a hyperlink) → Add link immediately or delete the reference (ZERO TOLERANCE)
 - **Internal config variable names** → Trace to external source and correct, or delete
 - **Observability steps in non-observability docs** (logging, metrics, tracing, monitoring) → Delete
 - **Trivial validation/utility steps in flows** → Delete

.github/prompts/audit-pr.prompt.md

@@ -42,11 +42,13 @@ For **every finding**, output it in this exact format:
 [Explain clearly why this is a problem: what can go wrong, what rule/best practice it violates, what the risk is.]
 
 **Code (current):**
+
 ```language
 // the problematic snippet
 ```
 
 **Suggested Fix:**
+
 ```language
 // the corrected snippet, or pseudocode if a full fix is complex
 ```
@@ -61,16 +63,16 @@ Before reviewing any code, answer these questions by reading `#activePullRequest
 
 - **PR Title & Description:** Does the title accurately describe the change? Is the description complete and clear?
 - **Linked Ticket (Jira / GitHub Issue):** If a ticket/issue is linked, does the code actually implement what the ticket describes? Call out any gaps, scope creep, or unfinished work.
-  - For **GitHub Issues**, use:
-    - `#issue_fetch`
-    - `#issue_read`
-  - For **Jira tickets**, use:
-    - `#getJiraIssue`
-    - `#getJiraIssueRemoteIssueLinks`
-    - `#getJiraIssueTypeMetaWithFields`
-    - `#getJiraProjectIssueTypesMetadata`
-    - `#searchJiraIssuesUsingJql`
-  - **Note:** These tools may not be available in all GitHub Copilot environments and may require further set-up. If you cannot access them, do not attempt to call them; instead, infer requirements from the PR title/description, visible ticket links, and any in-PR context.
+    - For **GitHub Issues**, use:
+        - `#issue_fetch`
+        - `#issue_read`
+    - For **Jira tickets**, use:
+        - `#getJiraIssue`
+        - `#getJiraIssueRemoteIssueLinks`
+        - `#getJiraIssueTypeMetaWithFields`
+        - `#getJiraProjectIssueTypesMetadata`
+        - `#searchJiraIssuesUsingJql`
+    - **Note:** These tools may not be available in all GitHub Copilot environments and may require further set-up. If you cannot access them, do not attempt to call them; instead, infer requirements from the PR title/description, visible ticket links, and any in-PR context.
 - **Diff Scope:** Are there any files changed that seem unrelated to the PR's stated purpose?
 - **Breaking Changes:** Does the PR introduce breaking changes without documenting them?
 - **PR Size:** Is the PR too large to review meaningfully? If so, note it.
@@ -114,8 +116,8 @@ Review `#activePullRequest #changes` across all of the following categories. Ski
 - Is sensitive data encrypted at rest and in transit?
 - Is the minimum necessary data being collected (data minimization)?
 - Are there any new logging statements that could leak sensitive user data (emails, names, health data, IDs)?
-  - Risky: user inputs, API request/response bodies, database records
-  - Never log: passwords, tokens, API keys, session IDs
+    - Risky: user inputs, API request/response bodies, database records
+    - Never log: passwords, tokens, API keys, session IDs
 - Is role-based access control (RBAC) applied to sensitive data correctly?
 
 ---
@@ -251,19 +253,24 @@ After all findings, output a structured summary:
 ## ✅ / 🟡 / 🔴 Overall Verdict: [APPROVED / APPROVED WITH SUGGESTIONS / CHANGES REQUESTED]
 
 ### Quick Stats
+
 - **Files reviewed:** X
 - **Findings:** X Blocking · X Non-blocking · X Suggestions · X Positive callouts
 
 ### PR Alignment
+
 [1–3 sentences on whether the code does what the PR/ticket says]
 
 ### Top Concerns
+
 [Bullet list of the most critical issues — these are the ones that must be resolved before merge]
 
 ### What's Done Well
+
 [Bullet list of genuinely good patterns, decisions, or improvements in this PR]
 
 ### Before Merging
+
 - [ ] [Action item 1]
 - [ ] [Action item 2]
 - [ ] ...

docs/architecture/configs.md

@@ -2,8 +2,6 @@
 
 This document describes configuration files and environment setup in AlexJSully's Portfolio project, their roles, technical details, and how to update or extend them.
 
-Implementation: [firebase.ts](../../src/configs/firebase.ts), [next.config.js](../../next.config.js)
-
 ## Purpose
 
 Configs manage environment variables, service integrations, and global settings for the app. They enable features like Firebase, Sentry error tracking, and custom runtime options.
@@ -16,8 +14,8 @@ Configs manage environment variables, service integrations, and global settings
     - `firebase.test.ts`: Test configuration for Firebase
 - **Related config files:**
     - `.env`: Environment variables (API keys, secrets)
-    - `next.config.js`: Next.js build/runtime config
-    - `sentry.client.config.ts`, `sentry.server.config.ts`, `sentry.edge.config.ts`: Sentry error tracking
+    - [`next.config.js`](../../next.config.js): Next.js build/runtime config
+    - [`sentry.client.config.ts`](../../sentry.client.config.ts), [`sentry.server.config.ts`](../../sentry.server.config.ts), [`sentry.edge.config.ts`](../../sentry.edge.config.ts): Sentry error tracking
 
 ## Usage Examples
 

docs/usage/setup.md

@@ -45,10 +45,12 @@ This guide walks you through installing, configuring, and running the Alexander
     - `NEXT_PUBLIC_FIREBASE_MESSAGING_SENDER_ID`
     - `NEXT_PUBLIC_FIREBASE_APP_ID`
     - `NEXT_PUBLIC_FIREBASE_MEASUREMENT_ID`
-    - `NEXT_PUBLIC_SENTRY_DSN` (if Sentry is used in your environment)
-      Place these keys in a local `.env` file during development. Do not commit `.env` to git.
+    - `NEXT_PUBLIC_SENTRY_DSN` (if Sentry is used in your environment).
+
+    Set these keys as environment variables during development (commonly via a local untracked `.env` file). Do not commit real secrets to git.
+
 - **Path Aliases:**
-    - Use TypeScript aliases (see `tsconfig.json`). The project exposes aliases like `@components`, `@data`, `@configs`, `@helpers`, and `@images` for cleaner imports.
+    - Use TypeScript aliases (see [`tsconfig.json`](../../tsconfig.json)). The project exposes aliases like `@components`, `@data`, `@configs`, `@helpers`, and `@images` for cleaner imports.
 
 ## 🧪 Testing & Validation
 
@@ -72,7 +74,6 @@ npm run test:jest
 
 ## 📝 Troubleshooting
 
-- See [Troubleshooting Guide](./troubleshooting.md) _(to be added)_
 - For help, open an issue or see [README.md](../../README.md)
 
 ---