mirror of
https://github.com/pewdiepie-archdaemon/odysseus.git
synced 2026-11-10 07:02:20 +01:00
The handbook says substantial features need Product Owner approval before implementation, but not how a proposal gets there, what counts as substantial, or what happens when no answer comes. Add the full workflow: triage within 7 days, a decision brief, four product labels, a lazy-consensus timeout that only applies to big-but-reversible work, and definitions for every judgement call (small, big, reversible, new direction, fits ROADMAP, objection, recorded decision). The Feature Request form gets three optional fields for the brief, and the PR template, CONTRIBUTING and triage point at the workflow.
66 lines
3.4 KiB
Markdown
66 lines
3.4 KiB
Markdown
## Summary
|
|
|
|
<!-- One paragraph: what changed and why. "Fixed bug" and "Added feature" are not summaries. -->
|
|
|
|
## Target branch
|
|
|
|
- [ ] This PR targets the correct integration branch: **`lab`** in the private maintainer-preview repository, or **`dev`** in the public repository. `main` remains release-curated.
|
|
|
|
## Linked Issue
|
|
|
|
<!-- Public-repository PRs must link an issue:
|
|
Fixes #NNN | Part of #NNN | Closes #NNN
|
|
|
|
Private maintainer-preview PRs may instead use:
|
|
N/A — maintainer integration work
|
|
|
|
New features: the linked issue carries `product: approved` or
|
|
`product: maintainer decision` (docs/maintainers/product-and-features.md).
|
|
-->
|
|
|
|
Fixes #
|
|
|
|
## Type of Change
|
|
|
|
- [ ] Bug fix (non-breaking — fixes a confirmed issue)
|
|
- [ ] New feature (non-breaking — adds new behaviour)
|
|
- [ ] Breaking change (changes or removes existing behaviour)
|
|
- [ ] Refactor / cleanup (behaviour unchanged)
|
|
- [ ] Documentation only
|
|
- [ ] CI / tooling / configuration
|
|
|
|
## Checklist
|
|
|
|
- [ ] I searched [open issues](https://github.com/odysseus-dev/odysseus/issues) and [open PRs](https://github.com/odysseus-dev/odysseus/pulls) — this is not a duplicate.
|
|
- [ ] This PR targets the correct integration branch (`lab` in maintainer-preview; `dev` in the public repository)
|
|
- [ ] My changes are limited to the scope described above — no unrelated refactors or whitespace changes mixed in.
|
|
- [ ] I actually ran the app (`docker compose up` or `uvicorn app:app`) and verified the change works end-to-end. Type-checks and unit tests are not enough.
|
|
- [ ] I did not run the app/runtime validation and stated that gap in **How to Test**. Leave this unchecked when the app-run box above is checked.
|
|
|
|
## How to Test
|
|
|
|
<!-- Step-by-step instructions a reviewer can follow to verify this works.
|
|
Do not leave this empty — a PR without test steps will be sent back. -->
|
|
|
|
1.
|
|
2.
|
|
3.
|
|
|
|
## Visual / UI changes — REQUIRED if you touched anything that renders
|
|
|
|
**Anything that changes what the UI looks like — buttons, icons, padding, colors, fonts, spacing, layout, CSS, HTML, SVG, or any `static/js/` module that draws to the DOM — needs all of the following. PRs that change rendering without these WILL be closed.**
|
|
|
|
- [ ] **Screenshot or short clip** of the change in the running app, attached below. Mobile screenshot too if the change affects mobile.
|
|
- [ ] **Style match**: the change uses Odysseus's existing visual language. Specifically:
|
|
- Reuse existing CSS variables (`--red`, `--fg`, `--bg`, `--card`, `--border`, etc.) — do not introduce new color values, font sizes, or spacing units.
|
|
- Reuse existing button/input/card/border classes. Don't invent parallel styling.
|
|
- **No Unicode emoji in UI or code.** Use inline SVG (matching the monochrome icon style already in `static/index.html`) or plain text.
|
|
- Monospaced font (`Fira Code`) for primary UI text. Don't override.
|
|
- Dark theme is the default; any light-mode work must be wired through the existing theme system, not hard-coded.
|
|
- [ ] **No new component patterns.** If a similar widget already exists in the app, extend it instead of writing a parallel one.
|
|
- [ ] **I am not an LLM agent submitting a bulk PR.** If you are, please open an issue describing the problem first — bulk auto-generated PRs that don't match the project's visual style are closed on sight, even when the underlying fix is correct.
|
|
|
|
### Screenshots / clips
|
|
|
|
<!-- Drag and drop images or a screen recording here. Required for any UI/visual change. -->
|