Compare commits

..

4 Commits

Author SHA1 Message Date
danijel.simeunovic 5d866b6348 Merge branch 'main' into feat/subdomain-drop-wildcard-cert
AI Code Review / ai-review (pull_request) Has been skipped
/ test (pull_request) Successful in 33s
2026-06-23 07:18:26 +00:00
Sten fcf187e903 fix(forte-drop): drop apex SAN, use dnsZones in issuer selector
AI Code Review / ai-review (pull_request) Has been skipped
- Apex drop.forteapps.net already gets its own cert from the forteapp
  chart (forte-drop-tls); the SAN on the wildcard cert was redundant.
- cert-manager selector.dnsNames matches exact FQDNs (no wildcard
  expansion), so the enumerated list is replaced by
  dnsZones: [forteapps.net], covering apex + all subdomains.

Refs #22

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-12 09:24:22 +02:00
Sten fcd8f99a52 feat(forte-drop): wildcard IngressRoute for per-slug drop subdomains
AI Code Review / ai-review (pull_request) Has been skipped
No forte-helm chart change needed after all. The forteapp chart emits one exact
Host(`drop.forteapps.net`) route (apex: admin + /api + public /shared). Add an
ADDITIVE standalone IngressRoute for the per-slug wildcard *.drop.forteapps.net,
pointing at the SAME chart service (forte-drop-app:3000 — whose targetPort is the
auth sidecar when auth is on), so forte drop subdomains flow through the sidecar and
are Forte-login gated exactly like the admin root.

priority:1 (LOW) is load-bearing: Traefik orders routers by rule-length by default,
and this regex is longer than Host(`mcp.drop.forteapps.net`) — without the explicit
low priority it would STEAL mcp.drop (and apex) traffic into the web pod. priority:1
guarantees the exact Host() routers (mcp release + chart apex) always win.

Traefik v3 (chart 28.x) HostRegexp = Go RE2; verify the rendered router against
mcp./www./app./apex/<real-slug> before prod. Uses the wildcard-drop-forteapps-net-tls
secret from the Certificate added in the same branch.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-10 09:53:10 +02:00
Sten 44ae8e0da6 feat(forte-drop): wildcard cert *.drop.forteapps.net for subdomain-per-drop
forte_drop is moving to per-slug subdomains: forte-login drops served at
<slug>.drop.forteapps.net (sidecar-gated), public/password drops at
drop.forteapps.net/shared/<slug>. That needs a wildcard TLS cert.

- letsencrypt-issuer.yaml: add '*.drop.forteapps.net' + 'drop.forteapps.net' to
  the dns01 azureDNS solver selector in BOTH issuers. The existing '*.forteapps.net'
  selector only matches single-label children, so it does NOT cover the two-label
  '*.drop.forteapps.net' — without this the wildcard challenge has no matching solver
  and issuance fails. SP already has zone-level rights on forteapps.net.
- new Certificate wildcard-drop-forteapps-net in the forte-drop namespace -> secret
  wildcard-drop-forteapps-net-tls (dnsNames *.drop + apex). Issued in-namespace so the
  app's Traefik IngressRoute can reference it directly (the secret-cloner can't help:
  generateExisting:false + forte-drop ns already exists). Added to the overlay
  kustomization so ArgoCD manages it (the Application is prune+selfHeal).

This is the SINGLE issuer of that secret. The forte-helm chart must reference it
verbatim and must NOT create its own Certificate into the same secret.

Depends on: DNS *.drop.forteapps.net resolving + ACME TXT in the flat forteapps.net
zone (no delegated drop. child zone). Do NOT merge until that's confirmed.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-09 16:49:15 +02:00
11 changed files with 80 additions and 103 deletions
+1 -4
View File
@@ -23,7 +23,7 @@ jobs:
REVIEW__INLINE_COMMENT_FALLBACK: "false"
# LLM configuration
LLM__PROVIDER: CLAUDE
LLM__META__MODEL: claude-3-opus
LLM__META__MODEL: claude-sonnet-4-20250514
LLM__META__MAX_TOKENS: "4096"
LLM__HTTP_CLIENT__API_URL: https://api.anthropic.com
LLM__HTTP_CLIENT__API_TOKEN: ${{ secrets.ANTHROPIC_API_KEY }}
@@ -36,9 +36,6 @@ jobs:
fetch-depth: 0
token: ${{ secrets.AI_REVIEW_TOKEN }}
- name: Update submodules to remote
run: git submodule update --remote --merge
- name: Run inline review
uses: docker://nikitafilonov/ai-review:v0.64.0
with:
-2
View File
@@ -1,5 +1,3 @@
[submodule "shared-prompts"]
path = shared-prompts
url = https://git.forteapps.net/Forte/ai-review-prompts.git
branch = main
@@ -0,0 +1,39 @@
# Wildcard routing for per-slug forte drops: <slug>.drop.forteapps.net -> the forte-drop
# web pod. The forteapp chart only emits a single exact Host(`drop.forteapps.net`) route
# (the apex: admin + /api + public /shared drops), so this ADDITIVE IngressRoute adds the
# wildcard. Kept in launchpad (forte-drop-specific) rather than the shared forteapp chart.
#
# It targets the SAME service the chart's route does — forte-drop-app:3000 — whose
# targetPort is the auth sidecar (service.yaml: targetPort = auth.sidecarPort when auth is
# on). So wildcard subdomains flow service:3000 -> sidecar -> app, i.e. they are Forte-login
# gated exactly like the admin root. A forteOnly drop is therefore never served un-gated.
#
# priority: 1 (intentionally LOW). Traefik orders routers by rule-length by default, and the
# regex string is longer than Host(`mcp.drop.forteapps.net`); without an explicit low
# priority this regex would OUTRANK and STEAL mcp.drop.forteapps.net (and the apex) into the
# web pod. priority:1 guarantees the exact Host() routers (mcp release, chart apex) always win;
# only real per-slug subdomains fall through to here. The app's reserved-slug check
# (mcp/www/api/admin/app) is a second line of defence.
apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
name: forte-drop-subdomains
namespace: forte-drop
labels:
app.kubernetes.io/name: forte-drop
app.kubernetes.io/part-of: apps
app.kubernetes.io/managed-by: argocd
spec:
entryPoints:
- websecure
routes:
# Traefik v3 (chart 28.x) HostRegexp takes a Go RE2 pattern. Verify the rendered
# router against mcp./www./app./apex/<real-slug> before relying on it in prod.
- match: HostRegexp(`^[a-z0-9-]+\.drop\.forteapps\.net$`)
kind: Rule
priority: 1
services:
- name: forte-drop-app
port: 3000
tls:
secretName: wildcard-drop-forteapps-net-tls
@@ -5,3 +5,5 @@ resources:
- keycloak-client-forte-drop.yaml
- forte-drop-pdb.yaml
- forte-drop-secrets-sealed.yaml
- wildcard-drop-tls-certificate.yaml
- forte-drop-subdomains-ingressroute.yaml
@@ -0,0 +1,35 @@
---
# Wildcard TLS cert for the per-slug drop subdomains: <slug>.drop.forteapps.net.
# forte_drop serves forte-login drops on their own subdomain (gated by the auth
# sidecar), so each drop needs a valid cert for *.drop.forteapps.net — a name the
# existing *.forteapps.net wildcard CANNOT cover (TLS wildcards match one label only).
#
# Scope: this cert covers ONLY *.drop.forteapps.net. The apex drop.forteapps.net is
# NOT included here — it is served by the forteapp chart's own Certificate (secret
# forte-drop-tls, dnsNames: [drop.forteapps.net]) and/or the existing *.forteapps.net
# wildcard, so adding it here would be redundant.
#
# Issued DIRECTLY into the forte-drop namespace (not via the chart) so the app's
# Traefik IngressRoute — which must reference a TLS secret in its OWN namespace — can
# use it without cross-namespace cloning. This is the single issuer of secret
# wildcard-drop-forteapps-net-tls; the forte-drop-subdomains IngressRoute references
# that secret. The letsencrypt-prod dns01 solver is authorized for this name via its
# selector.dnsZones (forteapps.net).
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: wildcard-drop-forteapps-net
namespace: forte-drop
spec:
secretName: wildcard-drop-forteapps-net-tls
issuerRef:
name: letsencrypt-prod
kind: ClusterIssuer
dnsNames:
- '*.drop.forteapps.net' # per-slug forte drop subdomains
duration: 2160h0m0s # 90 days
renewBefore: 720h0m0s # renew 30 days before expiry
privateKey:
algorithm: RSA
encoding: PKCS1
size: 4096
@@ -233,10 +233,6 @@ spec:
value: "{{ regex_replace_all('https?://[^/]*', request.object.metadata.annotations.\"policies.forteapps.io/auth-oidc-callback-path\", '') }}"
- name: AUTH_OIDC_SCOPES
value: "{{ request.object.metadata.annotations.\"policies.forteapps.io/auth-oidc-scopes\" || 'openid,profile,email' }}"
- name: AUTH_OIDC_COOKIE_DOMAIN
value: "{{ request.object.metadata.annotations.\"policies.forteapps.io/auth-oidc-cookie-domain\" || '' }}"
- name: AUTH_OIDC_ALLOWED_RETURN_HOSTS
value: "{{ request.object.metadata.annotations.\"policies.forteapps.io/auth-oidc-allowed-return-hosts\" || '' }}"
- name: AUTH_PUBLIC_PATHS
value: "{{ request.object.metadata.annotations.\"policies.forteapps.io/auth-public-paths\" || '/healthz' }}"
- name: AUTH_OIDC_COOKIE_SECRET
+2 -2
View File
@@ -1326,7 +1326,7 @@ storage:
- Shared configuration and prompts live in the `shared-prompts` Git submodule (→ `Forte/ai-review-prompts`)
- Review mode: `ONLY_ADDED_WITH_CONTEXT` — reviews only new/changed lines plus surrounding context (token-efficient)
- Agent mode: disabled (one-shot review, no multi-turn reasoning)
- LLM: Claude Sonnet (`claude-3-opus`)
- LLM: Claude Sonnet (`claude-sonnet-4-20250514`)
**Shared Prompts Structure** (submodule: `Forte/ai-review-prompts`):
```
@@ -1344,7 +1344,7 @@ shared-prompts/
```yaml
llm:
provider: CLAUDE
model: claude-3-opus
model: claude-sonnet-4-20250514
vcs:
provider: GITEA
review:
-36
View File
@@ -1,36 +0,0 @@
# Domain Docs
How the engineering skills should consume this repo's domain documentation when exploring the codebase.
## Before exploring, read these
- **`CONTEXT.md`** at the repo root, or
- **`CONTEXT-MAP.md`** at the repo root if it exists — it points at one `CONTEXT.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):
```
/
├── CONTEXT.md
├── docs/adr/
│ ├── 0001-event-sourced-orders.md
│ └── 0002-postgres-for-write-model.md
└── src/
```
## 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 `CONTEXT.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…_
-39
View File
@@ -1,39 +0,0 @@
# Issue tracker: Gitea
Issues for this repo live in Gitea at `git.forteapps.net/Forte/launchpad`. Use the Gitea API or `tea` CLI.
## Conventions
- **Create an issue**: `tea issue create --title "..." --description "..."`
or via API: `curl -X POST "https://git.forteapps.net/api/v1/repos/Forte/launchpad/issues" -H "Authorization: token $GITEA_TOKEN" -H "Content-Type: application/json" -d '{"title":"...","body":"..."}'`
- **Read an issue**: `tea issue view <number>` or API `GET /api/v1/repos/Forte/launchpad/issues/<number>`
- **List issues**: `tea issue list` or API `GET /api/v1/repos/Forte/launchpad/issues?state=open`
- **Comment on an issue**: `tea issue comment <number> "..."` or API `POST /api/v1/repos/Forte/launchpad/issues/<number>/comments`
- **Apply labels**: API `POST /api/v1/repos/Forte/launchpad/issues/<number>/labels` with `{"labels": [<label_id>]}`
- **Close**: API `PATCH /api/v1/repos/Forte/launchpad/issues/<number>` with `{"state": "closed"}`
Infer the repo from `git remote -v`.
## Pull requests as a triage surface
**PRs as a request surface: no.**
## When a skill says "publish to the issue tracker"
Create a Gitea issue.
## When a skill says "fetch the relevant ticket"
Fetch the issue via API or `tea issue view <number>`.
## 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 Destination / Notes / Decisions-so-far / Fog body.
- Create: `POST /api/v1/repos/Forte/launchpad/issues` with `{"title":"...","body":"...","labels":[<wayfinder:map label id>]}`
- **Child ticket**: an issue carrying `Part of #<map>` at the top of its body and a `wayfinder:<type>` label (`research`/`prototype`/`grilling`/`task`). Once claimed, the ticket is assigned to the driving dev.
- **Blocking**: Gitea does not have native issue dependencies. Fall back to a `Blocked by: #<n>, #<n>` line at the top of the child body. A ticket is unblocked when every issue it lists is closed.
- **Frontier query**: list the map's open children — `GET /api/v1/repos/Forte/launchpad/issues?state=open&labels=wayfinder:research,wayfinder:prototype,wayfinder:grilling,wayfinder:task` — then filter to those whose body starts with `Part of #<map>`. Drop any with an open issue in their `Blocked by` line, or with an assignee. First in map order wins.
- **Claim**: `PATCH /api/v1/repos/Forte/launchpad/issues/<n>` with `{"assignees":["<username>"]}` — the session's first write.
- **Resolve**: post the answer as a comment (`POST .../comments`), close the issue (`PATCH` with `{"state":"closed"}`), then append a context pointer (gist + link) to the map's Decisions-so-far by editing the map issue body.
-15
View File
@@ -1,15 +0,0 @@
# 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 right-hand column to match whatever vocabulary you actually use.
+1 -1
View File
@@ -31,7 +31,7 @@ gitea:
ENABLE_PASSWORD_SIGNIN_FORM: false
AUTO_WATCH_ON_CHANGES: false
AUTO_WATCH_NEW_REPOS: false
ENABLE_NOTIFY_MAIL: true
ENABLE_NOTIFY_MAIL: false
ENABLE_TIMETRACKING: false
openid: