The badges point at another repository, and npm test runs a missing file

The header links a video and the badges link a sibling project

The project title is inside an anchor that points at a YouTube watch URL, so clicking the name in the README opens a video rather than a file.

The badge row below it is a set of anchors with nothing inside them, and four of the targets are not this repository. The stargazers link, the network members link and the watchers link all address a different path under the same account, one that ends in a bot project rather than the one you are reading. The licence scanning badge points at that same sibling project as well. The followers link and the account link do address the account itself.

So of six badges, four measure a different repository. The star history chart at the bottom of the file does address the project you are in, with a template that distinguishes a dark and a light image.

None of this affects the code. It does mean the visible popularity signals on this page belong to another project, which is exactly the kind of thing that makes a repository look more active than its commit history is.

The last commit to the default branch is dated 2026-04-15.

Three releases from 2023, none of them version 2.1.0

The repository has three tags and none of them is a version number.

They are named bot, with a description of a first release, whatsappchatbot with a description naming an updated stable version, and GuruBot with a description calling itself version two point oh. Two of the three carry the description of a different repository name in their titles, which matches the badge problem above.

The manifest says something else entirely: version 2.1.0. So the number the package manager would report is one that no tag matches, and there is no release you can check out by version to get the code you installed.

The dates are the other half of the story. The newest tag is from September 2023, and the last commit is from April 2026, so there are close to three years of changes on the default branch with nothing tagged. Anyone pinning a release gets a 2023 build, and anyone installing from the branch gets code whose version string has never existed on the tag list.

The manifest description is one word longer than the repository's own description: Advanced WhatsApp Ai, against SIMPLE YET COMPLICATED.

npm test runs a file that is not in the repository

The manifest defines two scripts. One starts the bot with the main entry point. The other runs a test file:

node test.js

There is no test.js among the files in the repository. What is there is the entry point, a server module, a handler module, a second script whose name matches the project branding, a configuration module, a static page, and directories for shared code, plugins and a temporary folder.

So the documented test command fails on a file that does not exist, and no other test runner appears in the manifest.

The same manifest declares a set of directories, listing a shared library folder, a source folder and a plugins folder. Two of those three exist. There is no source folder in the repository, which suggests the layout was refactored and the declaration was left behind, or that the source folder is generated during a build and never committed.

Small things, both of them, and both of them are what a new contributor meets first when they run the obvious command.

The container clones the project instead of copying it

The Dockerfile is six lines and every one of them is worth reading.

It starts from an image on quay.io belonging to a different account and project, tagged latest rather than a version. It then runs a git clone of this repository into the image, sets that as the working directory, runs an install with a platform flag, exposes port 5000, and starts the bot with the manifest's start script.

Two consequences follow from the clone. First, the image is built from whatever the remote default branch looks like at build time, not from the commit you are looking at, so a rebuild of the same tag can produce different content. Second, the base image is a floating tag from another project, so a rebuild depends on a maintainer you do not control publishing a new image under that name.

The install line also passes a platform flag in the form a different package manager uses for selecting a binary variant. Given that the command is npm's, the flag is not doing what it looks like it does.

Nothing here is unusual for a small personal bot project. It is simply a build that reaches out to the network three times, once for the base image and once for the source, and pins none of them.

Three dependencies come from the wrong shelf

The dependency list is long, which is normal for this family of bot, and three entries are not.

One installs the file system module from npm at its security placeholder version. That package exists precisely so that code requiring the built-in gets a message instead of a shim, and having it as a real dependency means the built-in is being shadowed or at least requested twice. Another installs a path module from npm, when the path handling is part of Node itself. Both are long-standing npm hygiene warnings, and both are still listed at the top of the file.

The third is more interesting: the WhatsApp library is not pulled from a registry version at all. It is specified as a GitHub reference to somebody else's fork, which means there is no semantic version to resolve, no integrity check against a published release, and no way to tell from the manifest which commit you got.

Then there are the ordinary sharp edges. The HTML parser is pinned to a release candidate rather than a release, an HTTP client is at a major version behind the one the ecosystem now prefers, and the keyword list in the same manifest repeats one entry twice.

The environment example is missing two of the four documented variables

The configuration section lists four settings. A MongoDB connection URI, a WhatsApp phone number with the country code, an optional display name for the bot, and an owners list, given as a semicolon-separated string inside quotes.

The example environment file in the repository contains three variables, and two of them are not on that list. It has the database URI, with a placeholder username and password in it, the phone number with a comment showing the expected format, and the port. The display name and the owners list are absent.

That matters more than it looks, because the owners list is the kind of value that belongs in version control as a template and nowhere else. The README also says the same settings can be edited in a configuration module, which adds bot name, package name, author, owners and a sticker watermark, so there are two configuration surfaces and only one of them has a shipped example.

The port default appears in both places and agrees: 5000, with a pairing page served at that address showing the pairing code and the connection status.

The licence has three answers and the homepage is plain HTTP

Three sources describe the licence of this repository and they do not agree.

The repository's own licence metadata could not be resolved to a known identifier, which is what tooling reports when a licence cannot be classified automatically. The manifest declares Apache License 2.0, and a LICENSE file sits at the root. The declared string is the licence's display name rather than its SPDX expression, and that distinction matters in practice: automated licence checks match the identifier form, not the prose form, so a scanner reading the manifest will not recognise it as Apache-2.0 and will fall back to reporting nothing.

This is a case where the answer is not to guess. Read the file at the root, and if the intent is Apache-2.0, replace the display name in the manifest with the identifier so tools can see it.

One smaller thing in the same manifest: the homepage field is the repository itself, while the separately declared site address in the repository metadata is a plain HTTP URL rather than HTTPS. Nothing about the project requires a browser to load an unencrypted page, and changing it costs nothing.

Editorial conclusion

GURU-Ai is a recognisable member of a large family of WhatsApp bots built on an unofficial multi-device library, and if you already run that pattern you will recognise the pairing flow, the dot-prefixed commands and the configuration module immediately. Three things to settle before you rely on it. The version, because the manifest reports 2.1.0 while no tag carries that number and the newest tag is from 2023, so install from the branch and expect the version string to be meaningless. The licence, because the metadata, the manifest string and the file in the root give three answers and only the file settles it. And the container build, which fetches a floating base image from a third party and clones your source from the network instead of copying the context, so do not build and ship that image without changing those two lines. The dependency list also deserves a look before you install, since one entry comes from a fork rather than a registry.

Frequently asked questions

Official sources

1. Guru322/GURU-Ai on GitHub
2. Issues
3. Project website
4. README
5. Releases