@hdwebsoft/hdcode-ai-darwin-x64 0.0.6 → 0.0.8

package/resources/skills/hd-code-review/reference/stacks/wordpress.md

@@ -0,0 +1,54 @@
+# Stack: WordPress — Additional Review Checks
+
+Injected IN ADDITION to `php` preset when WordPress signals are detected:
+- `wp-config.php` in the diff
+- `wp-content/` paths in the diff
+- `functions.php` in a theme directory
+- WordPress function calls (`add_action`, `add_filter`, `get_option`, `WP_Query`, `WP_Post`) in `.php` files
+
+Contains WordPress-specific checks only — PHP-level checks are in `php.md`.
+
+---
+
+## Aspect 2 — Correctness (additional)
+
+- `WP_Query` without `wp_reset_postdata()` after a custom loop — corrupts the global `$post` variable for any subsequent loop on the same page.
+- `get_option()` return value used without checking for `false` — returns `false` when the option doesn't exist; always provide a default: `get_option('key', $default)`.
+- Direct `$wpdb->query()` with `sprintf` / string concatenation — SQL injection. Use `$wpdb->prepare()` for all queries with variable input.
+- `wp_die()` called in an AJAX handler without `wp_send_json_error()` — AJAX callers receive an HTML error page instead of JSON, breaking the frontend response handler.
+
+---
+
+## Aspect 3 — Possible Breakage (additional)
+
+- `add_action` / `add_filter` hook registered at the wrong priority or on the wrong hook — code runs before WordPress is fully loaded or after the targeted data is already rendered; verify hook timing in the WordPress action reference.
+- Plugin/theme adding `admin_enqueue_scripts` without checking `get_current_screen()` — scripts/styles enqueued on every admin page, not just the intended one.
+- Direct database write bypassing WordPress APIs (raw `INSERT` into `wp_posts`) — skips post meta, cache invalidation, and hooks; use `wp_insert_post()` / `wp_update_post()`.
+- Options or transients stored with `autoload = yes` for large datasets — bloats every page load's initial DB query; use `autoload = no` or custom tables for large data.
+
+---
+
+## Aspect 7 — Security (additional)
+
+- Missing nonce verification on form submissions or AJAX handlers — CSRF. Add `wp_nonce_field()` in forms and `check_ajax_referer()` / `wp_verify_nonce()` in handlers.
+- Missing capability check before privileged operations — `current_user_can('manage_options')` or the appropriate capability must be verified; absence allows privilege escalation.
+- `echo $_POST['field']` or `echo get_query_var('x')` without escaping — XSS. Use `esc_html()`, `esc_attr()`, `esc_url()`, `wp_kses()` as appropriate.
+- `$wpdb->prepare()` used with `%s` for table/column names — `prepare()` only escapes values, not identifiers; validate table/column names against an explicit allowlist.
+- File upload without MIME type validation via `wp_check_filetype_and_ext()` — allows uploading unexpected file types; use WordPress upload APIs which apply type checking.
+- `add_shortcode` rendering user-submitted content without `wp_kses()` — stored XSS via shortcode attributes.
+
+---
+
+## Aspect 10 — Code Quality (additional)
+
+- Hardcoded database table prefix `wp_` instead of `$wpdb->prefix` — breaks multi-site installs and custom-prefix installations.
+- Direct file path construction without `plugin_dir_path()` / `get_template_directory()` — breaks on non-standard WordPress setups.
+- `echo` inside a function intended as a filter callback — filters should `return` the modified value, not echo it; echoed output appears before page headers.
+
+---
+
+## Aspect 12 — Architecture & Design (additional)
+
+- Business logic in `functions.php` directly — for plugins and large themes, organize code into classes or separate includes; `functions.php` should only bootstrap hooks.
+- Calling `the_post()` or `setup_postdata()` outside of a loop context — corrupts global post state.
+- `wp_remote_get()` / `wp_remote_post()` called synchronously on page load for a third-party service — blocks page rendering if the remote service is slow or down; run via a scheduled event (`wp_cron`) or queue asynchronously.

package/resources/skills/hd-daily-goals/SKILL.md

@@ -16,6 +16,18 @@ Verify flow: `verify` arg → skip all phases → batch validate pasted reports
 
 ---
 
+## Startup: Ticket Pattern Bootstrap
+
+> Run silently before every session. No user interaction.
+
+1. Read `reference/ticket-autofill.md` to load the algorithm spec into context.
+2. Read `~/.hd/config.yaml` if it exists → load all `ticket_patterns` entries into `$URL_PATTERN[PREFIX]`.
+3. Scan last 5 files in `~/.hd/daily-goals/` and `~/.hd/daily-reports/` (whichever exist):
+   - Extract any full ticket URLs using the regex from the spec
+   - For each found prefix: if `$URL_PATTERN[PREFIX]` is not already set, add it (bootstrap only — config is authoritative and must not be overwritten by history)
+
+---
+
 ## Pre-Check: Verify Mode
 
 If first arg is `verify`: load `reference/verify-mode.md` and follow it entirely. Skip all phases below.
@@ -76,6 +88,11 @@ Any format is fine.
 
 Accept any format (prose, bullets, partial markdown, or mix).
 
+**Task link detection:** As the user enters goals, scan for ticket references using the algorithm in `reference/ticket-autofill.md`:
+- Full URL with ticket ID → extract base pattern → store `$URL_PATTERN[PREFIX]`; overwrite if a different URL is seen for the same prefix (correction)
+- Bare ID `PREFIX-NNNN` + `$URL_PATTERN[PREFIX]` known → silently expand to `[PREFIX-NNNN](url)` in the internal goal representation
+- Bare ID `PREFIX-NNNN` + no known pattern → add to `$PENDING_LINKS` for Phase 4 enforcement; do not interrupt Phase 1
+
 ---
 
 ## Phase 2: Parse & Preview
@@ -221,6 +238,19 @@ If any issues remain: present the remaining issue list again and repeat.
 - A value is provided
 - A written "why" explanation is provided after "don't know"
 
+### Task link enforcement
+
+After the main validation issues are processed, check `$PENDING_LINKS` for any goals with flagged bare IDs that still have no known pattern.
+
+For each such goal, add a `→ Link:` line to its batch prompt (batched with any remaining validation issues for that goal, not a separate turn):
+
+```
+→ Link: ? (paste the task URL — or type "none" if no tracker)
+```
+
+- URL provided → extract pattern per `reference/ticket-autofill.md`; silently expand all remaining goals with the same prefix; remove from `$PENDING_LINKS`; do not ask again for this prefix this session
+- `none` / `no tracker` → render the ID as plain text (no link); mark prefix as no-tracker in session; remove from `$PENDING_LINKS`; do not ask again for this prefix this session
+
 ### Mid-loop free chat
 
 If the user's response looks like a content edit rather than answering a validation question (e.g., "actually remove that goal", "change the hours to 4h"), apply the change immediately. Re-scan affected goals, update the issue list, then continue the loop.
@@ -244,17 +274,19 @@ After each edit, re-show the updated report. Loop until [Y].
 
 ## Phase 7: Output
 
-Before outputting, silently apply: normalize date to `YYYY-MM-DD`; ensure each goal starts with `- To` (capital T); embed "don't know" reasons as `(Note: ...)` at end of goal line; append ` ⭐` at the end of the line that matches `$PRIORITY_GOAL`.
-
+Before outputting, silently apply: normalize date to `YYYY-MM-DD`; ensure each goal starts with `- To` (capital T); embed "don't know" reasons as `(Note: ...)` at end of goal line; append ` ⭐` at the end of the line that matches `$PRIORITY_GOAL`; add `📋` emoji to the `##` header; compute total hours (sum of all project sections) and project count, then prepend a snapshot blockquote `> [N]h across [P] projects · Priority: [priority goal text ~60 chars]` — omit the `· Priority:` part if no `$PRIORITY_GOAL` was set, trim to ~60 chars with `…` if longer; use `### 🗂️ Name · Nh` for project headers (replacing `### Project: Name, Nh`); add one blank line between project sections (after each section's last goal, before the next `###`); for any `(Note: ...)` in a goal line — identify the key 1–4 word phrase (the blocker, dependency, person, or constraint) and bold **only that phrase** — if the note value is ≤4 words total, bold the whole value. Example: `(Note: Wait for Ricky's feedback)` → `(Note: **Wait for Ricky's** feedback)`.
 
 Output the final report in a copyable markdown block:
 
 ````markdown
-## $DATE | $NAME | goals
-### Project: [Name], [N]h
+## 📋 $DATE | $NAME | goals
+
+> [N]h across [P] projects · Priority: [priority goal text, ~60 chars]
+### 🗂️ [Name] · [N]h
 - To [goal 1]
 - To [goal 2]
-### Project: [Name], [N]h
+
+### 🗂️ [Name] · [N]h
 - To [goal 1]
 ````
 
@@ -267,11 +299,11 @@ Then add the send reminder:
 • If you post to multiple channels (you are following multiple projects and multiple leaders): send the same copy to each — do not split
 ```
 
-Then ask:
+Write the file to `~/.hd/daily-goals/$DATE.md` automatically, then confirm:
 
 ```
-Save a copy to history/$DATE-daily-goals/report.md? [Y/N]
+✅ Saved: ~/.hd/daily-goals/$DATE.md
 ```
 
-- [Y] → write the file and confirm: `✅ Saved: history/$DATE-daily-goals/report.md`
-- [N] → end session
+**Config flush:**
+After saving, compare session `$URL_PATTERN` against what was loaded at startup. For any prefix where the pattern is new or changed: merge into `~/.hd/config.yaml` under `ticket_patterns` (create the file if it doesn't exist; preserve all existing entries for other prefixes). Show `✅ Config updated: ~/.hd/config.yaml (+N pattern(s))` only when something was actually written. If nothing changed: silent.

package/resources/skills/hd-daily-goals/reference/ticket-autofill.md

@@ -0,0 +1,104 @@
+# Ticket Auto-Fill — Algorithm Spec
+
+Reference document loaded by hd-daily-goals, hd-daily-report, and hd-daily-viewer.
+
+---
+
+## 1. Pattern Detection Algorithm
+
+**Regex:**
+```
+https?://[^\s]+?/([A-Z]+-\d+)(/[^\s]*)?
+                  ↑ ticket ID   ↑ optional trailing slug — discard
+```
+
+**Rule:** Find the ticket ID anywhere in the URL path. Everything after the ticket ID segment is discarded (slugs, hash fragments, query params that follow the ID segment).
+
+```
+base_url = url up to end of ticket ID segment
+           with ticket ID replaced by {id}
+```
+
+**Worked examples:**
+
+| Input URL | Extracted base |
+|-----------|---------------|
+| `https://jira.company.com/browse/XOM-334` | `https://jira.company.com/browse/XOM-{id}` |
+| `https://linear.app/myteam/issue/XOM-334/implement-login-flow` | `https://linear.app/myteam/issue/XOM-{id}` |
+| `https://app.clickup.com/t/TIK-446` | `https://app.clickup.com/t/TIK-{id}` |
+
+The ticket prefix is the uppercase part before the dash: `XOM` from `XOM-334`.
+
+---
+
+## 2. Auto-Expansion
+
+When a bare ticket ID `PREFIX-NNNN` is encountered and `$URL_PATTERN[PREFIX]` is known:
+
+```
+[PREFIX-NNNN](base_url.replace("{id}", "PREFIX-NNNN"))
+```
+
+Example: `XOM-4423` + base `https://linear.app/myteam/issue/XOM-{id}`
+→ `[XOM-4423](https://linear.app/myteam/issue/XOM-4423)`
+
+This expansion happens silently — no user prompt.
+
+---
+
+## 3. Config Format
+
+File: `~/.hd/config.yaml`
+
+```yaml
+ticket_patterns:
+  XOM: https://linear.app/myteam/issue/XOM-{id}
+  BUG: https://jira.mycompany.com/browse/BUG-{id}
+  TIK: https://app.clickup.com/t/TIK-{id}
+```
+
+One entry per ticket prefix. The `{id}` placeholder receives the full `PREFIX-NNNN` string.
+
+---
+
+## 4. Session Lifecycle
+
+### Startup (before any user interaction)
+
+1. Read `~/.hd/config.yaml` if it exists → load all `ticket_patterns` entries into `$URL_PATTERN[PREFIX]`
+2. Scan last 5 files in `~/.hd/daily-goals/` and `~/.hd/daily-reports/` (whichever directories exist):
+   - For each file, extract any full ticket URLs using the regex
+   - For each found prefix: if `$URL_PATTERN[PREFIX]` is NOT already set, add it (bootstrap only — config is authoritative and must not be overwritten by history)
+
+### During Session
+
+- Full URL with ticket ID entered → extract prefix + base → store in `$URL_PATTERN[PREFIX]`
+- Correction: new full URL for same prefix → overwrite `$URL_PATTERN[PREFIX]` in session memory
+- Bare ID `PREFIX-NNNN` seen → check `$URL_PATTERN[PREFIX]` → auto-expand if known; flag for Phase 4 prompt if not known
+
+### End of Session (after output file written)
+
+1. Compare current `$URL_PATTERN` against what was loaded at startup
+2. For any prefix where the pattern is new or changed:
+   - Merge into `~/.hd/config.yaml` under `ticket_patterns`
+   - If config file did not exist: create it
+   - Preserve all existing entries for other prefixes (merge, not overwrite)
+3. Show `✅ Config updated: ~/.hd/config.yaml (+N pattern(s))` — only when something changed
+4. If no patterns changed: silent (no confirmation line)
+
+---
+
+## 5. Opt-Out Rule
+
+If the user types `none` or `no tracker` when asked for a link:
+
+- Mark `$URL_PATTERN[PREFIX] = "no-tracker"` in session memory
+- Render the ticket ID as plain text (no link)
+- Do not ask again for that prefix this session
+- **Do NOT write "no-tracker" to config** — opt-out is session-scoped only
+
+---
+
+## 6. Already-Linked IDs
+
+If a ticket ID is already a full markdown link `[PREFIX-NNNN](url)` in the source text, leave it as-is. Do not re-expand or modify it.

package/resources/skills/hd-daily-goals/reference/validation-rules.md

@@ -81,6 +81,19 @@ Warn once per goal. If the user adds an outcome in their answer, accept it.
 
 ---
 
+## Global Task Field: Link
+
+Every goal containing a bare ticket ID (`PREFIX-NNNN`) requires a task URL, with two exceptions:
+- Pattern already known (from `~/.hd/config.yaml` or earlier in this session) → auto-expanded silently, no prompt
+- User answered `none` / `no tracker` for this prefix → rendered as plain text, no prompt
+
+Enforcement rules:
+- Ask once per prefix per session (not once per goal)
+- Once a URL is provided for a prefix, all remaining goals with that prefix auto-expand immediately
+- Opt-out (`none`) is session-scoped only — never written to `~/.hd/config.yaml`
+
+---
+
 ## Global Rules
 
 No silent skip — every blank requires a value or written explanation. `skip`, `idk`, `N/A` alone → re-prompt.

package/resources/skills/hd-daily-report/SKILL.md

@@ -11,9 +11,24 @@ metadata:
 
 > **[LANGUAGE]** Fully language-adaptive. Detect language from Phase 1 free-text. All prompts, validation messages, section headers, and the report mirror it. Keep the emoji; translate only the label text (e.g. `✅ WHAT'S DONE` → `✅ ĐÃ LÀM XONG`, `🔄 IN PROGRESS` → `🔄 ĐANG LÀM`, `🚀 WHAT'S NEXT` → `🚀 TIẾP THEO`, `⚠️ ISSUES & BLOCKERS` → `⚠️ VẤN ĐỀ & BLOCKER`, `📅 TIME ALLOCATION` → `📅 PHÂN BỔ THỜI GIAN`). Do not translate task content.
 
-See `reference/sample-report.md` for a complete example.
+See `reference/sample-report.md` for a complete Dev schema example.
+See `reference/sample-report-qc.md` for a complete QC schema example.
 See `reference/validation-rules.md` for field-level enforcement rules.
 
+## Startup: Ticket Pattern Bootstrap
+
+> Run silently before Phase 0. No user interaction.
+
+1. Read `~/.hd/config.yaml` if it exists → load all `ticket_patterns` into `$URL_PATTERN[PREFIX]`.
+   Config format: `ticket_patterns: { PREFIX: "https://...PREFIX-{id}" }`
+2. Scan last 5 files in `~/.hd/daily-goals/` and `~/.hd/daily-reports/` (whichever exist):
+   - Extract full ticket URLs using regex `https?://[^\s]+?/([A-Z]+-\d+)(/[^\s]*)?`
+   - For each found prefix: if `$URL_PATTERN[PREFIX]` not already set, add it (bootstrap only — config is authoritative)
+
+If `~/.hd/config.yaml` is absent: proceed normally. The existing Phase 1 detection and Phase 3 enforcement handle everything in-session.
+
+---
+
 ## Pipeline
 
 ```
@@ -50,6 +65,12 @@ Accept any input format without asking the user to choose a mode (prose, bullets
 
 **Auto-detect draft mode:** If input contains `### ✅` or `### 🔄` or other report section headers, treat as an existing draft — skip to Phase 3 after preview.
 
+**Role detection:** After parsing Phase 1 input, silently detect reporter role from content signals. Store as `$ROLE` (default: `dev`).
+- QC signals: "test", "tested", "test case", "BUG-", "passed", "failed", "regression", "verified fix", "re-test", "test plan", "QC", "QA"
+- Dev signals: "PR", "merged", "commit", "deployed", "implemented", "refactored", "hotfix"
+- QC signals detected → `$ROLE = qc` → confirm before Phase 2: `Detected role: QC — applying QC report schema. (Wrong? Type "dev" to switch.)`
+- Dev signals or ambiguous → `$ROLE = dev` → proceed silently, no prompt.
+
 **Multi-project attribution:** If $PROJECTS > 1, infer each task's project from context (task ID prefixes, project names inline, natural grouping). If ambiguous, ask: "Which project does [TASK] belong to?" before parsing.
 
 **Task link detection:** Parse task references in any form: full URL, markdown link `[TASK-123](url)`, or bare ID (`TASK-123`, `123`). When the first full URL is seen for a project, extract the base pattern and store as `$URL_PATTERN[project]`. Auto-infer links for all subsequent tasks in that project — do not ask again. If no URL is known for a project yet, flag missing links internally and ask during Phase 3 as part of the per-task batch prompt.
@@ -80,6 +101,8 @@ Here's what I understood. Does this look right?
 [Y] Looks right, continue  [E] Edit something
 ```
 
+Empty sections in the preview render as `*(no entries detected — you'll be asked about this)*` instead of `- None`. (`- None` is only written after the user explicitly confirms a section is empty in Phase 3.)
+
 **[E] mode:** User types freely — "remove TASK-3", "move TASK-5 to done", "add a blocker". Apply the change and re-show. Loop until [Y].
 
 ---
@@ -92,16 +115,17 @@ Scan every item against `reference/validation-rules.md`.
 
 ### Missing fields overview
 
-Before the first prompt for each project, scan all 4 sections and show a compact summary:
+Before the first prompt for each project, scan all 4 sections and show a compact summary. Field labels adapt to `$ROLE`:
 
 ```
 🔍 Reviewing your report — found X missing fields:
 
-✅ WHAT'S DONE:  [HDKIT-101] — Note ❓
-🔄 IN PROGRESS:  [HDKIT-104] — Completion % ❓, Understanding % ❓, When complete ❓
-                 [HDKIT-105] — Understanding % ❓, When complete ❓
+✅ WHAT'S DONE:  [HDKIT-101] — Delivered ❓, Note ❓          ← dev schema
+                 [HDKIT-201] — Result ❓, Bugs ❓             ← qc schema
+🔄 IN PROGRESS:  [HDKIT-104] — Next ❓, Completion % ❓, Understanding % ❓, When complete ❓
+                 [HDKIT-105] — Next ❓, Understanding % ❓, When complete ❓
 🚀 WHAT'S NEXT:  (nothing missing)
-⚠️ ISSUES:       Issue 1 — Severity ❓, Blocked by ❓, Status ❓, Note ❓
+⚠️ ISSUES:       Issue 1 — Severity ❓, Blocking ❓, Workaround ❓, Status ❓, Note ❓
 
 💡 You can fill in multiple items at once — paste answers for several tasks in one reply and I'll process them all.
 
@@ -114,11 +138,30 @@ Let's go through them. Starting with the first:
 
 ### Batch prompts — one task at a time
 
-Group all missing fields for one task into a single prompt. Never ask field-by-field for the same task.
+Group all missing fields for one task into a single prompt. Never ask field-by-field for the same task. Field set adapts to `$ROLE`.
+
+**WHAT'S DONE — dev example:**
+```
+[HDKIT-101] (DONE) — a few things missing:
+→ Delivered: ? (e.g. PR merged, PR opened, deployed to staging, awaiting review)
+→ Note: ? (what should your leader know?)
+
+💡 To go faster: see the overview above and answer multiple items in one reply.
+```
+
+**WHAT'S DONE — QC example:**
+```
+[HDKIT-201] (DONE) — a few things missing:
+→ Result: ? (e.g. 23 passed / 2 failed)
+→ Bugs: ? (bug IDs found, or "none found")
+
+💡 To go faster: see the overview above and answer multiple items in one reply.
+```
 
 **In-progress task example:**
 ```
-[HDKIT-4] (IN PROGRESS) — a few things missing:
+[HDKIT-104] (IN PROGRESS) — a few things missing:
+→ Next: ? (what's the concrete next step?)
 → Completion %: ?
 → Understanding %: ?
 → When complete (due): ?
@@ -131,6 +174,8 @@ Group all missing fields for one task into a single prompt. Never ask field-by-f
 [Issue 1] "API Key invalid" — a few things missing:
 → Severity: [see numbered choices below]
 → Blocked by: ? (task ID, dependency, external party, or "None")
+→ Blocking: ? (which tasks or features does this affect?)
+→ Workaround: ? (temporary fix in place, or "none")
 → Reported: Yes or No?
 → Status: [see numbered choices below]
 → Note: ? (what should your leader know?)
@@ -212,7 +257,12 @@ All 5 sections must appear. Empty = `- None`. Before confirming, ask a reflectio
 | ⚠️ ISSUES | "No issues? Think through anything slowing you down, waiting on others, or that could block you tomorrow." |
 | 📅 TIME ALLOCATION | "No time allocated today? Confirm with [Y] or add entries." |
 
-`[Y]` → write `- None` and continue. `[N]` → "What would you like to add?" → free chat → re-validate section.
+Show the prompt as:
+```
+[Y] Confirm empty  [N] Add something
+💡 To save time, enter free text with all missing points you can remember — I'll parse them all at once.
+```
+`[Y]` → write `- None` and continue. `[N]` → accept free-text entry → parse all items → re-validate section.
 
 ### Time allocation sanity check
 
@@ -254,7 +304,13 @@ Show the complete report. Each project block: sections 1–4 + TIME ALLOCATION (
 
 ## Phase 5: Output
 
-Output each project as a self-contained 5-section markdown block. **No blank lines anywhere inside a block** — not between `## title` and first `###`, not after any `###` heading, not between last item of a section and the next `###`. Separate multiple blocks with the bold divider (not raw `---`). Every block — including the first — is preceded by the bold divider. TIME ALLOCATION in every block shows all projects' time entries — not just the current project's.
+Output each project as a self-contained 5-section markdown block. **No blank lines anywhere inside a block** — not between `## title` and `>` snapshot, not between `>` snapshot and first `###`, not after any `###` heading, not between last item of a section and the next `###`. Separate multiple blocks with the bold divider (not raw `---`). Every block — including the first — is preceded by the bold divider. TIME ALLOCATION in every block shows all projects' time entries — not just the current project's.
+
+**Snapshot line** — immediately after `## title`, insert one `>` line (no emoji, no blank lines around it):
+`> [N] done · [N] in-progress · [N] blocker(s) ([X] open) · [Nh]`
+Counts: done = non-None items in ✅; in-progress = non-None items in 🔄; blockers = non-None items in ⚠️, open count = those with Status: open or in discussion; Nh = total hours from TIME ALLOCATION.
+
+**Semantic emphasis** — at output time, for every `📝` note line in WHAT'S DONE, IN PROGRESS, and ISSUES & BLOCKERS: identify the key 1–4 word phrase (the blocker, dependency, person, risk, or constraint) and bold only that phrase. If the note value is ≤4 words total, bold the whole value. The `📝` label is never bolded — only the value. Example: `📝 Wait for Ricky's feedback` → `📝 **Wait for Ricky's** feedback`.
 
 **Send reminder** — show this after each project block:
 
@@ -269,6 +325,7 @@ Format:
 
 ````markdown
 ## {DATE} {NAME} daily report on {PROJECT_1}
+> [N] done · [N] in-progress · [N] blocker(s) ([X] open) · [Nh]
 ### ✅ WHAT'S DONE
 ...
 ### 🔄 IN PROGRESS
@@ -294,11 +351,10 @@ Format:
 
 [Send reminder]
 
-Then ask:
+Write the file to `~/.hd/daily-reports/{DATE}.md` automatically, then confirm:
 
 ```
-Save a copy to history/{DATE}-daily-report/report.md? [Y/N]
+✅ Saved: ~/.hd/daily-reports/{DATE}.md
 ```
 
-- [Y] → write file, confirm: `✅ Saved: history/{DATE}-daily-report/report.md`
-- [N] → end session
+**Config flush:** Compare session `$URL_PATTERN` against what was loaded at startup. For any prefix where the pattern is new or changed: merge into `~/.hd/config.yaml` under `ticket_patterns` (create the file if it doesn't exist; preserve all existing entries for other prefixes). Show `✅ Config updated: ~/.hd/config.yaml (+N pattern(s))` only when something was actually written. If nothing changed: silent.

package/resources/skills/hd-daily-report/reference/sample-report-qc.md

@@ -0,0 +1,44 @@
+# Sample Daily Report — QC Schema
+
+> Reference: A complete, well-filled example of `hd-daily-report` output (QC schema).
+> All 5 sections are present. All required fields are filled.
+
+---
+
+## 2026-02-28 Anna Nguyen daily report on HDKit
+> 2 done · 1 in-progress · 1 blocker(s) (1 open) · 8h
+### ✅ WHAT'S DONE
+- [HDKIT-201](https://linear.app/hd/issue/HDKIT-201): Test login flow regression suite
+	→ Result: 23 passed / 2 failed
+	→ Bugs: BUG-45, BUG-46
+	→ Scope: Login, session expiry, OAuth redirect
+	- Reviewed: No ⏳
+	- Note: 📝 Two edge cases failed on **OAuth redirect with expired token**.
+- [HDKIT-202](https://linear.app/hd/issue/HDKIT-202): Re-test BUG-43 (fixed by HDKIT-198)
+	→ Result: 1 passed / 0 failed
+	→ Bugs: BUG-43 verified ✔️
+	- Reviewed: Yes ✔️
+	- Note: 📝 **Fix confirmed** on staging. Safe to close.
+	→ Action needed: please close BUG-43 in the tracker
+### 🔄 IN PROGRESS
+- [HDKIT-203](https://linear.app/hd/issue/HDKIT-203): Test checkout flow — payment edge cases (40%)
+	- 🤔 Understanding: 90%
+	- 🎯 When complete (due): tomorrow EOD
+	→ Next: cover failed-payment and timeout scenarios
+	→ Environment: staging missing test card data for Stripe sandbox
+### 🚀 WHAT'S NEXT
+- [HDKIT-204](https://linear.app/hd/issue/HDKIT-204): Write test cases for new notification module (🎯 goal: 80%)
+- [HDKIT-205](https://linear.app/hd/issue/HDKIT-205): Regression sweep on user profile page (🎯 goal: 100%, due: March 2nd)
+### ⚠️ ISSUES & BLOCKERS
+- Issue 1: (severity: blocker) Stripe test card data missing from staging environment
+	- Blocked by: DevOps — staging not seeded with Stripe sandbox credentials
+	- Reported: Yes
+	- Reported at: https://discord.com/channels/hd/devops/9876543210
+	- References:
+		- None
+	→ Blocking: HDKIT-203 payment edge case tests fully blocked
+	→ Workaround: none — cannot simulate payment failures without test cards
+	- Status: open
+	- Note: 📝 Reported this morning, **no response yet**. Checkout tests cannot complete until resolved.
+### 📅 TIME ALLOCATION
+- 🕔 8h on HDKit

package/resources/skills/hd-daily-report/reference/sample-report.md

@@ -1,31 +1,35 @@
 # Sample Daily Report
 
-> Reference: A complete, well-filled example of `hd-daily-report` output.
+> Reference: A complete, well-filled example of `hd-daily-report` output (Dev schema).
 > All 5 sections are present. All required fields are filled.
+> For a QC schema example, see `sample-report-qc.md`.
 
 ---
 
 ## 2026-02-28 John Smith daily report on HDKit
+> 3 done · 2 in-progress · 2 blocker(s) (1 open) · 8h
 ### ✅ WHAT'S DONE
 - [HDKIT-101](https://linear.app/hd/issue/HDKIT-101): Implement daily report skill SKILL.md
-	- Completed: Yes ✔️
+	→ Delivered: PR #203 opened, awaiting review
 	- Reviewed: No ⏳
-	- Note: 📝 Draft complete, waiting for team review before merge.
+	- Note: 📝 Draft complete, **waiting for team review** before merge.
 - [HDKIT-102](https://linear.app/hd/issue/HDKIT-102): Write sample report and validation rules reference
-	- Completed: Yes ✔️
+	→ Delivered: merged to main
 	- Reviewed: Yes ✔️
-	- Note: 📝 Fully complete, merged to main.
+	- Note: 📝 **Fully complete**.
 - [HDKIT-103](https://linear.app/hd/issue/HDKIT-103): Fix typo in AGENTS.md introduction paragraph
-	- Completed: Yes ✔️
+	→ Delivered: merged to main
 	- Reviewed: Yes ✔️
-	- Note: 📝 100% done, trivial fix.
+	- Note: 📝 **Trivial fix**, took 10 minutes.
 ### 🔄 IN PROGRESS
 - [HDKIT-104](https://linear.app/hd/issue/HDKIT-104): Add hd-daily-report to hd-help skill map (60%)
 	- 🤔 Understanding: 100%
 	- 🎯 When complete (due): may complete tomorrow
+	→ Next: write the invocation examples section
 - [HDKIT-105](https://linear.app/hd/issue/HDKIT-105): Write integration tests for Phase 3 validation loop (30%)
 	- 🤔 Understanding: 80%
 	- 🎯 When complete (due): unclear — need to clarify test scope with tech lead first
+	→ Next: schedule sync with tech lead to define test scope
 ### 🚀 WHAT'S NEXT
 - [HDKIT-106](https://linear.app/hd/issue/HDKIT-106): Review PR for authentication module (🎯 goal: 100%, due: March 1st)
 - [HDKIT-107](https://linear.app/hd/issue/HDKIT-107): Start planning for hd-standup skill (🎯 goal: 50%)
@@ -37,21 +41,20 @@
 	- References:
 		- Slack thread: https://hdwebsoft.slack.com/archives/C123/p456
 		- Provisioning guide: https://wiki.hdwebsoft.com/devops/staging-credentials
+	→ Blocking: HDKIT-105 fully blocked
+	→ Workaround: none — cannot test without credentials
 	- Status: in discussion
-	- Note: 📝 Reported yesterday, no response yet. HDKIT-105 is fully blocked until credentials arrive. Need leadership to escalate if no update by EOD tomorrow.
+	- Note: 📝 Reported yesterday, **no response yet**. Need leadership to escalate if no update by EOD tomorrow.
 - Issue 2: (severity: normal) Validation loop skips empty WHAT'S NEXT section without asking
-	- Blocked by: HDKIT-105 (integration test suite not yet set up, so hard to reproduce reliably)
+	- Blocked by: HDKIT-105 (integration test suite not yet set up)
 	- Reported: Yes
 	- Reported at: https://linear.app/hd/issue/HDKIT-109
 	- References:
 		- None
+	→ Blocking: quality gate for skill release
+	→ Workaround: manual check before each output
 	- Status: open
-	- Note: 📝 Reproduced manually. Will fix after HDKIT-105 is unblocked. Not urgent today but risks shipping a broken validation loop.
-- Issue 3: (severity: minor) Sample report date is hardcoded to 2026-02-28
-	- Blocked by: None
-	- Reported: No
-	- Status: open
-	- Note: 📝 Noticed while reviewing reference files. Will update to use a relative date placeholder before the skill ships.
+	- Note: 📝 Reproduced manually. Will fix after **HDKIT-105 is unblocked**.
 ### 📅 TIME ALLOCATION
 - 🕔 6h on HDKit
 - 🕔 2h on Client Alpha project

package/resources/skills/hd-daily-report/reference/validation-rules.md

@@ -21,25 +21,44 @@ Applies to ALL task items across all sections (✅ WHAT'S DONE, 🔄 IN PROGRESS
 
 ## ✅ WHAT'S DONE
 
-Each task item must have ALL of:
+Field set depends on `$ROLE`. Both schemas share `Reviewed` and `Note`.
 
-| Field | Required | Enforcement | Format |
-|-------|----------|-------------|--------|
-| `Completed` | Yes | Re-prompt if missing | `Yes ✔️` or `No ⏳` or `No` |
-| `Reviewed` | Yes | Re-prompt if missing | `Yes ✔️` or `No ⏳` or `No` |
+### Dev schema ($ROLE = dev)
+
+| Field | Required | Enforcement | Format / Examples |
+|-------|----------|-------------|-------------------|
+| `→ Delivered:` | Yes | Re-prompt if missing | `PR merged`, `PR #42 opened`, `deployed to staging`, `awaiting review` |
+| `Reviewed` | Yes | Re-prompt if missing | `Yes ✔️` / `No ⏳` / or free text (e.g. `pending PR review`, `shared with lead`, `approved by manager`) |
 | `Note` | Yes | Re-prompt if blank | Free text with context |
+| `→ Action needed:` | Conditional | Omit if not applicable — no enforcement | `please review PR before EOD`, `escalate with client` |
+
+### QC schema ($ROLE = qc)
+
+| Field | Required | Enforcement | Format / Examples |
+|-------|----------|-------------|-------------------|
+| `→ Result:` | Yes | Re-prompt if missing | `23 passed / 2 failed`, `all passed` |
+| `→ Bugs:` | Yes | Re-prompt if missing | Bug IDs e.g. `BUG-45, BUG-46`; or `none found` |
+| `→ Scope:` | Optional | No enforcement | Test area — omit if self-evident from task title |
+| `Reviewed` | Yes | Re-prompt if missing | `Yes ✔️` / `No ⏳` / or free text (e.g. `test log shared with lead`, `pending QA sign-off`) |
+| `Note` | Yes | Re-prompt if blank | Free text with context |
+| `→ Action needed:` | Conditional | Omit if not applicable — no enforcement | Same as dev |
+
+**Re-test items:** handled inline in `→ Bugs:` — e.g. `BUG-45 verified ✔️ · BUG-46 still failing (re-opened)`
 
 ---
 
 ## 🔄 IN PROGRESS
 
-Each task item must have ALL of:
+Each task item must have ALL of (both roles):
 
 | Field | Required | Enforcement | Format |
 |-------|----------|-------------|--------|
 | Completion % (in title line) | Yes | Strict numeric — re-prompt until valid | `N%` (0–100), e.g. `(60%)` |
 | `Understanding` | Yes | Strict numeric — re-prompt until valid | `🤔 Understanding: N%` |
 | `When complete (due)` | Yes | Explanation allowed — re-prompt if blank | Date, timeframe, or written reason |
+| `→ Next:` | Yes | Re-prompt if blank | Concrete next action — 1 line |
+| `→ Action needed:` | Conditional | Omit if not applicable — no enforcement | Leader action required |
+| `→ Environment:` | QC only, informational | No enforcement | `staging OK` / `missing test data` / `build not deployed yet` |
 
 ### % format rules
 - Valid: `80%`, `100%`, `0%`
@@ -67,7 +86,7 @@ Each task item must have:
 
 ## ⚠️ ISSUES & BLOCKERS
 
-Each issue must have ALL of:
+Each issue must have ALL of (both roles):
 
 | Field | Required | Condition | Enforcement | Format |
 |-------|----------|-----------|-------------|--------|
@@ -76,6 +95,8 @@ Each issue must have ALL of:
 | `Reported` | Yes | Always | Re-prompt if missing | `Yes` / `No` |
 | `Reported at` | Yes | Only if `Reported: Yes` | Re-prompt if missing | URL / platform name |
 | `Status` | Yes | Always | Present as numbered choice [1]/[2]/[3]; re-show list if invalid | `open` / `in discussion` / `solved` |
+| `→ Blocking:` | Yes | Always | Re-prompt if missing; `N/A` alone not accepted | Task IDs, feature name, module — e.g. `HDKIT-105 fully blocked` |
+| `→ Workaround:` | Yes | Always | Re-prompt if missing | Mitigation in place, or `none` |
 | `Note` | Yes | Always | Re-prompt if blank or trivial | Free text with real context |
 | `References` | No | Optional | — | Link list |