@rudinmax87/united-we-stand 0.1.0

package/.united-we-stand/spec-driven/branch-template/ux/screen-states.md

@@ -0,0 +1,3 @@
+# UX Screen States
+
+Document loading, empty, error, success, and permission states where relevant.

package/.united-we-stand/spec-driven/branch-template/ux/user-flows.md

@@ -0,0 +1,3 @@
+# UX User Flows
+
+Document impacted user journeys, success paths, and unhappy paths.

package/.united-we-stand/steering/00-index.md

@@ -0,0 +1,15 @@
+# Steering Index
+
+This directory contains repo-specific steering.
+
+Read order:
+1. `product-steering.md`
+2. `architecture-steering.md`
+3. `coding-steering.md`
+4. `testing-steering.md`
+5. `security-steering.md`
+6. `observability-steering.md`
+7. `documentation-steering.md`
+8. `repo-conventions.md`
+
+Read `ux-steering.md` or `data-steering.md` when relevant.

package/.united-we-stand/steering/architecture-steering.md

@@ -0,0 +1,13 @@
+# Architecture Steering
+
+Use this file to encode durable architectural preferences.
+
+## Suggested Sections
+
+- System boundaries
+- Preferred patterns
+- Disallowed couplings
+- State ownership
+- Integration boundaries
+- Scalability constraints
+- Migration constraints

package/.united-we-stand/steering/coding-steering.md

@@ -0,0 +1,77 @@
+# Coding Steering
+
+This file defines repo-specific coding conventions that `4-implementer` must
+follow for every code change and `5-code-reviewer` must enforce during review.
+When this file is more specific than a profile doc, this file wins.
+
+## Formatting and consistency
+
+- Follow Airbnb JS/TS style guidance unless a stricter repo rule in this file overrides it.
+- Keep code consistently formatted with configured formatter/linter rules when present.
+- Order imports consistently.
+- Prefer clarity over cleverness.
+- Small, composable functions are mandatory.
+- Keep modules cohesive so each file has one main responsibility.
+- Use `const` by default; use `let` only when reassignment is required; avoid `var`.
+- Avoid deep nesting by using early returns, guard clauses, and small helpers.
+- Do not leave oversized functions in place when they can be split into smaller helpers with clearer responsibilities.
+- If a function starts mixing responsibilities, repeated condition branches, or long sequential logic, split it before considering the implementation complete.
+
+## Naming conventions
+
+- Use explicit, intent-revealing names instead of abbreviations.
+- Function and method names must describe what they do using `verb + object` naming where practical, such as `createAppointmentSlots`, `validateBookingRequest`, or `loadAvailableDays`.
+- Avoid vague names such as `doThing`, `handle`, `process`, `run`, `q`, or `fn1` for core logic.
+- Do not use single-letter identifiers, including in loops, callbacks, and temporary variables.
+- Prefer descriptive iteration and callback names such as `index`, `dayIndex`, `slotIndex`, `hourIndex`, `day`, `hour`, `appointment`, `user`, `request`, `error`, `event`, `response`, or `document`.
+- Use `camelCase` for variables and functions.
+- Use `PascalCase` for classes and components.
+- Use `UPPER_SNAKE_CASE` only for values that are truly constant and shared.
+
+## Commenting and documentation preferences
+
+- Commenting requirements in this section are mandatory for `4-implementer` and must be enforced by `5-code-reviewer`.
+- Every function and method must have a short JSDoc-style doc comment immediately above it.
+- Keep function and method doc comments to one brief sentence describing behavior.
+- Every changed code file must contain at least one intent-focused code comment.
+- If a file contains only one small function, that file still must include at least one short comment explaining what the function does.
+- Add `//` inline comments before each non-trivial block to explain intent, boundary handling, or reasoning.
+- When a block is small but important, still add a short comment if it clarifies why the code exists.
+- Do not comment obvious code paths line by line; comment intent, boundaries, and why the block exists.
+
+## Error-handling preferences
+
+- Handle errors intentionally and do not swallow exceptions.
+- Prefer predictable control flow and avoid hidden side effects.
+
+## Shared utilities rules
+
+- If logic is needed in more than one place, extract it into a shared function or module.
+- Prefer `utils/` for general-purpose helpers.
+- Prefer `lib/` for domain-specific shared logic.
+- Add at least minimal tests for shared utilities.
+
+## Dependency policy
+
+- Keep dependencies minimal and justify every new package.
+- Prefer built-in platform APIs before adding third-party dependencies when they are sufficient.
+- Prefer popular, maintained libraries with active releases and a solid security posture when a dependency is necessary.
+- Do not add deprecated or unmaintained packages when a maintained alternative exists.
+- Do not add packages with known active vulnerabilities.
+- Maintain the appropriate lockfile for the package manager in use.
+- Before merging a dependency change in npm-based repositories, run `npm audit` and address reported vulnerabilities by updating, replacing, or removing the dependency.
+
+## SonarQube-aligned quality rules
+
+- Follow common SonarQube-style clean code guidance as mandatory review criteria.
+- Avoid large functions. If a function grows beyond a small, easy-to-scan unit or starts carrying multiple responsibilities, split it into helpers before calling the work done.
+- Use strict equality (`===`, `!==`) instead of loose equality except for intentional safe nullish checks.
+- Do not import a module into itself.
+- Avoid absolute import paths unless repo conventions explicitly require alias-based imports.
+- Use `Number.isNaN()` for `NaN` checks.
+- Prefer spread syntax over redundant `.apply()` usage.
+- Prefer object spread syntax over `Object.assign()` when it is appropriate and equivalent.
+- Keep function and method names compliant with the naming rules in this file.
+- Remove unused variables, unused assignments, and dead code.
+- Avoid duplicated logic.
+- Avoid code shapes that would predictably trigger routine SonarQube-style maintainability findings when a straightforward cleanup is available.

package/.united-we-stand/steering/data-steering.md

@@ -0,0 +1,31 @@
+# Data Steering
+
+Use this file when the repo owns schemas, migrations, analytics, or data pipelines.
+
+## Schema and Diagram Expectations
+
+- For SQL database work, capture both conceptual and implementation-level structure.
+- Each process that interacts with the database should have:
+  - a flowchart
+  - a sequence diagram
+  - an entity-relationship model (`modelo de entidad relacion`)
+  - a relational model (`modelo relacional`)
+
+## SQL File Organization
+
+- Keep SQL commands in correctly named files separated by purpose, such as create, alter/update, seed, policy/RLS, rollback, or backfill work.
+- SQL files should have clear file-level comments stating purpose, scope, and execution intent.
+- If a `supabase/` directory exists, keep SQL migration files inside `supabase/migrations/`.
+- If SQL files already exist outside `supabase/migrations/` in a repo that uses Supabase, move or rewrite them into `supabase/migrations/` unless the user explicitly requests otherwise.
+- Use names that make the function obvious, for example timestamped migration files with purpose suffixes such as `create_users_table`, `update_booking_indexes`, or `rls_appointments_policies`.
+
+## Migration Rules
+
+- Separate schema creation, data correction, and security-policy work when that separation improves reviewability.
+- Comment non-trivial SQL blocks to explain intent, assumptions, and ordering constraints.
+- Prefer idempotent or explicitly guarded operations when the platform/workflow expects rerunnable scripts.
+
+## Data Safety Expectations
+
+- Make ownership, access control, and retention implications explicit for schema changes.
+- Document compatibility or rollout concerns when migrations affect live data or existing consumers.

package/.united-we-stand/steering/documentation-steering.md

@@ -0,0 +1,11 @@
+# Documentation Steering
+
+Use this file to define documentation expectations.
+
+## Suggested Sections
+
+- What changes require docs updates
+- README expectations
+- API docs expectations
+- Migration notes
+- Runbook / handoff expectations

package/.united-we-stand/steering/observability-steering.md

@@ -0,0 +1,11 @@
+# Observability Steering
+
+Use this file to define logging, metrics, tracing, and alerting expectations.
+
+## Suggested Sections
+
+- What must be logged
+- Structured logging requirements
+- Performance metrics
+- Tracing expectations
+- Error visibility requirements

package/.united-we-stand/steering/product-steering.md

@@ -0,0 +1,16 @@
+# Product Steering
+
+Use this file to encode durable product direction for the repo.
+
+## Suggested Sections
+
+- Primary users
+- Main outcomes
+- Priority tradeoffs
+- Non-goals
+- Constraints
+- Release posture
+
+## Template
+
+Fill this file with repo-specific information. If not yet defined, say `Not yet defined`.

package/.united-we-stand/steering/repo-conventions.md

@@ -0,0 +1,12 @@
+# Repo Conventions
+
+Use this file to describe practical repository conventions.
+
+## Suggested Sections
+
+- Directory layout
+- Naming rules
+- Test placement
+- Common commands
+- Build/release notes
+- Documentation placement

package/.united-we-stand/steering/security-steering.md

@@ -0,0 +1,12 @@
+# Security Steering
+
+Use this file to define repo-specific security expectations.
+
+## Suggested Sections
+
+- Secret handling
+- AuthN/AuthZ requirements
+- Input validation boundaries
+- Data exposure rules
+- Dependency security expectations
+- Audit / compliance notes

package/.united-we-stand/steering/testing-steering.md

@@ -0,0 +1,11 @@
+# Testing Steering
+
+Use this file to define what testing matters most in this repo.
+
+## Suggested Sections
+
+- Test pyramid priorities
+- Required regression coverage
+- Contract/integration expectations
+- Mocking boundaries
+- Acceptance criteria style

package/.united-we-stand/steering/ux-steering.md

@@ -0,0 +1,26 @@
+# UX Steering
+
+Use this file when the repo has user-facing interface work.
+
+## Layout and Visual Direction
+
+- Match the visual direction to the requested audience and tone.
+- For formal sites, prefer restrained layouts, calmer palettes, strong hierarchy, and conservative contrast usage.
+- For attention-grabbing or promotional sites, use bolder visual rhythm, stronger color accents, and more expressive composition while preserving usability.
+- For children-focused experiences, prefer friendly shapes, high clarity, playful palettes, and obvious interaction affordances without sacrificing accessibility.
+
+## Color and Contrast
+
+- Define a deliberate color palette instead of drifting into default UI colors.
+- Keep contrast strong enough for readability across primary text, controls, and states.
+- Use accent colors intentionally and consistently across calls to action, highlights, and status cues.
+
+## Accessibility Expectations
+
+- Preserve readable typography, usable focus states, and semantic structure.
+- Ensure layout, color, and motion choices do not reduce comprehension or navigation clarity.
+
+## Error and Empty States
+
+- UI states should be visually coherent with the selected visual direction.
+- Empty, loading, and error states should remain readable and intentional rather than generic placeholders.

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.