Charting works without an AI key; interpretation needs your backend
Adding an API key will not turn this repository into the hosted Zi Wei Dou Shu product. The English README says the open version has no backend routes, including the AI interpretation and compatibility-analysis endpoints. You get a charting engine and an example interface, with the missing services left to you. That is the first decision to make before adopting Renhuai123/ziwei-doushu: do you want these components, or do you need a finished application?
For a developer building a traditional Chinese astrology tool, the component scope is useful. You can inspect chart generation and make your own interface instead of accepting a remote site's output as a black box. For someone seeking the hosted service's interpretations, the gap is substantial. The interpretation database is a placeholder, and the repository excludes the prompts, accounts, and payments. Its English README makes these exclusions unusually plain.
What happened when we ran it
Our Zi Wei Dou Shu sandbox installed commit 1059c34 in 30 seconds, built it in 63 seconds, and passed the test step in 49 seconds on October 23, 2026. Installation recorded 460 dependencies occupying 430 MB on disk. The checkout itself held 120 files, about 15,208 source lines, and occupied 3.7 MB. That expansion matters when budgeting a development environment, even though the source tree is modest.
The recorded configuration had 3 CPUs, 8 GB of RAM, and image label lab-node:22. That label does not establish the actual runtime or operating-system version. Our scan found 1 CI workflow file, no Dockerfile, and no tests directory. The successful test command still stands. A directory-name check cannot tell you that an executable test command is absent, and the supplied measurements give no individual passing-test count to report.
Npm audit reported 8 known vulnerabilities: 1 critical, 5 high, and 2 moderate, with 0 low. Those are findings from our run, separate from the successful build and test steps. The summary does not identify affected packages, production exposure, or a verified fix. Before deploying a fork, obtain the advisory details and establish which installed paths are affected. A green build cannot answer that question.
We measured repository mechanics. This run does not establish that every chart follows the intended tradition, that the example interface works across devices, or that an interpretation predicts anything. There is also no recorded deployed-backend evaluation to credit. If your acceptance criteria include chart boundary behavior or a complete interpretation service, those remain separate jobs after the commands pass.
Direct engine callers need to verify longitude handling
Issue 45, opened on October 23, reports that direct callers of generateChart receive no true-solar-time correction from the longitude field. The report distinguishes that path from the web interface, which it says applies a partial adjustment first. This is a specific integration concern, not a failure reproduced in our sandbox. Read the longitude report before relying on the README's broad solar-time capability claim.
The practical question is which function receives your input and which conversion happens before it. The documented engine input uses a Gregorian date and an hour-branch index from 0 to 11, rather than a clock hour. Passing a wall-clock hour into that field would change its meaning. For your integration, write down the birthplace and time convention and compare boundary cases against the convention you intend to implement. Our passing command does not settle the issue report.
A generated dataset does not reopen the judgment library
The project publishes interpretation data separately from the closed judgment library that generated it. That makes the data useful for inspecting outputs while leaving the generating content rules unavailable. If you need to change those rules and regenerate matching readings, a download alone does not provide the missing implementation. Keep the dataset's content version attached to any derived material so later engine changes do not silently become part of the same baseline.
The dataset terms specify CC BY 4.0 attribution and expressly exclude quotations from Ni Haixia's lectures. The repository identifies those quotations separately under noncommercial terms. Code carries MIT terms. Treat these as distinct materials when planning reuse. A code-license badge is insufficient evidence about permission to redistribute every included text, especially for a commercial training corpus.
October activity leaves the integration report unresolved
GitHub records a push on October 20, 2026, and the longitude report arrived on October 23. Those dates show recent code and issue activity together. An open report gives a fork owner a concrete behavior to investigate. Keep a reproduction tied to the revision and function your product will call. The date of the latest push cannot resolve a report that arrived afterward.
Documentation earns 4/5 for stating the open-source boundary and input conventions. Our scale uses 1 for no usable starting path, 3 for a usable path with material gaps, and 5 for guidance that resolves those gaps. The unresolved solar-time report prevents treating the capability list as an exact integration contract.
Iztro suits chart-library work; lunar-javascript suits calendar work
Iztro describes its npm package as a Zi Wei Dou Shu charting library. Investigate it when your main requirement is a library you can place behind your own interface. That comparison concerns scope, not measured superiority: this lab run did not evaluate either alternative.
Lunar-javascript describes itself as a solar and Chinese lunar calendar library. Choose that narrower starting point if calendar conversion is the actual requirement. For this repository, first resolve the audit findings and establish your chart-input convention. Then decide whether building the missing interpretation backend is work you intended to take on.