# PRD — eit Evidence date: 2026-10-15. Source: `git@bitbucket.org:overdrive/eit.git`, `master` at `91549dc` (2019-09-26, "First commit with pipeline"). There is no prior PRD in the repository or in Silicon Ark. The repository has two commits and two files: `README.md` and `bitbucket-pipelines.yml`. Requirements below were recovered from those files. Provenance is marked on each item. The only remote branch is `master`. The pipeline also declares a `development` step. That branch is not on the remote. ## Product purpose The README heading is "Silicon Overdrive : EIT". It does not say what the product does. The setup line tells the reader to open a configure file and update database details. Provenance: **Documented** (`README.md`). No screen, API, report, or data store is committed. The purpose of EIT, beyond that heading, is **Unknown / Requires Confirmation**. A different Bitbucket repository, `overdrive/eitaws`, is documented in Silicon Ark as the eIT staff operations system. This repository does not contain that system. Treat a shared name as a naming overlap until someone confirms a relationship. ## Users and roles | Role | What the repository shows | Provenance | |---|---|---| | Reader of the README | Is told to edit a configure file and update database details | Documented. The file is not in git | | Bitbucket Pipelines | On `master`, installs packages and pushes the git tree by FTP. On `development`, would do the same to a different path | Implemented in `bitbucket-pipelines.yml`. The `development` branch does not exist | | Application user | Not described | Unknown / Requires Confirmation | No login, role, or permission check exists in the tree. ## Main workflows ### W1 — Read the setup note Trigger: a person opens `README.md`. Documented behaviour: go to the configure file and update database details. Inputs, validation, error text, and the configure file itself are not in the repository. Expected behaviour after the edit is **Unknown / Requires Confirmation**. The first commit's README was only `# eit`. Commit `91549dc` replaced that text. Provenance: **Documented** in the current file; the replacement is git history. ### W2 — Deploy `master` by FTP Trigger: a commit lands on branch `master`. Bitbucket runs the step in `bitbucket-pipelines.yml`. Inputs: pipeline variables `FTP_USERNAME_LIVE`, `FTP_PASSWORD_LIVE`, and `FTP_HOST_LIVE`. Values are not stored in git. Implemented behaviour: 1. The step runs in image `python:3.5.7`. 2. `apt-get update` runs. The comment says this is required to install zip. 3. `apt-get -qq install zip git git-ftp` runs. The comment says this is required for packaging up the application. 4. A `git ftp init` line for `ftp://$FTP_HOST_LIVE` is commented out. The comment says init is only for the first time. 5. `git ftp push` uploads the repository to `ftp://$FTP_HOST_LIVE` using the live username and password variables. No zip command runs after the install. No test runs. Failure behaviour is whatever Bitbucket and `git ftp` do by default. That behaviour is not described in the file. Provenance: **Implemented**. Whether this step has ever succeeded, and which host `FTP_HOST_LIVE` is, are **Unknown / Requires Confirmation**. ### W3 — Deploy `development` by FTP Trigger: a commit lands on branch `development`. The step is present in the pipeline file. The branch is not present on the remote, so this workflow cannot run against the repository as it was fetched. Implemented script, if that branch were pushed: 1. Same image and the same `apt-get` install as W2. 2. `git ftp init` for the QA URL is commented out. 3. `git ftp push` uploads to `ftp://$FTP_HOST_QA/public_html/americanshutters.overdriveqa.co.za` using `FTP_USERNAME_QA` and `FTP_PASSWORD_QA`. The YAML comment on the branch key is "ftp example". The path contains the host name `americanshutters.overdriveqa.co.za`. The README does not mention American Shutters. Whether this URL is an example copied from another project or the real QA site for EIT is **Unknown / Requires Confirmation**. Provenance: **Implemented** as pipeline text. Not reachable until a `development` branch exists. ## Functional requirements ### FR-001 — README names the project and a database setup step Requirement: The committed README identifies the project as "Silicon Overdrive : EIT" and instructs the reader to update database details in a configure file. Who: a person reading the repository. Trigger: opening `README.md`. Inputs: none in git. Expected behaviour: the two sentences above are the entire document. Outputs: none. Validation: none. Error conditions: the configure file is not in the repository, so the instruction cannot be followed from git alone. Evidence: `README.md`. Implementation: **Implemented** as text. Confidence: **High** that the text is the whole README. Confidence in there being a real configure file: **none from this repo**. ### FR-002 — `master` is published by git-ftp Requirement: A pipeline run on `master` pushes the git tree to an FTP host taken from pipeline variables. Who: Bitbucket Pipelines. Trigger: commit on `master`. Inputs: `FTP_USERNAME_LIVE`, `FTP_PASSWORD_LIVE`, `FTP_HOST_LIVE`. Expected behaviour: install `zip`, `git`, and `git-ftp`, then `git ftp push` to `ftp://$FTP_HOST_LIVE`. `git ftp init` stays commented. Outputs: files on the FTP host. Which files, and whether a previous init is required, are determined by git-ftp and by whether init was done by hand. The YAML does not say. Validation: none in the script. Error conditions: missing variables, a host that was never initialised, or `apt-get` failure. The file does not catch these. Evidence: `bitbucket-pipelines.yml` `master` step. Implementation: **Implemented**. Confidence: **High** for the script. Confidence that a live host still matches: **Unknown / Requires Confirmation**. ### FR-003 — `development` is published to a fixed QA path Requirement: A pipeline run on `development` pushes the git tree to `ftp://$FTP_HOST_QA/public_html/americanshutters.overdriveqa.co.za`. Who: Bitbucket Pipelines. Trigger: commit on `development`. Inputs: `FTP_USERNAME_QA`, `FTP_PASSWORD_QA`, `FTP_HOST_QA`. Expected behaviour: same install as FR-002, then `git ftp push` to that path. Init is commented. Outputs: files under `public_html/americanshutters.overdriveqa.co.za` on the QA host. Validation: none. Error conditions: same class as FR-002. In addition, the branch does not exist, so the trigger cannot occur on the remote that was inspected. Evidence: `bitbucket-pipelines.yml` `development` step; `git branch -a`. Implementation: **Implemented** as YAML. The branch is absent. Confidence: **High**. ## Integrations | System | Purpose | Trigger | Data | Direction | Authentication | Response | Failure | |---|---|---|---|---|---|---|---| | Bitbucket Pipelines | Run the YAML | Push to `master` or, if it existed, `development` | The git tree | Outbound from Bitbucket | Bitbucket's own pipeline | Not described | Not described | | FTP live | Receive `master` | `git ftp push` in the `master` step | Repository files | Outbound to `ftp://$FTP_HOST_LIVE` | `FTP_USERNAME_LIVE` / `FTP_PASSWORD_LIVE` | Not described | Not described | | FTP QA | Receive `development` | `git ftp push` in the `development` step | Repository files | Outbound to the American Shutters path on `$FTP_HOST_QA` | `FTP_USERNAME_QA` / `FTP_PASSWORD_QA` | Not described | Not described | No HTTP API, mail service, queue, or database client is committed. The README's database is an instruction only. ## Constraints - The pipeline image is pinned to `python:3.5.7`. No Python code uses that pin. - FTP passwords are referenced as variables. They are not committed. This document does not invent their values. - `git ftp init` is commented on both steps. A first deploy that needs init will not get it from the current script. - The QA URL is written in full, including `americanshutters.overdriveqa.co.za`. The live URL is only the variable `$FTP_HOST_LIVE`. ## Behaviour that cannot be specified from this tree - Screens, roles, and business workflows of an EIT application. - The schema and the configure file. - Whether the FTP steps were ever enabled in the Bitbucket UI, and whether the variables were set. - Any relationship to the eIT application in `eitaws`.