The Problem

Citizens and professionals need a simple way to query the Kenya Finance Bill 2025 without wading through dense legal text. Existing portals offer static PDFs or search‑only interfaces, which are hard to navigate for lay users.

What This Does

The repository delivers a static web front‑end that proxies user utterances to a Dialogflow CX agent pre‑trained on the Finance Bill 2025. The UI lives in index.html (markup), styles.css (visual layout), and script.js (client‑side logic). The GitHub Actions workflow in .github/workflows/gh-pages.yml builds and publishes the site to GitHub Pages automatically on pushes to main.

  • index.html defines the chat window and loads script.js and styles.css.
  • script.js binds UI events, serialises user text, and issues a fetch request to the configured Dialogflow CX endpoint, then renders the agent’s response.
  • styles.css supplies the minimal styling needed for a mobile‑friendly chat experience.

No server‑side code or build tools are present; the site is fully static.

How It Is Wired

Execution starts when a browser loads index.html. The page includes:

<link rel="stylesheet" href="styles.css">
<script src="script.js" defer></script>

script.js runs in the browser context; it does not import any other modules (import graph shows a single internal module with zero edges). The primary function—typically an event handler attached to the “Send” button—captures the input value, builds a JSON payload, and calls fetch(<Dialogflow‑CX‑URL>, {method:'POST', body:payload}). The response JSON is parsed and injected into the DOM to display the agent’s reply.

Because the JavaScript is self‑contained, the blast radius of a change is limited to the UI interaction layer; there are no downstream dependencies, databases, or file‑system writes. The only external effect is an HTTP POST to the Dialogflow CX service, which is the sole network touchpoint.

The CI pipeline (gh-pages.yml) triggers on push to main and runs actions/checkout followed by peaceiris/actions-gh-pages to push the static files to the gh-pages branch, which GitHub Pages serves.

How To Use It

# Clone the repo (exact URL as requested)
git clone https://github.com/moses-y/gdg
cd gdg

# No build step required – the site is static.
# Open the UI locally
open index.html   # macOS; use your OS’s equivalent to open the file in a browser

To connect to a real Dialogflow CX agent, edit script.js and replace the placeholder URL and authentication token with values from your Google Cloud project (see the comment block at the top of the file). After committing the change, push to main and the GitHub Actions workflow will redeploy the updated site.

Real‑World Use

A municipal office could host the generated site on its own domain, pointing script.js at a Dialogflow CX agent that includes local tax regulations. Citizens would type questions like “What is the new corporate tax rate?” and receive a conversational answer without leaving the office’s website.

Code Health & Issues

  • Low – Set timeout-minutes on workflow jobs – .github/workflows/gh-pages.yml declares no job timeout, risking overlapping runs on the default six‑hour limit. Fix: add timeout-minutes: 30 (or appropriate) to each job.
  • Medium – No test files – repository lacks any unit or integration tests; code paths are unvalidated.
  • Medium – No LICENSE file – usage and redistribution rights are undefined.
  • CI present – GitHub Actions workflow exists.
  • Dockerfile, lockfile, committed secrets – none found.

The Bottom Line

The project provides a minimal, static front‑end that connects a web chat UI to a Dialogflow CX agent, suitable for quick deployment of conversational access to the Kenya Finance Bill 2025. It is lightweight and easy to extend, but the lack of tests, licensing, and workflow timeouts are practical gaps that should be addressed before production use. Engineers comfortable with front‑end JavaScript and Dialogflow CX can adopt it quickly, while adding the missing quality safeguards.