Metadata-Version: 2.3
Name: deped-equipment
Version: 0.2.0
Summary: Equipment cleaner extracted from the DepEd asset pipeline.
Requires-Dist: deped-dcp-template>=0.12.1,<0.13
Requires-Dist: deped-primitives>=0.17.0,<0.18
Requires-Dist: deped-runtime[polars,r2]>=0.9.0,<0.10
Requires-Dist: fastexcel>=0.20.2
Requires-Dist: openpyxl>=3.1.5
Requires-Dist: polars>=1.44
Requires-Dist: pydantic>=2.13.3
Requires-Dist: pyyaml>=6.0.3
Requires-Python: >=3.14
Description-Content-Type: text/markdown

# DepEd Equipment

Equipment turns submitted inventory and ICT benchmarks into two SQLite files:

- `artifacts/provider.db` contains school counts and grouped DCP procurement evidence for downstream applications.
- `artifacts/equipment.db` contains the compact observations and source references used to explain those figures.

The public contract is `equipment_v4`, with schema `equipment_provider_v1`. The private schema is `equipment_build_v2`. Original source files remain the evidence for fields that Equipment does not copy.

## Build and verify

Run from this repository with Python 3.14+, `uv`, and `just` installed:

```sh
uv sync
just preflight
just build
just status --json
just audit
```

The build requires Portal and InsightEd extracts, Entity and Dataset artifacts with valid receipts, DCP templates, the DCP procurement workbook, historical ICT workbooks, and the eCart CSV. Paths are configured in `justfile` and can be overridden through environment variables. No HR artifact is required.

`just build` regenerates the lookup input and performs a complete build. It publishes the private database, provider database, and receipt together with rollback on publication errors. `just provider-artifact` republishes a completed build after checking its inputs and receipts.

Read the [build guide](docs/operations/build.md), [table reference and ERDs](docs/reference/tables.md), [figure definitions](docs/reference/artifact.md), and [measured validation](docs/validation.md).

Development checks are `just check` and `just test`. Run `just docs` to preview the documentation.

## Command environment

R2 transfer recipes use `op run --env-file=env.r2` to resolve the checked-in
1Password references only for the transfer process. Install the 1Password CLI
and authorize access to the referenced vault before running them.
Just does not load or generate `.env`. Export ordinary configuration overrides
in your shell. Existing local `.env` files are not deleted automatically; move
any needed overrides before removing old plaintext copies.

### Without 1Password

Have your secret manager or CI secret store supply `R2_ACCOUNT_ID`,
`R2_ACCESS_KEY_ID`, `R2_SECRET_ACCESS_KEY`, and `R2_BUCKET` to the command's
environment, with `R2_REGION=auto`. Supply resolved values, not `op://`
references. Run the underlying CLI directly; the Just transfer recipes still
invoke `op`, even when credentials are already exported:

```sh
uv run deped-runtime r2 download --target "data" --prefix "deped-equipment"
uv run deped-runtime r2 upload --source "data" --prefix "deped-equipment" --overwrite
```

These examples use the repository's default paths and prefixes. Adjust the
explicit flags for another location, retaining any include/overwrite options.
The upload command writes to the remote bucket. If you lack bucket access,
obtain the required inputs from maintainers and place them at the documented
local paths; installing 1Password does not itself grant data access.

Keep actual secrets out of reference files, committed files, and shell command
history. Ordinary offline builds and checks do not require 1Password.
