fix(git): avoid duplicate gh repo flag in pr-diff

.woodpecker/ci.yml

@@ -46,18 +46,28 @@ steps:
   test:
     image: *node_image
     environment:
-      DATABASE_URL: postgresql://mosaic:mosaic@postgres:5432/mosaic
+      # Avoid the namespace-level Woodpecker DB service named "postgres".
+      # The Kubernetes backend exposes service containers by step name.
+      DATABASE_URL: postgresql://mosaic:mosaic@ci-postgres:5432/mosaic
     commands:
       - *enable_pnpm
       # Install postgresql-client for pg_isready
       - apk add --no-cache postgresql-client
-      # Wait up to 30s for postgres to be ready
+      # Wait up to 60s for CI postgres to be ready; fail fast if it never comes up.
       - |
-        for i in $(seq 1 30); do
-          pg_isready -h postgres -p 5432 -U mosaic && break
-          echo "Waiting for postgres ($i/30)..."
+        ready=0
+        for i in $(seq 1 60); do
+          if pg_isready -h ci-postgres -p 5432 -U mosaic; then
+            ready=1
+            break
+          fi
+          echo "Waiting for ci-postgres ($i/60)..."
           sleep 1
         done
+        if [ "$ready" -ne 1 ]; then
+          echo "ci-postgres did not become ready" >&2
+          exit 1
+        fi
       # Run migrations (DATABASE_URL is set in environment above)
       - pnpm --filter @mosaicstack/db run db:migrate
       # Run all tests
@@ -66,7 +76,7 @@ steps:
       - typecheck
 
 services:
-  postgres:
+  ci-postgres:
     image: pgvector/pgvector:pg17
     environment:
       POSTGRES_USER: mosaic

guides/BOOTSTRAP.md

@@ -453,26 +453,6 @@ Initialize standard labels and the first pre-MVP milestone:
 
 ---
 
-## Secrets Bootstrap (Required for Every New App)
-
-Every new application MUST complete the following secrets bootstrap before deploying to any non-local environment. This is a hard gate — deployment without completed secrets bootstrap is forbidden.
-
-### Secrets bootstrap checklist
-
-- [ ] Vault path created: `vault kv put secret/k3s/<app>/ ...` with all required secret fields
-- [ ] Required secrets listed in project README under a "Secrets architecture" section, including:
-  - Vault path(s) used
-  - All required secret keys and their purpose
-  - Whether the app uses ESO bridge (default) or Direct-Vault (opt-in, with justification)
-- [ ] `external-secret.yaml` manifest committed to repo's `deploy/` or `k8s/` directory
-- [ ] Deployment YAML references the synced k8s Secret via `secretKeyRef` (not raw env vars or `.env` files)
-- [ ] App startup has schema-based validation for all required env vars (zod / pydantic / envconfig equivalent) that exits non-zero on missing required values
-- [ ] Direct-Vault opt-in (if applicable): justification documented in README + AppRole provisioned + bootstrap credentials stored in Vault and synced via a separate `ExternalSecret`
-
-See `~/.config/mosaic/guides/VAULT-SECRETS.md` for full worked examples of the ESO bridge pattern, the Direct-Vault opt-in pattern, and the forbidden antipatterns.
-
----
-
 ## Checklist
 
 After bootstrapping, verify:

guides/VAULT-SECRETS.md

@@ -203,374 +203,3 @@ Error: token expired
 3. **Audit logging** - All access is logged; act accordingly
 4. **No local copies** - Don't store secrets in files or env vars long-term
 5. **Rotate on compromise** - Immediately rotate any exposed secrets
-
----
-
-## Secrets Architecture Decision Matrix
-
-Use this table to choose between the ESO bridge (default) and Direct-Vault (opt-in) patterns for every new app or integration.
-
-| Factor | ESO Bridge (default) | Direct-Vault (opt-in) |
-| --- | --- | --- |
-| **Use-case** | All static secrets (DB creds, API keys, signing keys, OAuth secrets) | Dynamic creds with short TTLs (DB rotation, AWS STS, PKI), per-request audit trails, or lease renewal mid-pod-lifecycle |
-| **App code change** | None — reads standard env vars via `secretKeyRef` | Requires Vault client (`hvac`, `node-vault`, `vault/api`) in application code |
-| **Secret rotation** | ESO re-syncs on Vault write; pod restart or secret refresh picks up new value | App manages lease renewal or re-auth within the running process |
-| **Audit granularity** | Access logged at Vault when ESO syncs; no per-request app audit | Every app request to Vault is a separate audit log entry |
-| **Operational burden** | Low — ESO handles polling, sync, and k8s Secret lifecycle | Higher — app must handle auth, lease renewal, error paths, and token rotation |
-| **Justification required?** | No — this is the default | Yes — document in project README under "Secrets architecture" |
-| **Example use cases** | Web app DB password, OAuth client secret, JWT signing key, API token | HashiCorp DB secrets engine with 15-min TTL leases, AWS STS assume-role, Vault PKI short-lived certs |
-
-**Decision rule:** If you are unsure, use ESO. Only justify Direct-Vault when the secret cannot be safely stored in a k8s Secret (too short-lived, per-request TTL required, or mid-lifecycle renewal needed).
-
----
-
-## ESO Bridge Pattern (Default)
-
-This is the required default for all k8s workloads. Follow this exact pattern unless a documented dynamic-secrets requirement justifies Direct-Vault.
-
-### 1. Provision Vault path
-
-```bash
-# Write the secrets for the app (run once; use IaC/Terraform for repeatable provisioning)
-vault kv put secret/k3s/<app> \
-  db_password="..." \
-  api_key="..." \
-  jwt_secret="..."
-```
-
-Use the canonical path structure: `secret/k3s/<app>` for k3s cluster workloads.
-
-### 2. ExternalSecret manifest
-
-Commit this to the repo's `deploy/` or `k8s/` directory:
-
-```yaml
-# deploy/external-secret.yaml
-apiVersion: external-secrets.io/v1beta1
-kind: ExternalSecret
-metadata:
-  name: <app>-secrets
-  namespace: <namespace>
-spec:
-  refreshInterval: 1h
-  secretStoreRef:
-    name: vault-backend        # ClusterSecretStore name — verify with cluster admin
-    kind: ClusterSecretStore
-  target:
-    name: <app>-secrets        # k8s Secret name that will be created
-    creationPolicy: Owner
-  data:
-    - secretKey: DB_PASSWORD   # key in the k8s Secret
-      remoteRef:
-        key: secret/k3s/<app>  # Vault path
-        property: db_password  # field within the Vault secret
-    - secretKey: API_KEY
-      remoteRef:
-        key: secret/k3s/<app>
-        property: api_key
-    - secretKey: JWT_SECRET
-      remoteRef:
-        key: secret/k3s/<app>
-        property: jwt_secret
-```
-
-### 3. Deployment manifest — reference synced k8s Secret
-
-```yaml
-# deploy/deployment.yaml (env section)
-env:
-  - name: DB_PASSWORD
-    valueFrom:
-      secretKeyRef:
-        name: <app>-secrets   # matches ExternalSecret target.name
-        key: DB_PASSWORD
-  - name: API_KEY
-    valueFrom:
-      secretKeyRef:
-        name: <app>-secrets
-        key: API_KEY
-  - name: JWT_SECRET
-    valueFrom:
-      secretKeyRef:
-        name: <app>-secrets
-        key: JWT_SECRET
-  - name: PORT
-    value: "3000"              # safe-default: non-secret, no Vault needed
-```
-
-### 4. App-side schema validation — TypeScript (zod)
-
-Validate all required env vars at startup. Exit non-zero on missing values.
-
-```typescript
-// src/env.ts
-import { z } from 'zod';
-
-const envSchema = z.object({
-  DB_PASSWORD: z.string().min(1, 'DB_PASSWORD is required'),
-  API_KEY: z.string().min(1, 'API_KEY is required'),
-  JWT_SECRET: z.string().min(32, 'JWT_SECRET must be at least 32 chars'),
-  PORT: z.coerce.number().default(3000),
-  NODE_ENV: z.enum(['development', 'production', 'test']).default('production'),
-});
-
-const result = envSchema.safeParse(process.env);
-if (!result.success) {
-  console.error('Missing or invalid environment variables:');
-  console.error(result.error.flatten().fieldErrors);
-  process.exit(1);
-}
-
-export const env = result.data;
-```
-
-### 4b. App-side schema validation — Python (pydantic)
-
-```python
-# src/config.py
-from pydantic_settings import BaseSettings, SettingsConfigDict
-
-class Settings(BaseSettings):
-    db_password: str
-    api_key: str
-    jwt_secret: str
-    port: int = 3000
-    node_env: str = "production"
-
-    model_config = SettingsConfigDict(env_file=None)  # no .env in prod
-
-try:
-    settings = Settings()
-except Exception as e:
-    import sys
-    print(f"Missing or invalid environment variables: {e}", file=sys.stderr)
-    sys.exit(1)
-```
-
-### 4c. App-side schema validation — Go (envconfig)
-
-```go
-// config/config.go
-package config
-
-import (
-    "fmt"
-    "github.com/kelseyhightower/envconfig"
-)
-
-type Config struct {
-    DBPassword string `envconfig:"DB_PASSWORD" required:"true"`
-    APIKey     string `envconfig:"API_KEY" required:"true"`
-    JWTSecret  string `envconfig:"JWT_SECRET" required:"true"`
-    Port       int    `envconfig:"PORT" default:"3000"`
-}
-
-func Load() (*Config, error) {
-    var cfg Config
-    if err := envconfig.Process("", &cfg); err != nil {
-        return nil, fmt.Errorf("invalid environment: %w", err)
-    }
-    return &cfg, nil
-}
-```
-
-In your `main.go`:
-
-```go
-cfg, err := config.Load()
-if err != nil {
-    fmt.Fprintln(os.Stderr, err)
-    os.Exit(1)
-}
-```
-
----
-
-## Direct-Vault Opt-In Pattern
-
-Use this pattern ONLY when a documented dynamic-secrets requirement applies (DB rotation with short TTLs, AWS STS, PKI, per-request audit). Document the justification in the project README under "Secrets architecture" before implementing.
-
-### When it is justified
-
-- Vault DB secrets engine with lease TTLs shorter than a typical pod lifecycle (< 1 hour)
-- AWS STS assume-role tokens generated per-request
-- Vault PKI short-lived certificates (< 24 hours) that must be renewed within a running pod
-- Per-request audit trail requirement (each app call must appear separately in Vault audit log)
-
-### Provision an AppRole for the app
-
-```bash
-# Enable AppRole auth (if not already enabled)
-vault auth enable approle
-
-# Create a Vault policy for the app
-# Note: KV v2 paths require both the exact path (for the top-level secret) and the
-# wildcard (for sub-paths). Always include both to avoid permission denied errors.
-vault policy write <app>-policy - <<EOF
-path "secret/data/k3s/<app>" {
-  capabilities = ["read"]
-}
-path "secret/data/k3s/<app>/*" {
-  capabilities = ["read"]
-}
-path "database/creds/<app>-role" {
-  capabilities = ["read"]
-}
-EOF
-
-# Create the AppRole
-vault write auth/approle/role/<app>-role \
-  token_policies="<app>-policy" \
-  token_ttl=1h \
-  token_max_ttl=4h \
-  secret_id_ttl=0
-
-# Retrieve role-id and secret-id
-vault read auth/approle/role/<app>-role/role-id
-vault write -f auth/approle/role/<app>-role/secret-id
-```
-
-### Bootstrap AppRole credentials via ESO (solving the chicken-and-egg problem)
-
-The AppRole `role-id` and `secret-id` are themselves secrets. Store them in Vault at a bootstrap path, then use ESO to sync them into a k8s Secret. The app reads that k8s Secret at startup to authenticate with Vault directly.
-
-```bash
-# Store the bootstrap credentials in Vault
-vault kv put secret/k3s/<app>-bootstrap \
-  role_id="<role-id>" \
-  secret_id="<secret-id>"
-```
-
-```yaml
-# deploy/external-secret-bootstrap.yaml
-apiVersion: external-secrets.io/v1beta1
-kind: ExternalSecret
-metadata:
-  name: <app>-vault-auth
-  namespace: <namespace>
-spec:
-  refreshInterval: 24h
-  secretStoreRef:
-    name: vault-backend
-    kind: ClusterSecretStore
-  target:
-    name: <app>-vault-auth
-    creationPolicy: Owner
-  data:
-    - secretKey: VAULT_ROLE_ID
-      remoteRef:
-        key: secret/k3s/<app>-bootstrap
-        property: role_id
-    - secretKey: VAULT_SECRET_ID
-      remoteRef:
-        key: secret/k3s/<app>-bootstrap
-        property: secret_id
-```
-
-```yaml
-# deploy/deployment.yaml (env section for Direct-Vault app)
-env:
-  - name: VAULT_ADDR
-    value: "https://vault.example.com"  # safe-default: non-secret cluster address
-  - name: VAULT_ROLE_ID
-    valueFrom:
-      secretKeyRef:
-        name: <app>-vault-auth
-        key: VAULT_ROLE_ID
-  - name: VAULT_SECRET_ID
-    valueFrom:
-      secretKeyRef:
-        name: <app>-vault-auth
-        key: VAULT_SECRET_ID
-```
-
-### App-side Vault client pattern
-
-```typescript
-// src/vault-client.ts — only exists in Direct-Vault apps
-import vault from 'node-vault';
-import { z } from 'zod';
-
-const bootstrapSchema = z.object({
-  VAULT_ADDR: z.string().url(),
-  VAULT_ROLE_ID: z.string().min(1),
-  VAULT_SECRET_ID: z.string().min(1),
-});
-
-const bootstrap = bootstrapSchema.parse(process.env);
-
-const client = vault({ endpoint: bootstrap.VAULT_ADDR });
-
-export async function getVaultClient() {
-  const { auth } = await client.approleLogin({
-    role_id: bootstrap.VAULT_ROLE_ID,
-    secret_id: bootstrap.VAULT_SECRET_ID,
-  });
-  client.token = auth.client_token;
-  return client;
-}
-```
-
-Document in README under "Secrets architecture": the Vault path, why Direct-Vault is required, and the lease/renewal strategy.
-
----
-
-## Forbidden Patterns (CI Lint Targets)
-
-The following patterns are forbidden in all Mosaic projects. CI lint SHOULD catch these automatically (implementation tracked separately). Agents MUST NOT introduce these patterns.
-
-### 1. Untagged fallback defaults for required values
-
-```yaml
-# FORBIDDEN — required secret with silent fallback
-environment:
-  - DB_PASSWORD=${DB_PASSWORD:-changeme}
-  - API_KEY=${API_KEY:-}
-
-# REQUIRED — fast-fail on missing required values
-environment:
-  - DB_PASSWORD=${DB_PASSWORD:?DB_PASSWORD is required}
-  - API_KEY=${API_KEY:?API_KEY is required}
-
-# ALLOWED — true convenience default, tagged
-environment:
-  - PORT=${PORT:-3000}  # safe-default: non-secret, app works at any port
-```
-
-This applies to: `docker-compose.yml`, k8s manifests, Helm `values.yaml`, any env file committed to git.
-
-### 2. Vault KV calls in application source code (ESO-default projects)
-
-```python
-# FORBIDDEN in ESO-default apps — direct Vault client in app source
-import hvac
-client = hvac.Client(url=os.environ['VAULT_ADDR'])
-secret = client.secrets.kv.v2.read_secret_version(path='myapp/db')
-```
-
-ESO-default apps read env vars only. Direct-Vault clients belong only in apps with a documented dynamic-secrets justification in README.
-
-### 3. Hardcoded secrets or API keys in committed files
-
-```python
-# FORBIDDEN — hardcoded credential
-DB_PASSWORD = "supersecret123"
-API_KEY = "sk-live-abc123"
-```
-
-No exceptions. CI lint must flag any string matching common secret patterns (`password`, `secret`, `api_key`, `token` assigned a literal non-env-var value).
-
-### 4. `.env` files in production deployment paths
-
-```
-# FORBIDDEN — .env file in a production deploy path
-deploy/.env
-k8s/.env
-docker/.env
-
-# ALLOWED — local dev only
-.env.example          # template only, no real values
-.env                  # local dev, must be in .gitignore
-```
-
-`.env` files are acceptable in local-dev contexts only and MUST be in `.gitignore`. They are forbidden in any path that a CI pipeline or production deployment process reads directly.

packages/mosaic/framework/defaults/STANDARDS.md

@@ -27,16 +27,6 @@ Master/slave model:
 - Do not perform destructive git/file actions without explicit instruction.
 - Browser automation (Playwright, Cypress, Puppeteer) MUST run in headless mode. Never launch a visible browser — it collides with the user's display and active session.
 
-### Secrets handling (HARD RULE)
-
-- Vault is the canonical source-of-truth for every secret in every environment. No exceptions.
-- For k8s workloads, the default read path is **External Secrets Operator → k8s Secret → env var** (`secretKeyRef`). The app reads standard env vars; no Vault client in app code.
-- Direct-Vault clients in application code are **opt-in only**, justified per-app by a documented dynamic-secrets requirement (e.g., DB rotation, AWS STS). Default to ESO. Document the justification in the project's README under "Secrets architecture".
-- `${VAR:-default}` fallback syntax in any deployment configuration (compose, k8s manifests, Helm values, env files committed to git) is **forbidden** for required values. Use `${VAR:?VAR is required}` to fast-fail. Defaults are allowed only for true conveniences (e.g. `${PORT:-3000}`) and MUST be tagged `# safe-default: <reason>` so a reviewer can confirm the intent.
-- `.env` files in production deployment paths are **forbidden**. `.env.example` and `.env` in local-dev paths are fine.
-- App startup MUST validate required secrets against a schema (zod / pydantic / equivalent) and exit non-zero on missing required values. Never run with defaulted weak fallbacks.
-- New apps: bootstrap checklist (see `~/.config/mosaic/guides/BOOTSTRAP.md`) MUST include Vault path provisioning + `ExternalSecret` manifest + README declaring the Vault path and required keys.
-
 ## Session Lifecycle Contract
 
 - Start: `scripts/agent/session-start.sh`

packages/mosaic/framework/guides/BOOTSTRAP.md

@@ -453,26 +453,6 @@ Initialize standard labels and the first pre-MVP milestone:
 
 ---
 
-## Secrets Bootstrap (Required for Every New App)
-
-Every new application MUST complete the following secrets bootstrap before deploying to any non-local environment. This is a hard gate — deployment without completed secrets bootstrap is forbidden.
-
-### Secrets bootstrap checklist
-
-- [ ] Vault path created: `vault kv put secret/k3s/<app>/ ...` with all required secret fields
-- [ ] Required secrets listed in project README under a "Secrets architecture" section, including:
-  - Vault path(s) used
-  - All required secret keys and their purpose
-  - Whether the app uses ESO bridge (default) or Direct-Vault (opt-in, with justification)
-- [ ] `external-secret.yaml` manifest committed to repo's `deploy/` or `k8s/` directory
-- [ ] Deployment YAML references the synced k8s Secret via `secretKeyRef` (not raw env vars or `.env` files)
-- [ ] App startup has schema-based validation for all required env vars (zod / pydantic / envconfig equivalent) that exits non-zero on missing required values
-- [ ] Direct-Vault opt-in (if applicable): justification documented in README + AppRole provisioned + bootstrap credentials stored in Vault and synced via a separate `ExternalSecret`
-
-See `~/.config/mosaic/guides/VAULT-SECRETS.md` for full worked examples of the ESO bridge pattern, the Direct-Vault opt-in pattern, and the forbidden antipatterns.
-
----
-
 ## Checklist
 
 After bootstrapping, verify:

packages/mosaic/framework/guides/VAULT-SECRETS.md

@@ -203,374 +203,3 @@ Error: token expired
 3. **Audit logging** - All access is logged; act accordingly
 4. **No local copies** - Don't store secrets in files or env vars long-term
 5. **Rotate on compromise** - Immediately rotate any exposed secrets
-
----
-
-## Secrets Architecture Decision Matrix
-
-Use this table to choose between the ESO bridge (default) and Direct-Vault (opt-in) patterns for every new app or integration.
-
-| Factor | ESO Bridge (default) | Direct-Vault (opt-in) |
-| --- | --- | --- |
-| **Use-case** | All static secrets (DB creds, API keys, signing keys, OAuth secrets) | Dynamic creds with short TTLs (DB rotation, AWS STS, PKI), per-request audit trails, or lease renewal mid-pod-lifecycle |
-| **App code change** | None — reads standard env vars via `secretKeyRef` | Requires Vault client (`hvac`, `node-vault`, `vault/api`) in application code |
-| **Secret rotation** | ESO re-syncs on Vault write; pod restart or secret refresh picks up new value | App manages lease renewal or re-auth within the running process |
-| **Audit granularity** | Access logged at Vault when ESO syncs; no per-request app audit | Every app request to Vault is a separate audit log entry |
-| **Operational burden** | Low — ESO handles polling, sync, and k8s Secret lifecycle | Higher — app must handle auth, lease renewal, error paths, and token rotation |
-| **Justification required?** | No — this is the default | Yes — document in project README under "Secrets architecture" |
-| **Example use cases** | Web app DB password, OAuth client secret, JWT signing key, API token | HashiCorp DB secrets engine with 15-min TTL leases, AWS STS assume-role, Vault PKI short-lived certs |
-
-**Decision rule:** If you are unsure, use ESO. Only justify Direct-Vault when the secret cannot be safely stored in a k8s Secret (too short-lived, per-request TTL required, or mid-lifecycle renewal needed).
-
----
-
-## ESO Bridge Pattern (Default)
-
-This is the required default for all k8s workloads. Follow this exact pattern unless a documented dynamic-secrets requirement justifies Direct-Vault.
-
-### 1. Provision Vault path
-
-```bash
-# Write the secrets for the app (run once; use IaC/Terraform for repeatable provisioning)
-vault kv put secret/k3s/<app> \
-  db_password="..." \
-  api_key="..." \
-  jwt_secret="..."
-```
-
-Use the canonical path structure: `secret/k3s/<app>` for k3s cluster workloads.
-
-### 2. ExternalSecret manifest
-
-Commit this to the repo's `deploy/` or `k8s/` directory:
-
-```yaml
-# deploy/external-secret.yaml
-apiVersion: external-secrets.io/v1beta1
-kind: ExternalSecret
-metadata:
-  name: <app>-secrets
-  namespace: <namespace>
-spec:
-  refreshInterval: 1h
-  secretStoreRef:
-    name: vault-backend        # ClusterSecretStore name — verify with cluster admin
-    kind: ClusterSecretStore
-  target:
-    name: <app>-secrets        # k8s Secret name that will be created
-    creationPolicy: Owner
-  data:
-    - secretKey: DB_PASSWORD   # key in the k8s Secret
-      remoteRef:
-        key: secret/k3s/<app>  # Vault path
-        property: db_password  # field within the Vault secret
-    - secretKey: API_KEY
-      remoteRef:
-        key: secret/k3s/<app>
-        property: api_key
-    - secretKey: JWT_SECRET
-      remoteRef:
-        key: secret/k3s/<app>
-        property: jwt_secret
-```
-
-### 3. Deployment manifest — reference synced k8s Secret
-
-```yaml
-# deploy/deployment.yaml (env section)
-env:
-  - name: DB_PASSWORD
-    valueFrom:
-      secretKeyRef:
-        name: <app>-secrets   # matches ExternalSecret target.name
-        key: DB_PASSWORD
-  - name: API_KEY
-    valueFrom:
-      secretKeyRef:
-        name: <app>-secrets
-        key: API_KEY
-  - name: JWT_SECRET
-    valueFrom:
-      secretKeyRef:
-        name: <app>-secrets
-        key: JWT_SECRET
-  - name: PORT
-    value: "3000"              # safe-default: non-secret, no Vault needed
-```
-
-### 4. App-side schema validation — TypeScript (zod)
-
-Validate all required env vars at startup. Exit non-zero on missing values.
-
-```typescript
-// src/env.ts
-import { z } from 'zod';
-
-const envSchema = z.object({
-  DB_PASSWORD: z.string().min(1, 'DB_PASSWORD is required'),
-  API_KEY: z.string().min(1, 'API_KEY is required'),
-  JWT_SECRET: z.string().min(32, 'JWT_SECRET must be at least 32 chars'),
-  PORT: z.coerce.number().default(3000),
-  NODE_ENV: z.enum(['development', 'production', 'test']).default('production'),
-});
-
-const result = envSchema.safeParse(process.env);
-if (!result.success) {
-  console.error('Missing or invalid environment variables:');
-  console.error(result.error.flatten().fieldErrors);
-  process.exit(1);
-}
-
-export const env = result.data;
-```
-
-### 4b. App-side schema validation — Python (pydantic)
-
-```python
-# src/config.py
-from pydantic_settings import BaseSettings, SettingsConfigDict
-
-class Settings(BaseSettings):
-    db_password: str
-    api_key: str
-    jwt_secret: str
-    port: int = 3000
-    node_env: str = "production"
-
-    model_config = SettingsConfigDict(env_file=None)  # no .env in prod
-
-try:
-    settings = Settings()
-except Exception as e:
-    import sys
-    print(f"Missing or invalid environment variables: {e}", file=sys.stderr)
-    sys.exit(1)
-```
-
-### 4c. App-side schema validation — Go (envconfig)
-
-```go
-// config/config.go
-package config
-
-import (
-    "fmt"
-    "github.com/kelseyhightower/envconfig"
-)
-
-type Config struct {
-    DBPassword string `envconfig:"DB_PASSWORD" required:"true"`
-    APIKey     string `envconfig:"API_KEY" required:"true"`
-    JWTSecret  string `envconfig:"JWT_SECRET" required:"true"`
-    Port       int    `envconfig:"PORT" default:"3000"`
-}
-
-func Load() (*Config, error) {
-    var cfg Config
-    if err := envconfig.Process("", &cfg); err != nil {
-        return nil, fmt.Errorf("invalid environment: %w", err)
-    }
-    return &cfg, nil
-}
-```
-
-In your `main.go`:
-
-```go
-cfg, err := config.Load()
-if err != nil {
-    fmt.Fprintln(os.Stderr, err)
-    os.Exit(1)
-}
-```
-
----
-
-## Direct-Vault Opt-In Pattern
-
-Use this pattern ONLY when a documented dynamic-secrets requirement applies (DB rotation with short TTLs, AWS STS, PKI, per-request audit). Document the justification in the project README under "Secrets architecture" before implementing.
-
-### When it is justified
-
-- Vault DB secrets engine with lease TTLs shorter than a typical pod lifecycle (< 1 hour)
-- AWS STS assume-role tokens generated per-request
-- Vault PKI short-lived certificates (< 24 hours) that must be renewed within a running pod
-- Per-request audit trail requirement (each app call must appear separately in Vault audit log)
-
-### Provision an AppRole for the app
-
-```bash
-# Enable AppRole auth (if not already enabled)
-vault auth enable approle
-
-# Create a Vault policy for the app
-# Note: KV v2 paths require both the exact path (for the top-level secret) and the
-# wildcard (for sub-paths). Always include both to avoid permission denied errors.
-vault policy write <app>-policy - <<EOF
-path "secret/data/k3s/<app>" {
-  capabilities = ["read"]
-}
-path "secret/data/k3s/<app>/*" {
-  capabilities = ["read"]
-}
-path "database/creds/<app>-role" {
-  capabilities = ["read"]
-}
-EOF
-
-# Create the AppRole
-vault write auth/approle/role/<app>-role \
-  token_policies="<app>-policy" \
-  token_ttl=1h \
-  token_max_ttl=4h \
-  secret_id_ttl=0
-
-# Retrieve role-id and secret-id
-vault read auth/approle/role/<app>-role/role-id
-vault write -f auth/approle/role/<app>-role/secret-id
-```
-
-### Bootstrap AppRole credentials via ESO (solving the chicken-and-egg problem)
-
-The AppRole `role-id` and `secret-id` are themselves secrets. Store them in Vault at a bootstrap path, then use ESO to sync them into a k8s Secret. The app reads that k8s Secret at startup to authenticate with Vault directly.
-
-```bash
-# Store the bootstrap credentials in Vault
-vault kv put secret/k3s/<app>-bootstrap \
-  role_id="<role-id>" \
-  secret_id="<secret-id>"
-```
-
-```yaml
-# deploy/external-secret-bootstrap.yaml
-apiVersion: external-secrets.io/v1beta1
-kind: ExternalSecret
-metadata:
-  name: <app>-vault-auth
-  namespace: <namespace>
-spec:
-  refreshInterval: 24h
-  secretStoreRef:
-    name: vault-backend
-    kind: ClusterSecretStore
-  target:
-    name: <app>-vault-auth
-    creationPolicy: Owner
-  data:
-    - secretKey: VAULT_ROLE_ID
-      remoteRef:
-        key: secret/k3s/<app>-bootstrap
-        property: role_id
-    - secretKey: VAULT_SECRET_ID
-      remoteRef:
-        key: secret/k3s/<app>-bootstrap
-        property: secret_id
-```
-
-```yaml
-# deploy/deployment.yaml (env section for Direct-Vault app)
-env:
-  - name: VAULT_ADDR
-    value: "https://vault.example.com"  # safe-default: non-secret cluster address
-  - name: VAULT_ROLE_ID
-    valueFrom:
-      secretKeyRef:
-        name: <app>-vault-auth
-        key: VAULT_ROLE_ID
-  - name: VAULT_SECRET_ID
-    valueFrom:
-      secretKeyRef:
-        name: <app>-vault-auth
-        key: VAULT_SECRET_ID
-```
-
-### App-side Vault client pattern
-
-```typescript
-// src/vault-client.ts — only exists in Direct-Vault apps
-import vault from 'node-vault';
-import { z } from 'zod';
-
-const bootstrapSchema = z.object({
-  VAULT_ADDR: z.string().url(),
-  VAULT_ROLE_ID: z.string().min(1),
-  VAULT_SECRET_ID: z.string().min(1),
-});
-
-const bootstrap = bootstrapSchema.parse(process.env);
-
-const client = vault({ endpoint: bootstrap.VAULT_ADDR });
-
-export async function getVaultClient() {
-  const { auth } = await client.approleLogin({
-    role_id: bootstrap.VAULT_ROLE_ID,
-    secret_id: bootstrap.VAULT_SECRET_ID,
-  });
-  client.token = auth.client_token;
-  return client;
-}
-```
-
-Document in README under "Secrets architecture": the Vault path, why Direct-Vault is required, and the lease/renewal strategy.
-
----
-
-## Forbidden Patterns (CI Lint Targets)
-
-The following patterns are forbidden in all Mosaic projects. CI lint SHOULD catch these automatically (implementation tracked separately). Agents MUST NOT introduce these patterns.
-
-### 1. Untagged fallback defaults for required values
-
-```yaml
-# FORBIDDEN — required secret with silent fallback
-environment:
-  - DB_PASSWORD=${DB_PASSWORD:-changeme}
-  - API_KEY=${API_KEY:-}
-
-# REQUIRED — fast-fail on missing required values
-environment:
-  - DB_PASSWORD=${DB_PASSWORD:?DB_PASSWORD is required}
-  - API_KEY=${API_KEY:?API_KEY is required}
-
-# ALLOWED — true convenience default, tagged
-environment:
-  - PORT=${PORT:-3000}  # safe-default: non-secret, app works at any port
-```
-
-This applies to: `docker-compose.yml`, k8s manifests, Helm `values.yaml`, any env file committed to git.
-
-### 2. Vault KV calls in application source code (ESO-default projects)
-
-```python
-# FORBIDDEN in ESO-default apps — direct Vault client in app source
-import hvac
-client = hvac.Client(url=os.environ['VAULT_ADDR'])
-secret = client.secrets.kv.v2.read_secret_version(path='myapp/db')
-```
-
-ESO-default apps read env vars only. Direct-Vault clients belong only in apps with a documented dynamic-secrets justification in README.
-
-### 3. Hardcoded secrets or API keys in committed files
-
-```python
-# FORBIDDEN — hardcoded credential
-DB_PASSWORD = "supersecret123"
-API_KEY = "sk-live-abc123"
-```
-
-No exceptions. CI lint must flag any string matching common secret patterns (`password`, `secret`, `api_key`, `token` assigned a literal non-env-var value).
-
-### 4. `.env` files in production deployment paths
-
-```
-# FORBIDDEN — .env file in a production deploy path
-deploy/.env
-k8s/.env
-docker/.env
-
-# ALLOWED — local dev only
-.env.example          # template only, no real values
-.env                  # local dev, must be in .gitignore
-```
-
-`.env` files are acceptable in local-dev contexts only and MUST be in `.gitignore`. They are forbidden in any path that a CI pipeline or production deployment process reads directly.

packages/mosaic/framework/tools/_lib/credentials.sh

@@ -52,6 +52,20 @@ _mosaic_sync_woodpecker_env() {
   printf '%s\n' "$expected" > "$env_file"
 }
 
+# Load legacy flat Woodpecker credentials (.woodpecker.url / .woodpecker.token).
+# Some environments export WOODPECKER_INSTANCE=mosaic, but the current
+# credentials.json may still use the legacy flat schema. Treat "mosaic" as the
+# default flat instance when a nested .woodpecker.mosaic object is absent.
+_mosaic_load_woodpecker_legacy() {
+  export WOODPECKER_URL="$(_mosaic_read_cred '.woodpecker.url')"
+  export WOODPECKER_TOKEN="$(_mosaic_read_cred '.woodpecker.token')"
+  export WOODPECKER_INSTANCE="${WOODPECKER_INSTANCE:-mosaic}"
+  WOODPECKER_URL="${WOODPECKER_URL%/}"
+  [[ -n "$WOODPECKER_URL" ]] || { echo "Error: woodpecker.url not found" >&2; return 1; }
+  [[ -n "$WOODPECKER_TOKEN" ]] || { echo "Error: woodpecker.token not found" >&2; return 1; }
+  _mosaic_sync_woodpecker_env "$WOODPECKER_INSTANCE" "$WOODPECKER_URL" "$WOODPECKER_TOKEN"
+}
+
 load_credentials() {
   local service="$1"
 
@@ -155,7 +169,14 @@ EOF
       ;;
     woodpecker-*)
       local wp_instance="${service#woodpecker-}"
-      # credentials.json is authoritative — always read from it, ignore env
+      # credentials.json is authoritative — always read from it, ignore env.
+      # Backward compatibility: the default Mosaic Woodpecker instance may be
+      # stored in the legacy flat schema (.woodpecker.url/.token) instead of
+      # .woodpecker.mosaic.url/.token.
+      if [[ "$wp_instance" == "mosaic" ]] && [[ -z "$(_mosaic_read_cred '.woodpecker.mosaic.url')" ]] && [[ -n "$(_mosaic_read_cred '.woodpecker.url')" ]]; then
+        WOODPECKER_INSTANCE="mosaic" _mosaic_load_woodpecker_legacy
+        return $?
+      fi
       export WOODPECKER_URL="$(_mosaic_read_cred ".woodpecker.${wp_instance}.url")"
       export WOODPECKER_TOKEN="$(_mosaic_read_cred ".woodpecker.${wp_instance}.token")"
       export WOODPECKER_INSTANCE="$wp_instance"
@@ -166,7 +187,10 @@ EOF
       _mosaic_sync_woodpecker_env "$wp_instance" "$WOODPECKER_URL" "$WOODPECKER_TOKEN"
       ;;
     woodpecker)
-      # Resolve default instance, then load it
+      # Resolve default instance, then load it. If WOODPECKER_INSTANCE is set to
+      # "mosaic" by a shell/profile but credentials.json still uses the legacy
+      # flat .woodpecker.url/.token schema, load the flat credentials instead of
+      # failing with "woodpecker.mosaic.url not found".
       local wp_default
       wp_default="${WOODPECKER_INSTANCE:-$(_mosaic_read_cred '.woodpecker.default')}"
       if [[ -z "$wp_default" ]]; then
@@ -174,18 +198,18 @@ EOF
         local legacy_url
         legacy_url="$(_mosaic_read_cred '.woodpecker.url')"
         if [[ -n "$legacy_url" ]]; then
-          export WOODPECKER_URL="${WOODPECKER_URL:-$legacy_url}"
-          export WOODPECKER_TOKEN="${WOODPECKER_TOKEN:-$(_mosaic_read_cred '.woodpecker.token')}"
-          WOODPECKER_URL="${WOODPECKER_URL%/}"
-          [[ -n "$WOODPECKER_URL" ]] || { echo "Error: woodpecker.url not found" >&2; return 1; }
-          [[ -n "$WOODPECKER_TOKEN" ]] || { echo "Error: woodpecker.token not found" >&2; return 1; }
+          _mosaic_load_woodpecker_legacy
         else
           echo "Error: woodpecker.default not set and no WOODPECKER_INSTANCE env var" >&2
           echo "Available instances: $(jq -r '.woodpecker | keys | join(", ")' "$MOSAIC_CREDENTIALS_FILE" 2>/dev/null)" >&2
           return 1
         fi
       else
-        load_credentials "woodpecker-${wp_default}"
+        if [[ "$wp_default" == "mosaic" ]] && [[ -z "$(_mosaic_read_cred '.woodpecker.mosaic.url')" ]] && [[ -n "$(_mosaic_read_cred '.woodpecker.url')" ]]; then
+          WOODPECKER_INSTANCE="mosaic" _mosaic_load_woodpecker_legacy
+        else
+          load_credentials "woodpecker-${wp_default}"
+        fi
       fi
       ;;
     cloudflare-*)

packages/mosaic/framework/tools/git/issue-list.sh

@@ -1,6 +1,6 @@
 #!/bin/bash
 # issue-list.sh - List issues on Gitea or GitHub
-# Usage: issue-list.sh [-s state] [-l label] [-m milestone] [-a assignee]
+# Usage: issue-list.sh [-r owner/repo] [-s state] [-l label] [-m milestone] [-a assignee]
 
 set -e
 
@@ -13,6 +13,7 @@ LABEL=""
 MILESTONE=""
 ASSIGNEE=""
 LIMIT=100
+REPO_OVERRIDE=""
 
 usage() {
     cat <<EOF
@@ -26,12 +27,14 @@ Options:
     -m, --milestone NAME    Filter by milestone name
     -a, --assignee USER     Filter by assignee
     -n, --limit N           Maximum issues to show (default: 100)
+    -r, --repo OWNER/REPO   Repository slug (default: infer from git origin)
     -h, --help              Show this help message
 
 Examples:
     $(basename "$0")                          # List open issues
     $(basename "$0") -s all -l bug            # All issues with 'bug' label
     $(basename "$0") -m "0.2.0"               # Issues in milestone 0.2.0
+    $(basename "$0") --repo ddk/ai-bma         # List issues from anywhere
 EOF
     exit 1
 }
@@ -59,6 +62,10 @@ while [[ $# -gt 0 ]]; do
             LIMIT="$2"
             shift 2
             ;;
+        -r|--repo)
+            REPO_OVERRIDE="$2"
+            shift 2
+            ;;
         -h|--help)
             usage
             ;;
@@ -69,25 +76,33 @@ while [[ $# -gt 0 ]]; do
     esac
 done
 
-PLATFORM=$(detect_platform)
+if [[ -n "$REPO_OVERRIDE" ]]; then
+    REPO_INFO="$REPO_OVERRIDE"
+    PLATFORM=$(detect_platform 2>/dev/null || echo gitea)
+else
+    PLATFORM=$(detect_platform)
+    REPO_INFO=$(get_repo_info)
+fi
+
+if [[ -z "$REPO_INFO" || "$REPO_INFO" == error:* ]]; then
+    echo "Error: Could not determine repository from git origin. Run from a repo or pass --repo." >&2
+    exit 1
+fi
 
 case "$PLATFORM" in
     github)
-        CMD="gh issue list --state $STATE --limit $LIMIT"
-        [[ -n "$LABEL" ]] && CMD="$CMD --label \"$LABEL\""
-        [[ -n "$MILESTONE" ]] && CMD="$CMD --milestone \"$MILESTONE\""
-        [[ -n "$ASSIGNEE" ]] && CMD="$CMD --assignee \"$ASSIGNEE\""
-        eval "$CMD"
+        CMD=(gh issue list --repo "$REPO_INFO" --state "$STATE" --limit "$LIMIT")
+        [[ -n "$LABEL" ]] && CMD+=(--label "$LABEL")
+        [[ -n "$MILESTONE" ]] && CMD+=(--milestone "$MILESTONE")
+        [[ -n "$ASSIGNEE" ]] && CMD+=(--assignee "$ASSIGNEE")
+        "${CMD[@]}"
         ;;
     gitea)
-        CMD="tea issues list --state $STATE --limit $LIMIT"
-        [[ -n "$LABEL" ]] && CMD="$CMD --labels \"$LABEL\""
-        [[ -n "$MILESTONE" ]] && CMD="$CMD --milestones \"$MILESTONE\""
-        # Note: tea may not support assignee filter directly
-        eval "$CMD"
-        if [[ -n "$ASSIGNEE" ]]; then
-            echo "Note: Assignee filtering may require manual review for Gitea" >&2
-        fi
+        CMD=(tea issues list --repo "$REPO_INFO" --state "$STATE" --limit "$LIMIT")
+        [[ -n "$LABEL" ]] && CMD+=(--labels "$LABEL")
+        [[ -n "$MILESTONE" ]] && CMD+=(--milestones "$MILESTONE")
+        [[ -n "$ASSIGNEE" ]] && CMD+=(--assignee "$ASSIGNEE")
+        "${CMD[@]}"
         ;;
     *)
         echo "Error: Could not detect git platform" >&2

packages/mosaic/framework/tools/git/pr-ci-wait.sh

@@ -1,6 +1,6 @@
 #!/bin/bash
 # pr-ci-wait.sh - Wait for PR CI status to reach terminal state (GitHub/Gitea)
-# Usage: pr-ci-wait.sh -n <pr_number> [-t timeout_sec] [-i interval_sec]
+# Usage: pr-ci-wait.sh -n <pr_number> [-r owner/repo] [-t timeout_sec] [-i interval_sec]
 
 set -euo pipefail
 
@@ -10,6 +10,7 @@ source "$SCRIPT_DIR/detect-platform.sh"
 PR_NUMBER=""
 TIMEOUT_SEC=1800
 INTERVAL_SEC=15
+REPO_OVERRIDE=""
 
 usage() {
     cat <<EOF
@@ -17,12 +18,14 @@ Usage: $(basename "$0") -n <pr_number> [-t timeout_sec] [-i interval_sec]
 
 Options:
   -n, --number NUMBER      PR number (required)
+  -r, --repo OWNER/REPO    Repository slug (default: infer from git origin)
   -t, --timeout SECONDS    Max wait time in seconds (default: 1800)
   -i, --interval SECONDS   Poll interval in seconds (default: 15)
   -h, --help               Show this help
 
 Examples:
   $(basename "$0") -n 643
+  $(basename "$0") -n 643 --repo ddk/ai-bma
   $(basename "$0") -n 643 -t 900 -i 10
 EOF
 }
@@ -95,7 +98,7 @@ PY
 }
 
 github_get_pr_head_sha() {
-    gh pr view "$PR_NUMBER" --json headRefOid --jq '.headRefOid'
+    gh pr view "$PR_NUMBER" --repo "$OWNER/$REPO" --json headRefOid --jq '.headRefOid'
 }
 
 github_get_commit_status_json() {
@@ -132,6 +135,10 @@ while [[ $# -gt 0 ]]; do
             PR_NUMBER="$2"
             shift 2
             ;;
+        -r|--repo)
+            REPO_OVERRIDE="$2"
+            shift 2
+            ;;
         -t|--timeout)
             TIMEOUT_SEC="$2"
             shift 2
@@ -163,10 +170,21 @@ if ! [[ "$TIMEOUT_SEC" =~ ^[0-9]+$ ]] || ! [[ "$INTERVAL_SEC" =~ ^[0-9]+$ ]]; th
     exit 1
 fi
 
-detect_platform > /dev/null
+if [[ -n "$REPO_OVERRIDE" ]]; then
+    REPO_INFO="$REPO_OVERRIDE"
+    PLATFORM=$(detect_platform 2>/dev/null || echo gitea)
+else
+    detect_platform > /dev/null
+    REPO_INFO=$(get_repo_info)
+fi
 
-OWNER=$(get_repo_owner)
-REPO=$(get_repo_name)
+if [[ -z "$REPO_INFO" || "$REPO_INFO" == error:* || "$REPO_INFO" != */* ]]; then
+    echo "Error: Could not determine repository from git origin. Run from a repo or pass --repo owner/repo." >&2
+    exit 1
+fi
+
+OWNER=${REPO_INFO%%/*}
+REPO=${REPO_INFO##*/}
 START_TS=$(date +%s)
 DEADLINE_TS=$((START_TS + TIMEOUT_SEC))
 
@@ -182,10 +200,7 @@ if [[ "$PLATFORM" == "github" ]]; then
     fi
     echo "[pr-ci-wait] Platform=github PR=#${PR_NUMBER} head_sha=${HEAD_SHA}"
 elif [[ "$PLATFORM" == "gitea" ]]; then
-    HOST=$(get_remote_host) || {
-        echo "Error: Could not determine remote host." >&2
-        exit 1
-    }
+    HOST=$(get_remote_host 2>/dev/null || echo "git.mosaicstack.dev")
     TOKEN=$(get_gitea_token "$HOST") || {
         echo "Error: Gitea token not found. Set GITEA_TOKEN or configure ~/.git-credentials." >&2
         exit 1
@@ -195,7 +210,7 @@ elif [[ "$PLATFORM" == "gitea" ]]; then
         echo "Error: Could not resolve head SHA for PR #$PR_NUMBER." >&2
         exit 1
     fi
-    echo "[pr-ci-wait] Platform=gitea host=${HOST} PR=#${PR_NUMBER} head_sha=${HEAD_SHA}"
+    echo "[pr-ci-wait] Platform=gitea host=${HOST} repo=${OWNER}/${REPO} PR=#${PR_NUMBER} head_sha=${HEAD_SHA}"
 else
     echo "Error: Unsupported platform '${PLATFORM}'." >&2
     exit 1

packages/mosaic/framework/tools/git/pr-diff.sh

@@ -1,6 +1,6 @@
 #!/bin/bash
 # pr-diff.sh - Get the diff for a pull request on GitHub or Gitea
-# Usage: pr-diff.sh -n <pr_number> [-o <output_file>]
+# Usage: pr-diff.sh -n <pr_number> [-r owner/repo] [-o <output_file>]
 
 set -e
 
@@ -10,6 +10,7 @@ source "$SCRIPT_DIR/detect-platform.sh"
 # Parse arguments
 PR_NUMBER=""
 OUTPUT_FILE=""
+REPO_OVERRIDE=""
 
 while [[ $# -gt 0 ]]; do
     case $1 in
@@ -21,11 +22,16 @@ while [[ $# -gt 0 ]]; do
             OUTPUT_FILE="$2"
             shift 2
             ;;
+        -r|--repo)
+            REPO_OVERRIDE="$2"
+            shift 2
+            ;;
         -h|--help)
-            echo "Usage: pr-diff.sh -n <pr_number> [-o <output_file>]"
+            echo "Usage: pr-diff.sh -n <pr_number> [-r owner/repo] [-o <output_file>]"
             echo ""
             echo "Options:"
             echo "  -n, --number   PR number (required)"
+            echo "  -r, --repo     Repository slug (default: infer from git origin)"
             echo "  -o, --output   Output file (optional, prints to stdout if omitted)"
             echo "  -h, --help     Show this help"
             exit 0
@@ -42,31 +48,30 @@ if [[ -z "$PR_NUMBER" ]]; then
     exit 1
 fi
 
-detect_platform > /dev/null
+if [[ -n "$REPO_OVERRIDE" ]]; then
+    REPO_INFO="$REPO_OVERRIDE"
+    PLATFORM=$(detect_platform 2>/dev/null || echo gitea)
+else
+    detect_platform > /dev/null
+    REPO_INFO=$(get_repo_info)
+fi
+
+if [[ -z "$REPO_INFO" || "$REPO_INFO" == error:* ]]; then
+    echo "Error: Could not determine repository from git origin. Run from a repo or pass --repo." >&2
+    exit 1
+fi
 
 if [[ "$PLATFORM" == "github" ]]; then
     if [[ -n "$OUTPUT_FILE" ]]; then
-        gh pr diff "$PR_NUMBER" > "$OUTPUT_FILE"
+        gh pr diff "$PR_NUMBER" --repo "$REPO_INFO" > "$OUTPUT_FILE"
     else
-        gh pr diff "$PR_NUMBER"
+        gh pr diff "$PR_NUMBER" --repo "$REPO_INFO"
     fi
 elif [[ "$PLATFORM" == "gitea" ]]; then
     # tea doesn't have a direct diff command — use the API
-    OWNER=$(get_repo_owner)
-    REPO=$(get_repo_name)
-    REMOTE_URL=$(git remote get-url origin 2>/dev/null)
+    HOST=$(get_remote_host 2>/dev/null || echo "git.mosaicstack.dev")
 
-    # Extract host from remote URL
-    if [[ "$REMOTE_URL" == https://* ]]; then
-        HOST=$(echo "$REMOTE_URL" | sed -E 's|https://([^/]+)/.*|\1|')
-    elif [[ "$REMOTE_URL" == git@* ]]; then
-        HOST=$(echo "$REMOTE_URL" | sed -E 's|git@([^:]+):.*|\1|')
-    else
-        echo "Error: Cannot determine host from remote URL" >&2
-        exit 1
-    fi
-
-    DIFF_URL="https://${HOST}/api/v1/repos/${OWNER}/${REPO}/pulls/${PR_NUMBER}.diff"
+    DIFF_URL="https://${HOST}/api/v1/repos/${REPO_INFO}/pulls/${PR_NUMBER}.diff"
 
     GITEA_API_TOKEN=$(get_gitea_token "$HOST" || true)
 

packages/mosaic/framework/tools/git/pr-list.sh

@@ -1,6 +1,6 @@
 #!/bin/bash
 # pr-list.sh - List pull requests on Gitea or GitHub
-# Usage: pr-list.sh [-s state] [-l label] [-a author]
+# Usage: pr-list.sh [-r owner/repo] [-s state] [-l label] [-a author]
 
 set -e
 
@@ -12,6 +12,7 @@ STATE="open"
 LABEL=""
 AUTHOR=""
 LIMIT=100
+REPO_OVERRIDE=""
 
 usage() {
     cat <<EOF
@@ -24,12 +25,14 @@ Options:
     -l, --label LABEL       Filter by label
     -a, --author USER       Filter by author
     -n, --limit N           Maximum PRs to show (default: 100)
+    -r, --repo OWNER/REPO   Repository slug (default: infer from git origin)
     -h, --help              Show this help message
 
 Examples:
     $(basename "$0")                          # List open PRs
     $(basename "$0") -s all                   # All PRs
     $(basename "$0") -s merged -a username    # Merged PRs by user
+    $(basename "$0") --repo ddk/ai-bma         # List PRs from anywhere
 EOF
     exit 1
 }
@@ -53,6 +56,10 @@ while [[ $# -gt 0 ]]; do
             LIMIT="$2"
             shift 2
             ;;
+        -r|--repo)
+            REPO_OVERRIDE="$2"
+            shift 2
+            ;;
         -h|--help)
             usage
             ;;
@@ -63,18 +70,30 @@ while [[ $# -gt 0 ]]; do
     esac
 done
 
-PLATFORM=$(detect_platform)
+if [[ -n "$REPO_OVERRIDE" ]]; then
+    REPO_INFO="$REPO_OVERRIDE"
+    # Explicit --repo is primarily for Gitea wrappers; if a git origin is present,
+    # still honor GitHub detection for cross-platform behavior.
+    PLATFORM=$(detect_platform 2>/dev/null || echo gitea)
+else
+    PLATFORM=$(detect_platform)
+    REPO_INFO=$(get_repo_info)
+fi
+
+if [[ -z "$REPO_INFO" || "$REPO_INFO" == error:* ]]; then
+    echo "Error: Could not determine repository from git origin. Run from a repo or pass --repo." >&2
+    exit 1
+fi
 
 case "$PLATFORM" in
     github)
-        CMD="gh pr list --state $STATE --limit $LIMIT"
-        [[ -n "$LABEL" ]] && CMD="$CMD --label \"$LABEL\""
-        [[ -n "$AUTHOR" ]] && CMD="$CMD --author \"$AUTHOR\""
-        eval "$CMD"
+        CMD=(gh pr list --repo "$REPO_INFO" --state "$STATE" --limit "$LIMIT")
+        [[ -n "$LABEL" ]] && CMD+=(--label "$LABEL")
+        [[ -n "$AUTHOR" ]] && CMD+=(--author "$AUTHOR")
+        "${CMD[@]}"
         ;;
     gitea)
-        # tea pr list - note: tea uses 'pulls' subcommand in some versions
-        CMD="tea pr list --state $STATE --limit $LIMIT"
+        CMD=(tea pr list --repo "$REPO_INFO" --state "$STATE" --limit "$LIMIT")
 
         # tea filtering may be limited
         if [[ -n "$LABEL" ]]; then
@@ -84,7 +103,7 @@ case "$PLATFORM" in
             echo "Note: Author filtering may require manual review for Gitea" >&2
         fi
 
-        eval "$CMD"
+        "${CMD[@]}"
         ;;
     *)
         echo "Error: Could not detect git platform" >&2

packages/mosaic/framework/tools/git/pr-view.sh

@@ -1,6 +1,6 @@
 #!/bin/bash
 # pr-view.sh - View pull request details on GitHub or Gitea
-# Usage: pr-view.sh -n <pr_number>
+# Usage: pr-view.sh -n <pr_number> [-r owner/repo]
 
 set -e
 
@@ -9,6 +9,7 @@ source "$SCRIPT_DIR/detect-platform.sh"
 
 # Parse arguments
 PR_NUMBER=""
+REPO_OVERRIDE=""
 
 while [[ $# -gt 0 ]]; do
     case $1 in
@@ -16,11 +17,16 @@ while [[ $# -gt 0 ]]; do
             PR_NUMBER="$2"
             shift 2
             ;;
+        -r|--repo)
+            REPO_OVERRIDE="$2"
+            shift 2
+            ;;
         -h|--help)
-            echo "Usage: pr-view.sh -n <pr_number>"
+            echo "Usage: pr-view.sh -n <pr_number> [-r owner/repo]"
             echo ""
             echo "Options:"
             echo "  -n, --number   PR number (required)"
+            echo "  -r, --repo     Repository slug (default: infer from git origin)"
             echo "  -h, --help     Show this help"
             exit 0
             ;;
@@ -36,12 +42,23 @@ if [[ -z "$PR_NUMBER" ]]; then
     exit 1
 fi
 
-detect_platform
+if [[ -n "$REPO_OVERRIDE" ]]; then
+    REPO_INFO="$REPO_OVERRIDE"
+    PLATFORM=$(detect_platform 2>/dev/null || echo gitea)
+else
+    detect_platform > /dev/null
+    REPO_INFO=$(get_repo_info)
+fi
+
+if [[ -z "$REPO_INFO" || "$REPO_INFO" == error:* ]]; then
+    echo "Error: Could not determine repository from git origin. Run from a repo or pass --repo." >&2
+    exit 1
+fi
 
 if [[ "$PLATFORM" == "github" ]]; then
-    gh pr view "$PR_NUMBER"
+    gh pr view "$PR_NUMBER" --repo "$REPO_INFO"
 elif [[ "$PLATFORM" == "gitea" ]]; then
-    tea pr "$PR_NUMBER"
+    tea pr "$PR_NUMBER" --repo "$REPO_INFO"
 else
     echo "Error: Unknown platform"
     exit 1

packages/mosaic/framework/tools/woodpecker/pipeline-list.sh

@@ -50,7 +50,7 @@ REPO_ID=$(wp_resolve_repo_id "$REPO") || exit 1
 
 response=$(curl -sk -w "\n%{http_code}" \
   -H "Authorization: Bearer $WOODPECKER_TOKEN" \
-  "${WOODPECKER_URL}/api/repos/${REPO_ID}/pipelines?per_page=${LIMIT}")
+  "${WOODPECKER_URL}/api/repos/${REPO_ID}/pipelines?perPage=${LIMIT}")
 
 http_code=$(echo "$response" | tail -n1)
 body=$(echo "$response" | sed '$d')

packages/mosaic/framework/tools/woodpecker/pipeline-status.sh

@@ -64,7 +64,7 @@ _wp_fetch() {
 
 if [[ -z "$NUMBER" ]]; then
   # Get latest pipeline number from list, then fetch full detail
-  list_body=$(_wp_fetch "${WOODPECKER_URL}/api/repos/${REPO_ID}/pipelines?per_page=1") || exit 1
+  list_body=$(_wp_fetch "${WOODPECKER_URL}/api/repos/${REPO_ID}/pipelines?perPage=1") || exit 1
   NUMBER=$(echo "$list_body" | jq -r '.[0].number // empty')
   if [[ -z "$NUMBER" ]]; then
     echo "Error: No pipelines found" >&2