API Reference PhoenixKitProjects v#0.21.1

Projects module for PhoenixKit.

PhoenixKitAI.Translatable adapter for projects resources — the small per-module hook into PhoenixKitAI's generic AI-translation pipeline.

PhoenixKitAI.Components.AITranslate.FormBinding for projects forms — the storage-specific half of the shared AI-translate glue.

Activity logging wrapper for the Projects module.

Creation starting points — the outcome-oriented cards on the New project page (the 2026-08-06 five-AI brainstorm's strongest consensus: one transparent choice that BUNDLES a feature preset + extension seeds, replacing the bare preset select as the page's primary control).

The single resolver for "whose work is this?" questions against the polymorphic assignment assignee (person OR team OR department).

Folder-scoped file attachments for a project, backed by core PhoenixKit.Modules.Storage — the workspace's per-resource-folder convention (phoenix_kit_staff.Attachments is the reference this mirrors): no module-owned table, no migration.

The hub's authorization vocabulary and single resolver.

Maps projects — and, for the default Tasks mode, their scheduled tasks — to PhoenixLiveCalendar.Event structs for the Overview dashboard calendar.

The dashboard widgets phoenix_kit_projects contributes to phoenix_kit_dashboards.

Atom → translated-string dispatcher for Projects context errors.

Per-project extension enablement — the hub's context layer.

Option resolution for extension config_schema :select fields — shared by the Modules & Features panel and the creation form (extracted from the panel LV when the form grew inline extension config).

A project extension type — the catalog entry describing a capability that can be enabled per project (the hub's equivalent of a site module).

Discovers and caches the project-extension catalog.

Per-project feature flags — Level 2 of the hub's granularity model (Level 1 is extension enablement in PhoenixKitProjects.Extensions).

Global display settings for the projects Gantt/Timeline chart.

Gettext backend for projects-module-specific UI strings.

Indirect project access — a project role held by a staff team, a staff department, or a site role instead of by one named person.

Project health — the hub's native status signal (P2b), Basecamp's "Needle": a MANUAL three-state judgment (on_track / some_risk / concerned) with a note, set by a human — never auto-computed (the research's deliberate-omission lesson: progress math answers "how much", health answers "how do we feel about it").

The ledger→invoice bridge (Phase E, Option B of the panel-settled design): generate a DRAFT invoice in phoenix_kit_billing from this project's uninvoiced billable time.

Tiny locale-aware date/time formatting helpers used by the projects UI.

Per-project labels (Phase C): registry CRUD (managed in the project's Modules panel) + assignment tagging through the V7 join table. Rides the labels feature flag at the CALLER layer, like every context here.

The work ledger (Step 10): unified effort tracking where the actor can be a human or an AI agent and the quantity minutes, tokens, or cents — one table, so "what did this task actually cost" is a single query across people-hours and AI spend.

Per-project membership — the hub's native people layer (P2a).

Module-owned versioned migrations for phoenix_kit_projects.

Centralized path helpers for the Projects module.

The ONE doorway to people/team/department data for this module — the staff-optional seam (Phase B of the hub rework, panel-approved design).

READ-ONLY shadow schema over the core-owned phoenix_kit_staff_departments table (core V100). See PhoenixKitProjects.People.Person for the seam's rules.

READ-ONLY shadow schema over the core-owned phoenix_kit_staff_people table (created by core migration V100 — present on every install, whether or not the phoenix_kit_staff package is). Part of the staff-optional seam (see PhoenixKitProjects.People): projects' own bounded read model of a person, mapping ONLY the columns this module reads. No changesets — people are managed by the staff module's admin; projects never writes these rows.

READ-ONLY shadow schema over the core-owned phoenix_kit_staff_teams table (core V100). See PhoenixKitProjects.People.Person for the seam's rules: minimal columns, no changesets, local struct identity.

READ-ONLY shadow schema over the core-owned phoenix_kit_staff_team_memberships table (core V100). See PhoenixKitProjects.People.Person for the seam's rules.

The public portal (Phase J): anonymous issue submission + a read-only public issue list + a status summary for one project, behind a random capability slug. Security model per the 2026-08-06 design doc + the external security panel's findings, folded in

Makes a PUBLISHED portal issue mentionable — as its public URL.

Project events (Step 12): CRUD for the V6 phoenix_kit_project_events table — the Events extension tab's data layer. Every write logs activity and broadcasts on the project topic; there is no notification fan-out yet (events carry no target_uuid — deciding who an event should notify is a product call for daylight).

Context for projects, tasks, assignments, and dependencies.

Real-time updates for the projects module, backed by PhoenixKit.PubSub.Manager.

Makes projects and their tasks linkable and mentionable from anywhere.

The shared durations→dates schedule walk behind the project show page's Timeline (gantt) and Calendar tabs.

A task instance within a project. Copies description and duration from the task template at creation time — editable independently.

A dependency link: assignment_uuid cannot start until depends_on_uuid is done. Both must be in the same project (enforced at the context layer).

A per-project label (phoenix_kit_project_labels, chain V7): a named, colored tag assignments wear via the phoenix_kit_project_assignment_labels join table (join rows cascade with either side). Names are unique per project; color is a daisyUI badge class from the closed palette.

One row per project with the portal extension enabled (chain V10).

Provenance row for one anonymous portal submission (chain V10) — PII lives HERE and only here, so deleting it erases everything the portal learned about the submitter. v1 collects NO email (the panel's mail-bombing find — the notify-submitter feature waits for a double-opt-in design); the column exists for that v2. ip_hash is a truncated peppered HMAC — abuse telemetry, deliberately not an identifier.

A project container. Can start immediately (set up tasks first, then mark as started) or be scheduled for a future date.

One project event (phoenix_kit_project_events, chain V6): a dated happening that isn't a task — meeting, milestone, review. Stored UTC; all_day events ignore the time-of-day component and render as month bars, timed events as chips with a time prefix. created_by_uuid is FK-less provenance (house convention).

Per-project membership row (phoenix_kit_project_members, chain V3).

Per-project extension enablement row (phoenix_kit_project_modules).

A project's cemented workflow status — a local snapshot of a catalog status row, copied from the phoenix_kit_entities vocabulary when the project starts.

A project role held by a GROUP rather than a person: a staff team, a staff department, or a site role.

Reusable task template with title, description, estimated duration, and optional default assignee.

Default dependency between task templates. When both tasks are added to the same project, the assignment dependency is auto-created.

One project whiteboard (phoenix_kit_project_whiteboards, chain V5): a named drawing surface = one core Storage file (the blank-background bridge — see PhoenixKitProjects.Whiteboards) plus core annotation rows anchored to that file by PhoenixKitWeb.Components.MediaCanvasViewer.

One ledger entry (phoenix_kit_project_work_entries, chain V4): effort spent on a project (optionally a specific assignment) by an ACTOR that can be a human (user / staff_person) or an ai_agent — the boss's unified work ledger. kind fixes the amount's unit

User-defined project workflow statuses, configured through the optional phoenix_kit_entities module and cemented locally when a project starts.

Shared state glue for the calendar assignee/overdue filter — the chip-rail model (person chips via the core search_picker, a Me quick-toggle, an Unassigned lens, Personal-only and Overdue-only refinements, one Clear).

Add a task to a project or edit an existing assignment. Supports picking from library or creating new. Manages assignment dependencies (which tasks in this project must finish first).

Aggregator for the projects module's reusable UI components.

"Who can see this project, and what can they do" — the access controls, in one place, shared by the surfaces that set them.

<.assignee_filter_panel> — the Filters funnel button (badged with the active-filter count) plus its client-side popup panel: person typeahead, Me/Unassigned quick-adders, active chips, Personal-only and Overdue-only refinements, and Clear.

Status presentation for an Assignment.status value ("todo", "in_progress", "done"). Mirrors DerivedStatusBadge but for the assignment lifecycle instead of the project lifecycle.

<.day_popup_modal> — the whole-day popup both calendars share.

Badge that renders a project's Project.derived_status/1 value as a daisyUI badge with the canonical icon + color + gettext'd label.

Section heading + description + action button row used by every admin LV in the projects module (Overview, Projects list, Tasks, Templates, Project show, every form).

Layered daisyUI <dialog> modal stack driven by a modal_stack assign. The function component renders the always-visible content (default slot) plus one <dialog> per stack frame, delegating each frame's body rendering to the :frame slot the host provides.

One project in the dashboard's "Running" section, rendered as a hierarchical summary (V127): a top line with the project name + tier + progress, a one-line summary (N tasks · M sub-projects), a status breakdown (X done · Y in progress · Z todo), and then each embedded sub-project nested underneath as an indented sub-step with its own summary + breakdown — all the way down.

Embed-mode aware link.

Embed-mode aware <li> entry for use inside <.table_row_menu>.

Compact bordered card with a label and a big number. Used in OverviewLive's top stats row (Running / Tasks in progress / Tasks todo / Tasks done) and in the bottom navigation row.

daisyUI tabs tabs-boxed segment switcher driven by the active value + a list of {value, label, icon} tuples. Used in AssignmentFormLive ("From library" / "Create new") and ready for reuse anywhere a small set of mutually-exclusive panes shares a single LV-managed assign.

Status pill rendered next to a project title on the Running dashboard. Encodes the prioritized-tier classification

The shared "Workflow status" form section (V125), reused by every form that edits a project-like record: ProjectFormLive, TemplateFormLive, and AssignmentFormLive's sub-project mode. A sub-project and a template are both projects, so they get the same status-source picker a project has.

Cross-cutting helpers for the projects module's LiveView layer.

Shared plumbing for the admin list pages (Projects / Tasks / Templates): column-visibility persistence, search-param coercion, the client-search haystack builder, and the Columns dropdown component.

The member-facing projects surface — My Projects on the user dashboard (/dashboard/projects), the non-admin doorway into the hub.

Projects module dashboard.

Opinionated wrapper LV that pairs the <.popup_host> function component with the emit-mode PubSub contract.

Privacy headers for the portal, chosen from the portal's access mode.

The public portal page — /portal/:slug, no authentication, no internal API access: everything renders from Portal.public_view/1's whitelisted DTO (panel #5), and the submit path runs the full guard chain inside handle_event (panel #2 — plug-level limits never see LiveView events).

Per-project Activity — the hub's native audit surface (P2b): core's activity log filtered to this project via the resource_uuid filter (PhoenixKit.Activity.list/1), paged with load-more. Read-only; guarded with Code.ensure_loaded? so a stripped Activity module degrades to an empty feed (the hello_world events pattern). Embeddable like every LV here.

Calendar view of a project — the same scheduled data as the Timeline (gantt) tab, rendered as all-day bars on a month grid via the standalone phoenix_live_calendar component instead of bars on a date axis.

The Events extension tab (Step 12): a month calendar of project events (meetings, milestones, reviews) + a server-rendered upcoming list, mounted by the hub via live_render with the extension-tab session contract (no handle_params/3; same trust model as every contributed tab — see ProjectWhiteboardsLive).

Per-project Files — the hub's native attachments surface (P2b), folder-scoped via PhoenixKitProjects.Attachments (core Storage; no module table). Upload/browse rides core's MediaSelectorModal scoped to the project folder; picked/uploaded files link into it, removal follows the sole-home-soft-trash convention.

Create or edit a project.

Gantt / waterfall view of a project — the same data as ProjectShowLive, rendered as horizontal bars on a date axis via the PhoenixLiveGantt component instead of the vertical timeline.

Per-project Members — the hub's native people surface (P2a).

The per-project Modules & Features panel — the hub's control surface.

Show a project with a vertical timeline of assignments. Supports inline status changes, duration editing, dependency management, and tracks who completed each task.

The Whiteboards extension tab (Step 11): board list + canvas, rendered by the projects hub via live_render with the extension-tab session contract (see PhoenixKitHelloWorld.Web.ProjectHelloTabLive for the contract reference). Mounts off-router only; no handle_params/3.

List projects.

Projects module settings (global, under the core Settings area).

Route contributions beyond the admin tabs (which auto-generate from admin_tabs/0 / user_dashboard_tabs/0): the PUBLIC portal surface.

Create or edit a reusable task template, including default dependencies.

List reusable task templates.

Create or edit a project template.

List project templates.

Dashboard widget: the running projects with the NEAREST planned ends — soonest first, overdue flagged — so slipping work surfaces on the dashboard before someone opens the projects page. Data comes from Projects.project_summaries/1 (the same batched math as the overview: weekend-aware planned_end, progress %). Views: detailed (date, progress, late badge) / compact (name + date). Settings: "limit".

Shared helpers + frame for the dashboard widgets phoenix_kit_projects contributes to phoenix_kit_dashboards via phoenix_kit_widgets/0.

Dashboard widget: the CURRENT USER's open assignments across every active project — the personal "what's on my plate" view. Resolves the viewer through the host-provided scope assign → their staff person → Projects.list_assignments_for_user/1 (which degrades gracefully on a Staff outage). Views: detailed (task, project, status, progress) / compact (task + status dot). Settings: "limit".

Dashboard widget: the current ongoing (todo + in-progress) tasks of a project. Views: detailed (task, assignee, status, progress) / compact (task + status dot). Settings: "project" (name / id / substring) and "limit".

Dashboard widget: a single project's schedule/estimate — total estimated hours, progress, planned end, and a live ETA (with an on-track / late cue). Views: detailed / simple. Settings: "project".

Dashboard widget: the status of a single project — lifecycle + workflow status, progress, task counts, and a live ETA. Views: detailed / simple (auto-simple when small). Pick the project via the "project" setting (name / id / substring).

Dashboard widget: every project at a glance, coloured by status. Views: grid (a uniform tile per project, tinted by lifecycle and attention-sorted — overdue first, completed last — with the workflow status as a second line) / counts (a bucket per workflow status with a count). No settings — shows all projects.

Dashboard widget: workspace-wide projects + task workload at a glance — project lifecycle counts (running / overdue / scheduled / completed) and assignment status counts (todo / in progress / done). Views: detailed / simple.

Project whiteboards (Step 11): freeform drawing boards on core's Fresco/Etcher/annotations stack via the blank-background bridge — core's annotation persistence anchors to a phoenix_kit_files row (hard FK), so each board generates a solid-white PNG, registers it as a Storage file in the project's folder, and lets core's MediaCanvasViewer do everything else (drawing, annotation CRUD, palettes). When core grows a file-less canvas the bridge shrinks to a data migration; the board row (name/order/dimensions) is ours either way.