ftkit verify

Verify that a repository follows the Fountain standard.

Usage

ftkit verify

The command is also available under the alias v:

ftkit v

It takes no arguments and runs against the current service repository.

What it does

verify runs a suite of 20 checks over the service in the current directory and prints, for each check, a list of passes (✓), warnings (⚠) and errors (✗). At the end it prints a summary with the total counts.

The 20 checks cover, in order:

1. Project structure — required directories (server, biz, biz/core, biz/dal), go.mod and a config file.
2. main.go — package main, the fountain bootstrap pattern, server creation, and a Serving() call.
3. server/server.go — blank import of biz, the server struct, NewServer(), the lifecycle methods (Initialize, Serving, Destroy, Info) and the install order in Initialize().
4. server/route.go — initHTTPHandle, API versioning, route groups and handler references.
5. biz/biz.go — blank imports for controller domains under biz/core/*.
6. Controllers — each domain calls RegisterCoreController() and implements InstallController() / RegisterCallback(), using sync.Once.
7. controller.go contents — only CoreController-related functions plus init() / Get*ControllerInstance().
8. Handlers — each handler domain has an *_impl.go with a New*API() constructor that takes []core.CoreController.
9. Handler files — naming {group}.{operation}_handler.go and exactly one handler function per file.
10. No route handlers in *_impl.go — methods taking *fiber.Ctx must live in *_handler.go.
11. DAO layer — biz/dal/dao/managers.go, its constants, init() and RegisterDAO* usage, plus models.
12. DAO import rules — DB DAOs vs. cache DAOs and what they may import (currently advisory).
13. DAO ownership — each DAO belongs to a single controller and is touched from a single file.
14. DAO type suffix — GetDAO[...] type parameters in InstallController() must end in DAO, Cache or STO.
15. Logging — only flog is allowed; log, slog, logrus, zap, zerolog and fmt.Print*-as-logging are flagged.
16. No data structs — controller, DAO and handler files must not declare data structs (those belong in biz/dal/do).
17. Controller errors — exported controller functions must return *froto.RpcError, not plain error.
18. No interface{} / any params — in controller files other than controller.go.
19. pkg/ directory — and the client library (<service>_client/).
20. Go file headers — reports the percentage of files carrying the standard header.

For the full, human-readable list of the conventions these checks enforce, see the Standards Checklist.

Exit behavior

• If any errors are found, verify prints a numbered list of the errors and exits with a non-zero status (exit 1) — useful for CI gates.
• If there are warnings but no errors, it reports the repo as conformant with caveats and exits successfully.
• If there are no errors and no warnings, it reports the repo as fully conformant.

TIP

For check 20 (headers), verify suggests running ftkit header to automatically add the missing file headers.

verify has no flags.