Commit Graph
1 Commits
Author SHA1 Message Date
LincPayandClaude Opus 5 22870eb480 docs: README and API-SPEC, both promised by the original scaffold
A judge who cannot run the code reads the README, and until now the
reasoning behind this system lived only in Java comments and commit
messages — including the one thing a NABARD panel will check first, which
is why the apex tier cannot reach a borrower.

README covers the institutional model and why NABARD's restriction is the
point rather than a limitation, how to run both projects, the seven console
logins with what each sees, the demo path, and the design decisions worth
defending.

It also states plainly what is real and what is not: live Agmarknet and
Open-Meteo data and a working rule engine, a forecast that is deterministic
rather than machine-learned, and a seeded loan book. It says that
trust-seeded defaults to true and that the honest setting turns 34
trip-wires into 5. A demo that implies more than it has is worth less than
one that is straight about the gap.

API-SPEC documents every endpoint across the four surfaces, the response
envelope, the tenancy rule, small-cell suppression, effective dating and
the rejection reasons — plus the one defect found while writing it:
SecurityConfig whitelists /health but nothing is mapped there, so it
returns 500. The working probe is /auth/health.

Every credential and figure quoted was verified against the running
service: seven logins, the enterprise PIN, and the 44 / 39 / 59 / 12
portfolio counts.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-06 20:02:38 +05:30