Initial commit: Tagesbyte prototype
Flutter app that collects daily tech news from German and English RSS/Atom feeds, with a reader view, AI article summaries and daily briefings (Claude API or n8n webhook), paywall/sponsored filtering and ad/consent blocking. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
CedricandClaude Opus 5.5 committed
commit
f12fb1dabb
159 files changed
+8738
No files matched your search
@@ -0,0 +1,51 @@
|
||||
# Domain Docs
|
||||
|
||||
How the engineering skills should consume this repo's domain documentation when exploring the codebase.
|
||||
|
||||
## Before exploring, read these
|
||||
|
||||
- **`GLOSSARY.md`** at the repo root, or
|
||||
- **`GLOSSARY-MAP.md`** at the repo root if it exists: it points at one `GLOSSARY.md` per context. Read each one relevant to the topic.
|
||||
- **`docs/adr/`**: read ADRs that touch the area you're about to work in. In multi-context repos, also check `src/<context>/docs/adr/` for context-scoped decisions.
|
||||
|
||||
If any of these files don't exist, **proceed silently**. Don't flag their absence; don't suggest creating them upfront. The `/domain-modeling` skill (reached via `/grill-with-docs` and `/improve-codebase-architecture`) creates them lazily when terms or decisions actually get resolved.
|
||||
|
||||
## File structure
|
||||
|
||||
Single-context repo (most repos):
|
||||
|
||||
```
|
||||
/
|
||||
├── GLOSSARY.md
|
||||
├── docs/adr/
|
||||
│ ├── 0001-event-sourced-orders.md
|
||||
│ └── 0002-postgres-for-write-model.md
|
||||
└── src/
|
||||
```
|
||||
|
||||
Multi-context repo (presence of `GLOSSARY-MAP.md` at the root):
|
||||
|
||||
```
|
||||
/
|
||||
├── GLOSSARY-MAP.md
|
||||
├── docs/adr/ ← system-wide decisions
|
||||
└── src/
|
||||
├── ordering/
|
||||
│ ├── GLOSSARY.md
|
||||
│ └── docs/adr/ ← context-specific decisions
|
||||
└── billing/
|
||||
├── GLOSSARY.md
|
||||
└── docs/adr/
|
||||
```
|
||||
|
||||
## Use the glossary's vocabulary
|
||||
|
||||
When your output names a domain concept (in an issue title, a refactor proposal, a hypothesis, a test name), use the term as defined in `GLOSSARY.md`. Don't drift to synonyms the glossary explicitly avoids.
|
||||
|
||||
If the concept you need isn't in the glossary yet, that's a signal: either you're inventing language the project doesn't use (reconsider) or there's a real gap (note it for `/domain-modeling`).
|
||||
|
||||
## Flag ADR conflicts
|
||||
|
||||
If your output contradicts an existing ADR, surface it explicitly rather than silently overriding:
|
||||
|
||||
> _Contradicts ADR-0007 (event-sourced orders), but worth reopening because…_
|
||||
@@ -0,0 +1,40 @@
|
||||
# Issue tracker: Gitea
|
||||
|
||||
Issues and specs for this repo live as issues on the self-hosted Gitea instance at https://tea.zendric.de, repo `Cedric/TagesByte`. Use the `tea` CLI for all operations.
|
||||
|
||||
`tea` infers the repo from the `origin` remote (`ssh://git@tea.zendric.de:2223/Cedric/TagesByte.git`). If inference fails, add `--repo Cedric/TagesByte`.
|
||||
|
||||
## Conventions
|
||||
|
||||
- **Create an issue**: `tea issues create --title "..." --description "..."`. For multi-line bodies, pipe a heredoc into `--description-file -`.
|
||||
- **Read an issue**: `tea api repos/{owner}/{repo}/issues/<n>` for the issue as JSON, and `tea api repos/{owner}/{repo}/issues/<n>/comments` for its comments.
|
||||
- **List issues**: `tea issues list --state open --fields index,title,body,labels -o json`, with `--labels "..."` / `--state` filters as needed.
|
||||
- **Make an issue a child of a parent**: Gitea has no sub-issues. Put `Part of #<parent>` at the top of the child body, and add `- [ ] #<child>` to a task list in the parent body.
|
||||
- **Comment on an issue**: `tea comment <n> "..."`
|
||||
- **Apply / remove labels**: `tea issues edit <n> --add-labels "..."` / `--remove-labels "..."`
|
||||
- **Close**: `tea comment <n> "..."`, then `tea issues close <n>`.
|
||||
|
||||
## Pull requests as a triage surface
|
||||
|
||||
**PRs as a request surface: no.** _(Set to `yes` if this repo treats external PRs as feature requests; `/triage` reads this flag.)_
|
||||
|
||||
When set to `yes`, PRs run through the same labels and states as issues, using `tea pulls` (`tea pulls list`, `tea pulls <n>`) and `tea api repos/{owner}/{repo}/pulls/<n>.diff` for the diff. Gitea shares one number space across issues and PRs.
|
||||
|
||||
## When a skill says "publish to the issue tracker"
|
||||
|
||||
Create a Gitea issue.
|
||||
|
||||
## When a skill says "fetch the relevant ticket"
|
||||
|
||||
Read it as in **Read an issue** above.
|
||||
|
||||
## Wayfinding operations
|
||||
|
||||
Used by `/wayfinder`. The **map** is a single issue with **child** issues as tickets.
|
||||
|
||||
- **Map**: a single issue labelled `wayfinder:map`, holding the Notes / Decisions-so-far / Fog body. `tea issues create --labels wayfinder:map ...`.
|
||||
- **Child ticket**: linked to the map as in **Make an issue a child of a parent**. Labels: `wayfinder:<type>` (`research`/`prototype`/`grilling`/`task`). Once claimed, the ticket is assigned to the driving dev.
|
||||
- **Blocking**: Gitea's native issue dependencies. Add an edge with `tea api -X POST repos/{owner}/{repo}/issues/<child>/dependencies -F index=<blocker> -f owner=Cedric -f repo=TagesByte`. List a ticket's blockers with `tea api repos/{owner}/{repo}/issues/<child>/dependencies`. A ticket is unblocked when every blocker is closed.
|
||||
- **Frontier query**: list the map's open children (from its task list), drop any with an open blocker or an assignee; first in map order wins.
|
||||
- **Claim**: `tea issues edit <n> --add-assignees Cedric`, the session's first write.
|
||||
- **Resolve**: `tea comment <n> "<answer>"`, then `tea issues close <n>`, then append a context pointer (gist + link) to the map's Decisions-so-far.
|
||||
@@ -0,0 +1,15 @@
|
||||
# Triage Labels
|
||||
|
||||
The skills speak in terms of five canonical triage roles. This file maps those roles to the actual label strings used in this repo's issue tracker.
|
||||
|
||||
| Label in mattpocock/skills | Label in our tracker | Meaning |
|
||||
| -------------------------- | -------------------- | ---------------------------------------- |
|
||||
| `needs-triage` | `needs-triage` | Maintainer needs to evaluate this issue |
|
||||
| `needs-info` | `needs-info` | Waiting on reporter for more information |
|
||||
| `ready-for-agent` | `ready-for-agent` | Fully specified, ready for an AFK agent |
|
||||
| `ready-for-human` | `ready-for-human` | Requires human implementation |
|
||||
| `wontfix` | `wontfix` | Will not be actioned |
|
||||
|
||||
When a skill mentions a role (e.g. "apply the AFK-ready triage label"), use the corresponding label string from this table.
|
||||
|
||||
Edit the "Label in our tracker" column to match whatever vocabulary you actually use.
|
||||
Reference in new issue
Block a user