[Feature Request] Provide a first-class way to remove the scaffold's built-in blog resource

[MarkColeMukisa]

[Feature Request] Provide a first-class way to remove the scaffold's built-in blog resource

Reported against: Grit scaffold (triple: Next.js admin + web, Go API)
Applies to: the scaffold's built-in blog resource

Summary

The blog resource ships with every scaffolded project, but there is no clean way to remove
it. It is not a generated resource — it is baked into the scaffold itself — so
grit remove resource Blog (which only cleans up generated files) cannot fully remove it.
Any project that doesn't want blogs must hand-edit ~20 touch points and delete live DB rows.

Motivation

A user running a non-blog app should be able to opt out of the scaffold's demo/blog resource
without fighting the framework. Right now removal is manual, fragile, and leaves dangling
references if a step is missed.

Where the blog resource lives (from a real scaffolded project)

Verified against a real scaffold at Grit 3.145.0 (grit.json → architecture triple,
frontend next). grep -ri blog apps packages yields ~100+ matches across 5+ packages.

Go / API:

• apps/api/internal/models/blog.go
• apps/api/internal/handlers/blog_handler.go
• apps/api/internal/services/blog_service.go
• apps/api/internal/database/blogs_seeder.go (+ call in seed.go)
• apps/api/internal/routes/routes.go — public + admin routes, studio mount, docs routes,
  sync registry (syncRegistry.Register("blogs", ...)), handler init
• apps/api/internal/authz/permissions.go — blogs.* permission group
• DB table blogs (+ seeded rows)

Shared package:

• packages/shared/schemas/blog.ts
• packages/shared/types/blog.ts
• packages/shared/schemas/index.ts / types/index.ts / constants/index.ts (API_ROUTES.BLOGS)

Admin app:

• apps/admin/resources/blogs/blogs.ts, blogs.custom.tsx
• apps/admin/resources/index.ts (registry entry)
• apps/admin/app/(dashboard)/resources/blogs/... pages

Web app:

• apps/web/hooks/use-blogs.ts
• apps/web/app/blog/... pages
• home page blog sections (bounded by grit:home:blog-* markers)
• navbar /blog link

Sample of the wiring in apps/api/internal/routes/routes.go (Grit 3.145.0 scaffold):

blogHandler := handlers.NewBlogHandler(db)
...
syncRegistry.Register("blogs", &models.Blog{})
...
blogs := v1.Group("/blogs")
blogs.GET("", blogHandler.ListPublished)
blogs.GET("/:slug", blogHandler.GetBySlug)
...
admin.GET("/admin/blogs", blogHandler.List)
admin.GET("/admin/blogs/:id", blogHandler.GetByID)
admin.POST("/admin/blogs", blogHandler.Create)
admin.PUT("/admin/blogs/:id", blogHandler.Update)
admin.DELETE("/admin/blogs/:id", blogHandler.Delete)

Suggested behavior

A single command, e.g.:

grit remove blog

or a flag on the existing remove command (grit remove resource Blog --scaffold) that:

1. Removes/de-stages all of the above code paths and marker-bounded sections.
2. Removes the DB table and rows for blogs (with confirmation / a --yes flag).
3. Keeps the rest of the app fully functional — routes, auth, admin panel, web home page all
   still work with zero blog references.
4. Logs every file it touches and every step skipped, so the user can review before commit.

If a flag isn't desired, an alternative is a documented, tested removal checklist + a grit remove enhancement that understands scaffold resources, not just generated ones.

Acceptance criteria

• After running the command, grep -ri blog apps packages returns no scaffold references
  (a clean run on a fresh scaffold should be 0 matches).
• grit sync, grit start, admin panel, and web app all work with blogs absent.
• Existing data for other resources is untouched.

Environment

• OS: Windows 11
• Grit CLI: 3.145.0 (grit version)
• Scaffold version: 3.145.0 (grit.json — architecture triple, frontend next)
• Go: 1.25.0, Gin 1.11.0, GORM 1.31.1
• Next.js: 16.1.6, React 19.2.7, TypeScript ^5.3.0
• pnpm 10.0.0 monorepo (Turborepo)