A poetry API needs a deployment check beyond a successful build
Chinese Poetry API gives developers a documented REST and GraphQL interface to classical Chinese poetry. It is a plausible fit for reading apps, quizzes and educational tools that need a service layer. Our recorded run does not establish that the service was ready to deploy: the build step succeeded, while the test command failed without enough retained error detail to identify the cause.
The README documents simplified zh-Hans and traditional zh-Hant output, poem search, random selection, authors, dynasties, forms, statistics and health endpoints. Search examples distinguish all-text, title, content and author searches. These are documented capabilities, not endpoint results measured in our run. The supplied README and operational extracts are primarily Chinese; they do not establish that no English documentation exists anywhere.
What our October 3 run actually recorded
Our recorded run began on October 3, 2026, at 02:40:23.233 UTC against commit f17afe49ead6dce982602819dadcf6b6f9d5fd50, dated September 3, 2026. The configuration recorded 3 CPUs, 8 GB of memory and image golang:1.24-bookworm.
The dependency/setup step exited 0 after 29 seconds. Its retained tail says go: downloading go1.25.0 (linux/amd64). The dependency summary contains 122 entries; that is not a count of installed command-line tools. The image label also does not establish the actual toolchain used throughout the run.
The build step exited 0 after 79 seconds, with retained tail vet-exit:0. We can report that successful recorded step. The tail does not independently demonstrate a compiled server artifact, an installed binary or a running API.
The go test step exited 1 after 13 seconds. The parser recorded 6 passing packages, 8 failing packages and 10 packages without tests. Its total of 14 refers to passing and failing package summaries, not 14 individual tests. Exhaustive unique test counts were not reconciled against a complete log. Packages without tests must not be counted as failures.
The retained tail names failures in database, GraphQL and integration packages, including TestGraphQLCountFields, and shows the processor package passing. It omits the underlying error messages needed to diagnose those failures. In particular, this run does not support attributing them to no such module: fts5 or to a missing sqlite_fts5 tag.
The checkout measured 2,384 files, approximately 18,837 source lines and 380 MB. It included 3 CI workflow files, a Dockerfile, a Compose file and a tests directory. Those repository signals do not establish that CI passed or that the container works. No new execution, installed-binary check, deployment check or workload benchmark was performed for this correction.
Follow the documented build configuration
The current Makefile sets CGO_ENABLED=1 and GO_TAGS := sqlite_fts5. Its comment says the tag enables FTS5 and the trigram tokenizer required by the full-text search index. Both build and test targets pass the tag.
That is a documented build requirement, separate from the unexplained failures in our stored run. A generic go build should not be treated as equivalent to the project's configured build. Use the documented Makefile path for a source evaluation, then check startup and search against a fresh database before relying on a custom binary.
The README recommends Docker. Release v0.6.0 says container startup automatically downloads the database and lists poetry.db.gz plus checksums.txt for SHA256 verification. This makes the release asset part of deployment planning. Confirm the image and database revisions you intend to use, verify the asset, and check persistence and restart behavior. Our run did not test these operations; the available extracts do not substantiate the previous claims about a particular volume mount or container health-check implementation.
Keep release data separate from the current README
Release v0.6.0 reports 371,313 poems, 13,577 authors and 11 dynasties in its database. Those are release-reported figures, not counts we queried or a verified total for today's main branch.
The current README says the project uses palemoky/chinese-poetry on its fix-typo branch, with corrections to characters, dynasties and authors. Its category counts differ from the README pinned to our recorded commit. Treat the release, the measured source revision and the current README as different snapshots. Confirm the actual database behind your deployment rather than combining their figures into one inventory.
Verify search composition and textual variants
The README documents dynasty and author filters for poem lists and random selection. That does not establish the same filter support for keyword search.
In issue 65, opened July 14, 2026, a user reports that /api/v1/poems/search cannot combine keywords with dynasty filtering. The maintainer acknowledged the request on July 17. The supplied extract shows the issue open, but an issue report alone does not prove the behavior of every later revision. If your interface needs a query such as moon poems from the Tang dynasty, confirm it against your selected deployment before designing around it.
Issue 51 also needs careful reading. A user reported wrong characters on June 23, 2026. On October 6, the maintainer explained that the example's wording appears in Song-era sources and that another wording appears in later selections. This exchange supports checking textual provenance; it does not prove that the example is an error or quantify corpus-wide accuracy. The current README's correction claims do not establish independent editorial verification either.
For classroom or quotation use, sample representative poems in both scripts against the editions your application follows. Decide how you will handle variants and user corrections before presenting the text as authoritative.
Choose the service only when you need its interface
The Chinese Poetry repository distributes its literature data as JSON. Choose that route for offline processing or an application with its own storage and search layer.
Gushici addresses a narrower need: returning a random classical Chinese poetry line, optionally by category, in formats including JSON, text, SVG and PNG. Its README says the open repository contains only test data and that additional data must be collected separately. That matters if you intend to self-host a quote widget.
Chinese Poetry API is the candidate here when REST or GraphQL and both Chinese scripts justify operating a service. The next useful check is a deployment of your chosen revision with representative list, search and GraphQL requests. The stored test failure is a reason to investigate, not a diagnosis.
How to read the scores
These are editorial assessments of the supplied evidence, not benchmark results. The rubric is 1 for substantial documented barriers, 2 for limited or unresolved evidence, 3 for a usable documented path with material checks remaining, 4 for detailed support with few unresolved questions, and 5 for strong corroboration across documentation and relevant recorded checks. Unknown adoption or compatibility earns no extra credit. Setup and maturity remain provisional because deployment was not verified.