docs: add ugig.net gig postings for each launch PRD

docs/prds/gigs/00-detection-data-model-ugig.md

@@ -0,0 +1,40 @@
+# Build the ThreatCrush detection data model & event ingest
+
+> ugig.net gig posting — implements [PRD-00](../00-detection-data-model.md)
+
+- **Title:** Build the ThreatCrush detection data model & event ingest
+- **Skills required:** `postgres`, `supabase`, `sql`, `rls`, `typescript`, `nextjs`, `zod`, `api-design`
+- **Budget type:** fixed
+- **Budget (USD):** 1,200 – 2,000
+- **Repo:** https://github.com/profullstack/threatcrush · branch `feat/detection-data-model`
+- **Spec:** `docs/prds/00-detection-data-model.md`
+
+## What we need
+
+The backbone every other detection feature depends on. ThreatCrush's shipped
+schema has servers/properties but **none** of the detection tables the product
+is built around. We need the data model plus one authenticated, normalized
+ingest path the daemon writes to — privacy-first (normalized detections only, no
+raw logs by default).
+
+## Scope
+
+1. One Supabase migration adding `detections`, `remediation_actions`,
+   `hardening_findings`, `allowlists`, `alert_destinations`, `alert_rules`,
+   `rule_registry` (columns per the PRD), org-scoped with RLS that mirrors the
+   existing `organizations_and_servers` policies.
+2. `POST /api/events` — validate a batch of normalized detection + heartbeat
+   payloads against a shared zod schema (exported from `apps/sdk`), upsert into
+   `detections`, update `servers.last_seen_at`. Agent auth via the existing
+   server enrollment token / API key.
+3. Read endpoints: `GET /api/servers/[id]/detections|findings|remediations`.
+4. The shared payload schema lives in `apps/sdk` and is imported by both the web
+   API and the CLI (no duplicate definitions).
+
+## Acceptance criteria
+
+- Migration applies cleanly; RLS verified with a cross-org test (no leakage).
+- Daemon can POST a normalized detection and it appears in `detections`.
+- No raw log lines are stored unless explicitly opted in.
+- PR with green CI and the shared schema wired into both web + CLI.
+</content>

docs/prds/gigs/01-detection-rule-engine-ugig.md

@@ -0,0 +1,39 @@
+# Build the ThreatCrush detection rule engine & rule packs
+
+> ugig.net gig posting — implements [PRD-01](../01-detection-rule-engine.md)
+
+- **Title:** Build the ThreatCrush detection rule engine & rule packs
+- **Skills required:** `typescript`, `nodejs`, `linux`, `security`, `log-parsing`, `json-schema`, `vitest`, `ci`
+- **Budget type:** fixed
+- **Budget (USD):** 2,000 – 3,500
+- **Repo:** https://github.com/profullstack/threatcrush · branch `feat/detection-rule-engine`
+- **Spec:** `docs/prds/01-detection-rule-engine.md`
+
+## What we need
+
+Detections today are hardcoded inside the `ssh-guard` module. We need a typed,
+declarative rule format and an engine that evaluates rules over event windows
+from the daemon's watchers — so detections are versioned, auditable, and
+community-editable instead of buried in code.
+
+## Scope
+
+1. A typed rule schema (defined in `apps/sdk`): id, title, description,
+   source_types, match conditions, threshold, window, severity, remediation
+   suggestions, tags, distro/service compatibility.
+2. An engine that consumes normalized events from `apps/cli/src/daemon/watchers`,
+   maintains sliding windows, and emits detections conforming to PRD-00.
+3. A curated default rule pack (auth/ssh/recon) loaded at daemon start; operator
+   overrides from `/etc/threatcrush/rules.d/`.
+4. Per-rule + per-source suppression/cooldown to cut noise; register loaded rules
+   into `rule_registry`.
+5. `threatcrush rules list|show <id>|test <fixture>`; CI that validates every
+   shipped rule and runs log-fixture tests.
+
+## Acceptance criteria
+
+- `ssh-guard`'s current detections reproduced from rules with no regression.
+- Suppression demonstrably collapses repeat events.
+- CI validates all rules + fixtures; rule schema published from `apps/sdk`.
+- PR with green CI and docs for authoring a rule.
+</content>

docs/prds/gigs/02-firewall-auto-remediation-ugig.md

@@ -0,0 +1,38 @@
+# Build ThreatCrush firewall auto-remediation (nftables/iptables)
+
+> ugig.net gig posting — implements [PRD-02](../02-firewall-auto-remediation.md)
+
+- **Title:** Build ThreatCrush firewall auto-remediation (nftables/iptables)
+- **Skills required:** `typescript`, `nodejs`, `linux`, `nftables`, `iptables`, `networking`, `security`, `systemd`
+- **Budget type:** fixed
+- **Budget (USD):** 1,800 – 3,000
+- **Repo:** https://github.com/profullstack/threatcrush · branch `feat/firewall-remediation`
+- **Spec:** `docs/prds/02-firewall-auto-remediation.md`
+
+## What we need
+
+The product's central promise — "what the tool already blocked" — is currently
+vapor: there is zero firewall code. Build the `firewall-rules` module that blocks
+offending IPs in response to detections, safe-by-default, with a clean audit
+trail synced to `remediation_actions`.
+
+## Scope
+
+1. Firewall adapters: nftables first, iptables fallback, auto-detected behind a
+   generic interface.
+2. Actions: temporary ban (with expiry), permanent blocklist, unblock; a daemon
+   worker that unblocks expired bans (mirror the existing `runs-worker`).
+3. Dry-run mode (default until opted in), allowlist enforcement (reads
+   `allowlists`), full local + server-synced audit trail.
+4. Graceful `EACCES` handling when the daemon lacks `CAP_NET_ADMIN` — surface a
+   hardening recommendation instead of crashing.
+5. CLI: `threatcrush block <ip> [--ttl] | unblock <ip> | blocklist |
+   allowlist add|remove`; `[remediation]` config block in `threatcrushd.conf`.
+
+## Acceptance criteria
+
+- nftables + iptables adapters pass integration tests in a container.
+- Dry-run writes an audit entry but makes no firewall change.
+- Allowlisted IP is never blocked; expired bans auto-clear; manual unblock works.
+- Actions surface in the dashboard via `remediation_actions`. PR with green CI.
+</content>

docs/prds/gigs/03-hardening-scanner-ugig.md

@@ -0,0 +1,34 @@
+# Build the ThreatCrush hardening scanner
+
+> ugig.net gig posting — implements [PRD-03](../03-hardening-scanner.md)
+
+- **Title:** Build the ThreatCrush hardening scanner
+- **Skills required:** `typescript`, `nodejs`, `linux`, `ssh-hardening`, `security`, `sysadmin`, `vitest`
+- **Budget type:** fixed
+- **Budget (USD):** 1,500 – 2,500
+- **Repo:** https://github.com/profullstack/threatcrush · branch `feat/hardening-scanner`
+- **Spec:** `docs/prds/03-hardening-scanner.md`
+
+## What we need
+
+A key differentiator and an MVP feature that doesn't exist yet: a local hardening
+scanner that runs on enrollment and on demand, producing plain-English findings
+with recommended fixes and a per-server hardening score.
+
+## Scope
+
+1. The nine initial checks from the PRD: SSH password auth, root SSH login, weak
+   SSH config, missing auto security updates, firewall inactive, exposed ports,
+   fail2ban present, world-writable sensitive dirs, risky service exposure.
+2. Each check returns key, severity, status (pass/warn/fail), explanation, fix.
+3. `threatcrush harden` (color report) + `threatcrush harden --json`; auto-run
+   after `init`/enrollment; results synced to `hardening_findings` (PRD-00).
+4. A hardening score surfaced in `threatcrush status` and the dashboard.
+
+## Acceptance criteria
+
+- All nine checks implemented with fix guidance; runs without root where possible
+  and degrades gracefully on `EACCES`.
+- Findings persist to `hardening_findings`; score computed and shown in `status`.
+- PR with green CI and unit tests covering each check's pass/fail logic.
+</content>

docs/prds/gigs/04-network-monitor-module-ugig.md

@@ -0,0 +1,35 @@
+# Build the ThreatCrush network monitor module
+
+> ugig.net gig posting — implements [PRD-04](../04-network-monitor-module.md)
+
+- **Title:** Build the ThreatCrush network monitor module
+- **Skills required:** `typescript`, `nodejs`, `linux`, `networking`, `conntrack`, `security`, `performance`
+- **Budget type:** fixed
+- **Budget (USD):** 2,000 – 3,500
+- **Repo:** https://github.com/profullstack/threatcrush · branch `feat/network-monitor`
+- **Spec:** `docs/prds/04-network-monitor-module.md`
+
+## What we need
+
+The README's hero output shows port scans and SYN floods detected across "every
+port" and lists `network-monitor` as a bundled module — but it doesn't exist.
+Build a lightweight connection-level monitor (no heavy DPI) that powers the
+headline detections.
+
+## Scope
+
+1. A connection source adapter (prefer conntrack / `ss` / `/proc/net/*`;
+   document privilege needs) — low idle CPU/memory.
+2. Port-scan heuristic (many ports / short window / single source) and SYN-flood
+   heuristic (half-open ratio).
+3. Thresholds driven by the rule engine (PRD-01), not hardcoded; detections flow
+   to `detections` (PRD-00) and can trigger firewall bans (PRD-02).
+4. Graceful `EACCES` degradation.
+
+## Acceptance criteria
+
+- A simulated `nmap` scan against the host is detected within the configured
+  window and (if enabled) triggers a ban.
+- Idle overhead stays within the PRD perf budget.
+- PR with green CI and a fixture-based test for the scan/flood heuristics.
+</content>

docs/prds/gigs/05-dns-monitor-module-ugig.md

@@ -0,0 +1,31 @@
+# Build the ThreatCrush DNS monitor module
+
+> ugig.net gig posting — implements [PRD-05](../05-dns-monitor-module.md)
+
+- **Title:** Build the ThreatCrush DNS monitor module
+- **Skills required:** `typescript`, `nodejs`, `linux`, `dns`, `security`, `entropy-analysis`
+- **Budget type:** fixed
+- **Budget (USD):** 1,500 – 2,500
+- **Repo:** https://github.com/profullstack/threatcrush · branch `feat/dns-monitor`
+- **Spec:** `docs/prds/05-dns-monitor-module.md`
+
+## What we need
+
+The README claims DNS-tunneling/DGA detection and lists `dns-monitor` as a
+bundled module — it doesn't exist. Build the module that catches DNS-based
+exfiltration and DGA beaconing.
+
+## Scope
+
+1. A DNS event source (resolver/query logs or passive `:53` observation);
+   document what each environment realistically provides.
+2. Tunneling heuristics: TXT query rate, label length, entropy thresholds.
+3. DGA heuristics: domain entropy / n-gram / dictionary checks.
+4. Thresholds via the rule engine (PRD-01); detections to `detections` (PRD-00).
+
+## Acceptance criteria
+
+- A scripted DNS-tunneling pattern and a high-entropy DGA burst are both flagged.
+- Low false positives against a normal-traffic fixture corpus.
+- PR with green CI and the fixture corpus committed.
+</content>

docs/prds/gigs/06-code-scanner-engine-ugig.md

@@ -0,0 +1,36 @@
+# Mature the ThreatCrush code scanner engine
+
+> ugig.net gig posting — implements [PRD-06](../06-code-scanner-engine.md)
+
+- **Title:** Mature the ThreatCrush code scanner engine
+- **Skills required:** `typescript`, `nodejs`, `static-analysis`, `security`, `secrets-detection`, `cve`, `llm-integration`
+- **Budget type:** fixed
+- **Budget (USD):** 2,000 – 3,500
+- **Repo:** https://github.com/profullstack/threatcrush · branch `feat/code-scanner`
+- **Spec:** `docs/prds/06-code-scanner-engine.md`
+
+## What we need
+
+`threatcrush scan ./src` exists but its coverage needs to reach launch quality
+and match the README's claims (vulnerabilities, secrets, misconfig, dependency
+CVEs) plus the usage-billed `scan.deep` AI tier.
+
+## Scope
+
+1. Secrets (entropy + known-token regexes, with allowlist), language-aware static
+   risky-call detection (JS/TS, Python first), common misconfig checks.
+2. Dependency CVEs: parse lockfiles, check against an advisory source (OSV /
+   GitHub Advisory DB).
+3. `scan.deep`: AI-assisted triage, metered via CoinPayPortal, explicit opt-in;
+   default model = latest Claude (Opus 4.8) per repo guidance; degrade to the free
+   scan when no keys/credits.
+4. Output: `--json`, severity per finding, CI-friendly exit codes; optional
+   persistence of findings for the dashboard.
+
+## Acceptance criteria
+
+- Documented coverage matrix; README claims match implemented checks.
+- Secrets + dependency-CVE detection verified against a seeded fixture repo.
+- `scan.deep` gated behind opt-in + billing; gracefully degrades without keys.
+- PR with green CI.
+</content>

docs/prds/gigs/07-pentest-engine-ugig.md

@@ -0,0 +1,35 @@
+# Mature the ThreatCrush pentest engine
+
+> ugig.net gig posting — implements [PRD-07](../07-pentest-engine.md)
+
+- **Title:** Mature the ThreatCrush pentest engine
+- **Skills required:** `typescript`, `nodejs`, `web-security`, `owasp`, `pentesting`, `api-fuzzing`, `security`
+- **Budget type:** fixed
+- **Budget (USD):** 2,500 – 4,000
+- **Repo:** https://github.com/profullstack/threatcrush · branch `feat/pentest-engine`
+- **Spec:** `docs/prds/07-pentest-engine.md`
+
+## What we need
+
+`threatcrush pentest URL` is wired into the web `properties`/`property_runs`
+model, but the engine's check coverage needs a documented, launch-quality suite
+with strict "authorized targets only" guardrails (testing the user's own
+properties).
+
+## Scope
+
+1. Authorization gate: only run against verified/owned properties; record consent
+   (tie to the existing property-ownership verification).
+2. Check suite: SQLi, reflected/stored XSS, SSRF, open redirect, security
+   headers, basic API fuzzing — documented with severity mapping.
+3. Safety: rate limits, non-destructive probes, scope/robots respect.
+4. Parity: identical engine for CLI `pentest` and server-scheduled `property_runs`;
+   findings conform to the schema the property detail page + CSV export consume.
+
+## Acceptance criteria
+
+- CLI and scheduled runs produce identical findings for the same target.
+- Authorization guardrail blocks scanning of unverified domains.
+- Documented check coverage; README claims match.
+- PR with green CI; findings render in property detail + CSV export.
+</content>

docs/prds/gigs/08-alerting-and-alert-rules-ugig.md

@@ -0,0 +1,35 @@
+# Build ThreatCrush alerting channels & alert rules
+
+> ugig.net gig posting — implements [PRD-08](../08-alerting-and-alert-rules.md)
+
+- **Title:** Build ThreatCrush alerting channels & alert rules
+- **Skills required:** `typescript`, `nodejs`, `slack-api`, `discord-api`, `pagerduty`, `supabase`, `security`
+- **Budget type:** fixed
+- **Budget (USD):** 1,500 – 2,500
+- **Repo:** https://github.com/profullstack/threatcrush · branch `feat/alerting-rules`
+- **Spec:** `docs/prds/08-alerting-and-alert-rules.md`
+
+## What we need
+
+The README promises Slack, Discord, email, webhook, and PagerDuty alerts, but the
+daemon ships only SMTP/webhook/Slack and has no alert-rules layer (no
+thresholding, severity filtering, per-server subscriptions, or rate limiting).
+Add the missing channels and the rules engine behind them.
+
+## Scope
+
+1. New channels: Discord webhook + PagerDuty Events API (keep Slack/webhook/SMTP)
+   in `apps/cli/src/daemon/alerts`.
+2. `alert_destinations` + `alert_rules` (PRD-00) as the backing model; routing: a
+   detection matches 0..n rules → fan out to mapped destinations.
+3. Rate limiting + thresholding per rule/destination; coalesce bursts.
+4. Config sync: daemon reads org-scoped rules from the server, falls back to
+   `threatcrushd.conf` for local-only mode.
+
+## Acceptance criteria
+
+- Discord + PagerDuty deliver a test alert.
+- A medium-severity detection does not page a high-only rule; per-server
+  subscription routes only that server's alerts; a flood is capped to the limit.
+- PR with green CI.
+</content>

docs/prds/gigs/09-module-sdk-and-publish-ugig.md

@@ -0,0 +1,35 @@
+# Build & publish the ThreatCrush module SDK (`@threatcrush/sdk`)
+
+> ugig.net gig posting — implements [PRD-09](../09-module-sdk-and-publish.md)
+
+- **Title:** Build & publish the ThreatCrush module SDK (`@threatcrush/sdk`)
+- **Skills required:** `typescript`, `nodejs`, `sdk-design`, `npm-publishing`, `json-schema`, `docs`
+- **Budget type:** fixed
+- **Budget (USD):** 1,500 – 2,500
+- **Repo:** https://github.com/profullstack/threatcrush · branch `feat/module-sdk`
+- **Spec:** `docs/prds/09-module-sdk-and-publish.md`
+
+## What we need
+
+`@threatcrush/sdk` is 146 lines of types, marked alpha, and unpublished —
+blocking community module authoring. Define and freeze the public module
+contract, publish it, and document authoring.
+
+## Scope
+
+1. Manifest spec (name, version, kind, entrypoint, config schema, compatibility,
+   declared capabilities) and typed lifecycle hooks (init/start/stop, event
+   subscription, detection emit, remediation request).
+2. Re-export the shared detection/rule/alert/ingest schemas (PRD-00, PRD-01) so
+   authors and the platform share one source of truth — imported by web API + CLI.
+3. Publish `@threatcrush/sdk` to npm (public) with semver + changelog, wired into
+   CI.
+4. Authoring guide + an `examples/` starter module.
+
+## Acceptance criteria
+
+- `npm i @threatcrush/sdk` works; types resolve.
+- A starter module built only against the published SDK loads in `module-host`.
+- Web API and CLI both import the shared schemas from the SDK (no duplication).
+- PR with green CI and published docs.
+</content>