Temper v1 Greenfield Product and Architecture #29

New issue

Open

opened 2026-07-14 22:37:31 -04:00 by caleb-brown · 0 comments

caleb-brown commented

2026-07-14 22:37:31 -04:00

Owner

Destination

An implementation-ready product and architecture specification for a production-capable, self-hosted, Forgejo-first Temper v1—clear enough to rebuild from an empty repository with no major product, domain, security, UX, or operational decisions unresolved.

Notes

This is a planning map. It resolves decisions and produces specification artifacts; it does not implement the production app.
Rebuild greenfield. The prototype is behavioral evidence and a source of risks, not the implementation baseline, and its code, schema, and accidental behaviors carry no compatibility requirement.
One organization operates each Temper Deployment for multiple repositories and potentially multiple Forgejo hosts. A small set of trusted Temper Operators administers it; developers interact through Forgejo pull requests.
Temper v1 is a pull-request review product and supports Forgejo only. Keep a clean internal Forgejo seam without designing a generic SCM plugin system.
Optimize for high-signal Forgejo-native feedback, operator recoverability, explicit trust and data boundaries, and visible degradation rather than silent truncation or failure.
Each ticket owns its eventual answer. Recommendations from the prototype and initial deliberation are hypotheses until recorded in that ticket's resolution.
Use the grilling and domain-modeling skills for product and domain decisions, research against primary sources for Forgejo facts, prototype for state models and UX, and codebase-design when choosing module seams.

Decisions so far

Not yet specified

Follow-on compatibility decisions exposed by real Forgejo capability testing, including version-specific fallbacks that cannot yet be named precisely.
Follow-on interaction and remediation questions exposed by the Forgejo feedback and Temper Operator prototypes, especially edge cases not visible until those journeys are concrete.
Follow-on security controls and operational limits exposed by the trust model, failure analysis, and selected runtime architecture.
Narrow investigations into review decomposition, cross-file reasoning, and coverage reconciliation if the quality criteria and model-execution prototype show they are needed.

Out of scope

Implementing the production application during this map, or migrating prototype code, schema, or data.
GitHub, GitLab, Gitea, and generic SCM/plugin compatibility beyond a clean internal Forgejo boundary.
Hosted SaaS, multi-tenant organization isolation, billing, public signup, and developer-facing Temper accounts or dashboards.
Issue triage, arbitrary commit review, repository chat, IDE features, code generation or patch application, autonomous agents, and merge automation.
Treating model findings as approval, a request for changes, or an authoritative merge gate.
Built-in model hosting, training, fine-tuning, multi-provider routing, and automatic fallback.
Executing or cloning pull-request code and building a language-specific linter or static-analyzer ecosystem.
Enterprise RBAC, SSO/SCIM, compliance certification, multi-region active-active operation, and a v1 zero-downtime or high-availability SLA.

## Destination An implementation-ready product and architecture specification for a production-capable, self-hosted, Forgejo-first Temper v1—clear enough to rebuild from an empty repository with no major product, domain, security, UX, or operational decisions unresolved. ## Notes - This is a planning map. It resolves decisions and produces specification artifacts; it does not implement the production app. - Rebuild greenfield. The prototype is behavioral evidence and a source of risks, not the implementation baseline, and its code, schema, and accidental behaviors carry no compatibility requirement. - One organization operates each Temper Deployment for multiple repositories and potentially multiple Forgejo hosts. A small set of trusted Temper Operators administers it; developers interact through Forgejo pull requests. - Temper v1 is a pull-request review product and supports Forgejo only. Keep a clean internal Forgejo seam without designing a generic SCM plugin system. - Optimize for high-signal Forgejo-native feedback, operator recoverability, explicit trust and data boundaries, and visible degradation rather than silent truncation or failure. - Each ticket owns its eventual answer. Recommendations from the prototype and initial deliberation are hypotheses until recorded in that ticket's resolution. - Use the grilling and domain-modeling skills for product and domain decisions, research against primary sources for Forgejo facts, prototype for state models and UX, and codebase-design when choosing module seams. ## Decisions so far  ## Not yet specified - Follow-on compatibility decisions exposed by real Forgejo capability testing, including version-specific fallbacks that cannot yet be named precisely. - Follow-on interaction and remediation questions exposed by the Forgejo feedback and Temper Operator prototypes, especially edge cases not visible until those journeys are concrete. - Follow-on security controls and operational limits exposed by the trust model, failure analysis, and selected runtime architecture. - Narrow investigations into review decomposition, cross-file reasoning, and coverage reconciliation if the quality criteria and model-execution prototype show they are needed. ## Out of scope - Implementing the production application during this map, or migrating prototype code, schema, or data. - GitHub, GitLab, Gitea, and generic SCM/plugin compatibility beyond a clean internal Forgejo boundary. - Hosted SaaS, multi-tenant organization isolation, billing, public signup, and developer-facing Temper accounts or dashboards. - Issue triage, arbitrary commit review, repository chat, IDE features, code generation or patch application, autonomous agents, and merge automation. - Treating model findings as approval, a request for changes, or an authoritative merge gate. - Built-in model hosting, training, fine-tuning, multi-provider routing, and automatic fallback. - Executing or cloning pull-request code and building a language-specific linter or static-analyzer ecosystem. - Enterprise RBAC, SSO/SCIM, compliance certification, multi-region active-active operation, and a v1 zero-downtime or high-availability SLA.

caleb-brown added the

wayfinder:map

label

Rows
Columns