# PRD — formulys_api_nodejs Evidence date: 2026-10-14. Source: `git@bitbucket.org:overdrive/formulys_api_nodejs.git`, `master` at `9d191c4` (2023-11-17, Jaco Brits, "Initial commit"). There is no prior PRD in the source repository or in Silicon Ark. The only evidence is `.gitignore` and the git history of that one file. No application was run, because there is nothing to run. ## Product purpose **Unknown.** The repository name is `formulys_api_nodejs`. No document and no source describe a purpose, a user, or a workflow. **Inferred** from the slug only: a Node.js API associated with Formulys. The tree does not confirm Node.js, an API, or Formulys behaviour. `.gitignore` ignores `node_modules/` and `dist/`, which is necessary for a Node project and is also part of a generic template that ignores Java, Python, and Maven output in the same file. **Documented:** the ignore file's own comments, which describe the list as examples to customise and link to an Atlassian gitignore tutorial. They do not describe a product. **Implemented:** ignore rules only. See technical documentation for the pattern list. ## Users and interactions No actor is named in the repository. | Actor | Evidence | Status | |---|---|---| | Person who created the repository | Commit author Jaco Brits ``, message "Initial commit" | **Implemented** as git metadata. Role beyond author of that commit is **Unknown** | | API caller | None | **Not present** | | End user of Formulys | None | **Not present** | | Operator of a pipeline or Sonar scan | No pipeline file. Scan-host sonar files are not in this commit | **Unknown / Requires Confirmation** | No session, role, permission, or screen exists in this repository. ## Systems the product talks to None are implemented. Not present: HTTP server, database, queue, mailer, object storage, identity provider, Bitbucket Pipelines, Docker, and a SonarQube project file in git. The onboarding record named `sonar-project.properties` and `sonarqube_scan.bat` on the scan host. Those files are not in `9d191c4`. A SonarQube integration is **not implemented** in the committed tree. Whether a local scan script existed outside git is **Unknown / Requires Confirmation**. ## Major workflows No product workflow is implemented. ### WF-1 — Repository creation **Implemented** as git history: 1. A single root commit `9d191c4` on 2023-11-17 adds `.gitignore`. 2. No parent commit. No later commit. No tag. No other branch. 3. The file is 50 lines. Its header comments say the patterns are examples and should be customised. What happened in Bitbucket's UI at creation time is **Inferred** (a hosting provider's "initial commit" that adds a default ignore file). The audit log was not available. The inference rests on the commit message, the single file, and the Atlassian tutorial URL inside the file. ## Functional requirements No product requirement is recoverable from behaviour, because the repository does not implement an application. The items below record that boundary so a later change can be tested against it. ### FR-001 — The committed tree does not expose an API Requirement: at `9d191c4`, the repository does not start a server, define a route, or accept a request. Who: anyone cloning `master`. Trigger: checkout of `9d191c4`. Inputs: none. Expected behaviour: the work tree contains `.gitignore` and no application entry point. Outputs: no HTTP response, no job, no persisted product record. Validation: `git ls-tree -r HEAD --name-only` lists `.gitignore` only. Error conditions: none in product code. There is no handler to fail. Dependencies: Git. No runtime dependency is declared. Evidence: `git ls-tree` of `9d191c4`; absence of `package.json`, source files, and a README. Implementation: Implemented (as absence of an application). Confidence: High. ### FR-002 — Generated and IDE files matching the ignore list stay untracked Requirement: Git does not add paths that match the patterns in `.gitignore`, once those paths exist in a working copy. Who: a developer using this clone. Trigger: creating a file whose name matches a pattern in `.gitignore`, then inspecting Git status. Inputs: a path such as `node_modules/`, `dist/`, `target/`, `.idea/`, `*.log`, `*.class`, `*.jar`, `*.exe`, `*.war`, `TEST*.xml`, `.DS_Store`, or `Thumbs.db`. Expected behaviour: Git treats the path as ignored. `sonar-project.properties` and `sonarqube_scan.bat` do not match any pattern, so they would be visible to Git if they were created. Outputs: ignored paths omitted from an ordinary status of untracked product files. Validation: pattern match against `.gitignore`. This inspection did not create sample files. Error conditions: a pattern that is too broad (`*.exe`, `*.log`, `dist/`) would also hide a deliberately committed tool or log if someone later wanted it in git. That consequence is **Inferred** from how Git ignore works. The file comments say the list should be customised. No project-specific exception is present. Dependencies: Git. Evidence: `.gitignore`. Implementation: Implemented as ignore rules. Not exercised by adding files during this inspection. Confidence: High for the pattern text. Medium for day-to-day effect, because no matching files are in the tree. ### FR-003 — No authenticated or authorised action exists Requirement: the repository does not check an identity, a role, or a session. Who: not applicable. No user action is implemented. Trigger: none. Inputs: none. Expected behaviour: no access decision is made. Outputs: none. Validation: no auth module, middleware, or policy file is tracked. Error conditions: none. Dependencies: none. Evidence: file list of `9d191c4`. Implementation: Implemented (as absence). Confidence: High. ## Data the repository manages No product entity, schema, or migration is present. The ignore file is repository configuration, not domain data. ## Constraints - History is one commit on `master`. Any API behaviour would have to be uncommitted local work or a different repository. Neither was found in this clone. - The ignore list is generic. It is not evidence that the project uses Java, Python, Maven, or Node together. - Secrets: none are stored in git. There is no `.env`. ## Not verified - The scan-host working copy was not available, so untracked sonar files could not be read. - Bitbucket UI settings (branch permissions, project access, pipelines configured only in the UI) were not inspected. The clone shows one branch, `master`, and one commit. - Whether a Node process was ever deployed from this slug is **Unknown**.