LogBook Institution
A Go and Next.js academic LMS/ERP foundation with JWT-derived tenant context, modular services, and explicit progress limits.
tenant-aware LMS backend
system flowVerified identity establishes organization context before domain handlers run.
The problem
LogBook Institution is a Go/Next.js multi-tenant university LMS/ERP project. Its most useful backend evidence is not its size. It is the effort to enforce identity, authorization and tenant boundaries while implementing academic workflows as separate Go domain packages.
Implemented boundary: verified identity context
The backend uses Go, chi and pgx. The authentication test file backend/internal/auth/middleware_test.go creates JWTs with invalid or missing claims to ensure the protected handler rejects them. Cases include absent or wrong-role claims, missing subjects, expired tokens, a wrong signature secret and an incorrect issuer.
The design derives organization context from verified JWT identity, rather than trusting a tenant identifier in an arbitrary request body. Negative-path tests are especially important here: a green happy-path test cannot show that a caller from one institution is prevented from accessing another.
Implementation versus product readiness
The August 8, 2026 repository status ledger recorded 35 backend packages, 168 HTTP routes and 46 migrations. These numbers describe codebase extent at a point in time, not capability or quality. The same ledger explicitly said an institution could not yet run a semester on the platform and identified unfinished teaching-core systems, dual authentication, flat authorization, and missing frontend coverage.
The latest GitHub Actions run visible in the audit, from August 14, failed a live-service isolation guard, although its backend test/build and frontend build jobs passed in that run. This is not a current green-CI claim.
Engineering trade-off
A modular API design makes domain ownership and tests easier to isolate, but increases integration work. Before claiming platform readiness, the teaching workflows must work end to end; authorization and tenancy must survive real database integration; and deployment needs a real institutional target.
What I can defend in an interview: JWT reject-path tests, the role of tenant identity propagation, explicit SQL boundaries, and why route count is not a delivery metric.
Current claim: substantial backend foundation in a private development repository, not a completed university LMS.
Evidence inspected: backend/internal/auth/middleware_test.go, STATUS.md (dated August 8, 2026), and .github/workflows/ci.yml.