mirror of
https://github.com/PerpetualSoftware/pad.git
synced 2026-09-11 21:39:01 +00:00
xarmian
b891ba84a4
* feat(templates): ship hiring template (TASK-614) First non-software template under PLAN-609. Proves the machinery built by TASK-610 through TASK-613 end-to-end: category grouping, per-template trigger vocabularies, template-owned starter packs, domain-specific seed items. Collections ----------- - Requisitions (REQ) — open roles, with status/team/level/location - Candidates (CAND) — applicants, parent-linked to a Requisition - Interview Loops (LOOP) — interview rounds, parent-linked to a Candidate - Feedback (FB) — per-interviewer debriefs, parent-linked to a Loop - Docs — rubrics, process notes - Conventions + Playbooks — using hiring trigger vocabulary Trigger vocabularies -------------------- - HiringConventionTriggers: always, on-candidate-advance, on-loop-scheduled, on-feedback-submitted, on-offer-extended, on-close-requisition - HiringPlaybookTriggers: on-candidate-advance, on-interview-scheduled, on-feedback-submitted, on-close-requisition, manual - HiringConventionScopes / HiringPlaybookScopes: all, sourcing, screening, interviewing, offers Starter pack ------------ - Conventions (3): PII handling (must/always), requisition linking (should/always), 24h debriefs (should/on-feedback-submitted) - Playbooks (2): "Advance a Candidate" (on-candidate-advance), "Hiring Workspace Onboarding" (manual) - Seed items: one example Requisition, one example Candidate (both labeled as seeded so users can delete or overwrite) Tests ----- - TestHiringTemplate — collections present, trigger vocabulary uses hiring values and does not leak software triggers (on-commit etc.) - TestSeedCollectionsFromTemplateHiring — end-to-end: seeding creates all seven collections plus populates the starter pack Parent: PLAN-609. * fix(web): display hiring triggers on conventions + playbooks pages Per Codex review P1 on PR #146. The conventions page hardcoded a software-only TRIGGERS list in its grouping loop, silently hiding any convention whose trigger wasn't in that list — so a hiring workspace's seeded conventions (on-candidate-advance etc.) never appeared in the primary management UI. Same issue on the playbooks page's filter dropdown. - conventions page: grouping now iterates the union of the hardcoded TRIGGERS (in original order) plus any triggers discovered in the data (sorted alphabetically). Unknown triggers fall back to a generic bell icon + the raw trigger string via a triggerMeta helper. byTrigger is now SvelteMap<string, Item[]>; the narrow Trigger type still gates the create form. - playbooks page: the filter dropdowns for trigger and scope now expose the union of the hardcoded list and any distinct values found on loaded playbooks. Create form still uses the narrow list. The broader "derive options from collection schema so the CREATE forms also follow the workspace's trigger vocabulary" is tracked as IDEA-619 for a follow-up PR. * fix(templates): ship explicit prefixes for hiring collections Per Codex P2 on PR #146. The seeded candidate's content referenced --parent REQ-1, but the default DerivePrefix turns "Requisitions" into "REQUI" (strips trailing S, caps at 5), so the example wouldn't resolve. Similar problems for Candidates (CANDI) and Feedback (FEEDB). - Add optional Prefix string field to DefaultCollection so templates can override the derived prefix. Empty (the default) preserves today's auto-derivation for every existing template. - Thread DefaultCollection.Prefix through SeedCollectionsFromTemplate to the CollectionCreate call — the CreateCollection API already supported a Prefix field. - Hiring template sets explicit prefixes: Requisitions → REQ, Candidates → CAND, Interview Loops → LOOP, Feedback → FB. The seeded onboarding text's --parent REQ-1 reference now resolves. - Test asserts the expected prefixes land on the created collections. * fix: add 'offers' to hiring playbook scopes + tolerate custom scopes in web UI Per Codex review iteration 3 on PR #146. - HiringPlaybookScopes now includes 'offers', matching HiringConventionScopes. The hiring pipeline has a distinct offer stage and playbook workflows tied to offer management were previously uncovered in the schema. - web/conventions page: the scope filter dropdown now exposes the union of SURFACES (original order) plus any scopes discovered on loaded conventions, via a new allSurfaces $derived. Same pattern as the earlier triggers fix. Non-software scopes (sourcing, screening, interviewing, offers) now show up for hiring workspaces instead of being hidden by the narrow hardcoded list. The conventions create form still uses the hardcoded SURFACES — that broader "derive from collection schema" fix is tracked as IDEA-619. * fix(templates): hiring Feedback BoardGroupBy uses submitted, not recommendation Per Codex review iteration 4 on PR #146. Feedback items have two select fields: recommendation (strong-hire/hire/mixed/no-hire/ strong-no, no terminal values) and submitted (pending/submitted, terminal=submitted). The done-state pipeline prefers settings.board_group_by when it's a select field, so grouping on recommendation made terminal detection fall back to checking recommendation against default done-statuses — never matching, leaving submitted feedback perpetually 'active' in active-count views. Group on submitted so completion actually registers. * fix(templates): Advance-a-Candidate playbook uses valid Feedback fields Per Codex review iteration 5 on PR #146. The seeded playbook told agents to create Feedback items with recommendation=pending, but recommendation's allowed values are only the concrete verdicts (strong-hire, hire, mixed, no-hire, strong-no) — 'pending' would be rejected at field validation. Updated the step to use submitted=pending (which IS in the allowed options) and call out that recommendation should stay blank until the interviewer actually records a verdict.
Pad Web UI
SvelteKit 2 + Svelte 5 frontend for Pad, compiled to static files and embedded into the Go binary.
Development
npm install
npm run dev # Dev server at localhost:5173 (proxies API to localhost:7777)
npm run build # Production build to build/
npm run check # Type checking with svelte-check
When developing, run the Go backend separately with make dev from the project root.
Building for Production
Do not build in isolation. Always use make build from the project root — this builds the web frontend, then compiles the Go binary with the build output embedded via //go:embed.
Stack
- Svelte 5 with runes (
$state,$derived,$effect) - SvelteKit 2 with
adapter-static(SPA mode) - Tiptap block editor with markdown round-trip
- svelte-dnd-action for drag-and-drop in board/list views
- SSE for real-time updates
- TypeScript throughout
Structure
src/
routes/ SvelteKit pages
+layout.svelte App shell (sidebar + main)
+page.svelte Landing/redirect
[workspace]/
+page.svelte Dashboard (collections, phases, activity)
+layout.svelte SSE connection per workspace
[collection]/
+page.svelte Collection view (board/list)
[collection]/[item]/
+page.svelte Item detail + editor
conventions/ Purpose-built conventions page
playbooks/ Purpose-built playbooks page
settings/ Workspace settings
lib/
api/client.ts HTTP API client
components/
layout/ Sidebar, navigation
editor/ Tiptap editor, raw markdown editor
fields/ FieldEditor, relation picker
items/ ItemCard, ItemDetail
collections/ BoardView, ListView
common/ StatusBadge, badges, modals
search/ CommandPalette
activity/ ActivityFeed
stores/ Svelte 5 reactive stores
workspace.svelte.ts Workspace state
collections.svelte.ts Collection + item state
ui.svelte.ts Sidebar, mobile state
types/index.ts TypeScript types and constants
app.css Global styles and design tokens