diff --git a/GEMINI.md b/GEMINI.md index 0b98afb..a5aad19 100644 --- a/GEMINI.md +++ b/GEMINI.md @@ -43,6 +43,7 @@ This is a non-negotiable security requirement. - **Hypothesize and Verify:** Treat fixes as hypotheses and verify them with tests. - **Consult Docs Before Guessing:** When an error occurs, consult official documentation first. - **Keep Architecture Document Updated:** After implementing a new feature, update `docs/ARCHITECTURE.md` to reflect the changes. +- **Do Not Start Servers:** Never start servers, whether through `docker compose up` or `iex -S mix phx.server`. ### Iterative Refinement - When we are working on a document or a piece of code, do not reprint the entire file after every change. Acknowledge that you have understood the change, and wait for me to ask before you display the full content. @@ -75,4 +76,4 @@ This is a non-negotiable security requirement. - **Debug the App, Not the Test:** Analyze the stack trace to find the root cause in the application code. - **Testing LiveView Navigation:** Use the `follow_redirect(conn)` helper to test `push_navigate` or `push_redirect`. - **Testing Stateless Components:** Use `render_component/2` for stateless functional components. -- **Testing with Scope:** Use the `log_in_user/2` helper in tests to set up the `current_scope`. +- **Testing with Scope:** Use the `log_in_user/2` helper in tests to set up the `current_scope`. \ No newline at end of file diff --git a/assets/css/app.css b/assets/css/app.css index 5608797..1238b0d 100644 --- a/assets/css/app.css +++ b/assets/css/app.css @@ -102,6 +102,22 @@ /* This file is for your main application CSS */ +@utility z-base { + z-index: 10; +} +@utility z-popover { + z-index: 20; +} +@utility z-sticky { + z-index: 30; +} +@utility z-drawer { + z-index: 40; +} +@utility z-modal { + z-index: 50; +} + @utility main-margins { @apply max-w-2xl mx-auto; } diff --git a/docs/ARCHITECTURE.md b/docs/ARCHITECTURE.md index 34b44a0..d88e602 100644 --- a/docs/ARCHITECTURE.md +++ b/docs/ARCHITECTURE.md @@ -58,3 +58,23 @@ The business logic in `lib/cms` is organized into "contexts." Each context is a * **Purpose:** Manages the church's library of worship songs. * **Associated Schemas:** * `CMS.Songs.Song`: Represents a single song, including its title, lyrics, author, and other metadata. + +## Frontend Conventions + +### Z-Index Scale + +To ensure a consistent and predictable stacking order for UI elements, we use a semantic z-index scale. Instead of using arbitrary numeric values, you **must** use the following Tailwind CSS utility classes: + +* `z-base`: For elements that need a base stacking context. (z-index: 10) +* `z-popover`: For popovers and dropdowns. (z-index: 20) +* `z-sticky`: For sticky elements like navbars. (z-index: 30) +* `z-drawer`: For drawers and sidebars. (z-index: 40) +* `z-modal`: For modals and overlays that must appear on top of all other content. (z-index: 50) + +**Example:** + +```html +
+ +
+``` diff --git a/docs/sub_issue_template.md b/docs/sub_issue_template.md new file mode 100644 index 0000000..983b36c --- /dev/null +++ b/docs/sub_issue_template.md @@ -0,0 +1,58 @@ +# Sub-Issue Template (Vertical Slice) + +Each sub-issue you create **must** follow this format. This template is designed to describe a "vertical slice" of functionality, from the user interface down to the database. + +--- + +**Title:** A clear, user-centric summary of the feature slice. +* *Example:* "User can submit the new prayer request form and see a success message." + +**Goal:** Briefly explain the "why" of this specific task and what new capability it delivers to the user. +* *Example:* "This task connects the UI form to the backend, allowing users to save their prayer requests for the first time. It provides the core 'happy path' functionality." + +**Affected Components:** List the primary files/modules involved in this slice. +* *Example:* + * **LiveView:** `lib/cms_web/live/prayer_request_live/new.ex` + * **Context:** `lib/cms/prayers.ex` + * **Schema:** `lib/cms/prayers/prayer_request.ex` + +**Implementation Steps:** Describe the sequence of changes needed to implement the slice. +* *Example:* + 1. In `prayers.ex`, create a new function `create_prayer_request(attrs)` that takes valid attributes and saves a new `PrayerRequest` to the database. + 2. In the `new.ex` LiveView, implement a `handle_event` for the "save" event from the form. + 3. This event handler should call the new `create_prayer_request` context function. + 4. On successful creation, redirect the user to the prayer request index page and display a "Prayer Request created!" flash message. + +**How to Verify:** Provide simple, end-to-end steps to confirm the slice is working correctly. +* *Example:* + 1. Navigate to the `/prayer-requests/new` page. + 2. Fill out the form fields and click "Save". + 3. Confirm that the page redirects to the index page. + 4. Confirm that a success message is displayed. + 5. (Optional) Check the database to ensure the new record was saved correctly. + +**BDD Scenario:** This scenario describes the required user-facing behavior. It is written in Gherkin syntax for clarity and communication, not because the project uses a Gherkin-based tool. The developer should implement this scenario as a standard feature test using the project's existing testing framework (e.g., ExUnit). +* *Example:* + ```gherkin + Scenario: User successfully submits a new prayer request + Given I am on the new prayer request page + When I fill in "Title" with "Healing for Sarah" + And I fill in "Details" with "Please pray for my friend Sarah's recovery." + And I click the "Save" button + Then I should be on the prayer requests page + And I should see a flash message saying "Prayer Request created!" + ``` + +**Unit Tests:** In addition to the BDD scenario, add lower-level tests for the core business logic to ensure correctness and enable faster debugging. +* *Example:* + * **File:** `test/cms/prayers_test.exs` + * **Function:** `create_prayer_request/1` + * **Scenarios to test:** + * Returns `{:ok, %PrayerRequest{}}` with valid attributes. + * Returns `{:error, %Ecto.Changeset{}}` when the title is missing. + * Correctly sets the `organization_id` on the new prayer request. + +**Definition of Done:** +* All implementation steps are complete. +* All verification steps pass. +* The changes are committed with a clear and descriptive message that closes this issue (e.g., `Closes #`). \ No newline at end of file diff --git a/lib/cms_web/components/bottom_dock.ex b/lib/cms_web/components/bottom_dock.ex index 09824e3..3ddb1c8 100644 --- a/lib/cms_web/components/bottom_dock.ex +++ b/lib/cms_web/components/bottom_dock.ex @@ -9,7 +9,7 @@ defmodule CMSWeb.BottomDock do def bottom_dock(assigns) do ~H""" -
+
<.link navigate={~p"/liturgies/latest"} class="dock-item"> <.icon name="hero-book-open-solid" class="w-5 h-5" /> {gettext("Liturgy")} diff --git a/lib/cms_web/components/core_components.ex b/lib/cms_web/components/core_components.ex index a9d952e..fc3bf99 100644 --- a/lib/cms_web/components/core_components.ex +++ b/lib/cms_web/components/core_components.ex @@ -66,7 +66,7 @@ defmodule CMSWeb.CoreComponents do phx-hook="Flash" data-timeout={@timeout} role="alert" - class="toast toast-bottom toast-center z-50" + class="toast toast-bottom toast-center z-modal" {@rest} >
<.bottom_dock current_scope={@current_scope} />
-