[Hyderabad] Barma — Vibe Coding Submission

[ManoharBarma]

Vibe Coding Workshop — Submission PR

Name: Manohar Barma - 963251
TechM Group: TechM Vibe Coding Workshop
Date: 15 April 2025
AI tool(s) used: Claude Code

---

Checklist — Complete Before Opening This PR

• agents.md committed for all 4 UCs
• skills.md committed for all 4 UCs
• classifier.py runs on test_[city].csv without crash
• results_[city].csv present in uc-0a/
• app.py for UC-0B, UC-0C, UC-X — all run without crash
• summary_hr_leave.txt present in uc-0b/
• growth_output.csv present in uc-0c/
• 4+ commits with meaningful messages following the formula
• All sections below are filled in

---

UC-0A — Complaint Classifier

Which failure mode did you encounter first?

Severity blindness — complaints containing "child", "school", "hospital", "hazard", "fell" were not being classified as Urgent.

What enforcement rule fixed it? Quote the rule exactly as it appears in your agents.md:

"priority must be Urgent when the description contains any of: injury, child, school, hospital, ambulance, fire, hazard, fell, collapse — this rule has no exceptions regardless of other context"

How many rows in your results CSV match the answer key?

Pending answer key release — all 15 rows classified with correct taxonomy and severity enforcement

Did all severity signal rows (injury/child/school/hospital) return Urgent?

Yes — PM-202402 (school/child), PM-202411 (hazard), PM-202420 (injury), PM-202446 (fell), GH-202401 (ambulance), GH-202411 (hospital), GH-202412 (school), KM-202421 (fell/hospital), AM-202407 (child) all return Urgent.

Your git commit message for UC-0A:

UC-0A Fix severity blindness: no keyword enforcement → added injury/child/school/hospital triggers and exact 10-value taxonomy

---

UC-0B — Summary That Changes Meaning

Which failure mode did you encounter?

Clause omission and condition dropping — naive prompt dropped clauses entirely and reduced clause 5.2 from two required approvers (Department Head AND HR Director) to one.

List any clauses that were missing or weakened in the naive output (before your RICE fix):

Clauses 2.5, 2.7, 3.4, 5.2, 5.3, 7.2 were either missing or had conditions dropped. Clause 5.2 most critically — "Manager approval alone is not sufficient" was lost.

After your fix — are all 10 critical clauses present in summary_hr_leave.txt?

Yes — all 10 clauses (2.3, 2.4, 2.5, 2.6, 2.7, 3.2, 3.4, 5.2, 5.3, 7.2) are present with full conditions. Compliance verification table at end of file confirms PRESENT for all 10.

Did the naive prompt add any information not in the source document (scope bleed)?

Yes — phrases like "as is standard practice in government organisations" appeared. Fixed by explicit enforcement rule prohibiting any information not in the source document.

Your git commit message for UC-0B:

UC-0B Fix clause omission: no completeness rule → enforced all 10 required clauses with multi-condition preservation for clause 5.2

---

UC-0C — Number That Looks Right

What did the naive prompt return when you ran "Calculate growth from the data."?

A single aggregated growth percentage across all wards combined — no breakdown by ward or category, no mention of null rows.

Did it aggregate across all wards? Did it mention the 5 null rows?

Yes, aggregated across all wards. No, the 5 null rows were silently skipped without any flag or explanation.

After your fix — does your system refuse all-ward aggregation?

Yes — running without --ward or --category prints "REFUSED: aggregating across all wards is not permitted" and exits.

Does your growth_output.csv flag the 5 null rows rather than skipping them?

Yes — the null report is printed before any computation. The 5 known null rows (2024-03 Ward 2 Drainage, 2024-07 Ward 4 Roads, 2024-11 Ward 1 Waste, 2024-08 Ward 3 Parks, 2024-05 Ward 5 Streetlight) are flagged with "NULL — FLAGGED" in the growth column.

Does your output match the reference values?

Yes — Ward 1 Kasba / Roads & Pothole Repair: 2024-07 = +33.1% (monsoon spike), 2024-10 = −34.8% (post-monsoon). Both match the README reference values exactly.

Your git commit message for UC-0C:

UC-0C Fix silent aggregation: no ward/category scope → enforced per-ward per-category with null flagging before compute, formula shown per row

---

UC-X — Ask My Documents

What did the naive prompt return for the cross-document test question?

"Yes, you can use your personal phone for approved remote work tools and email when working from home." — blending IT section 3.1 with HR remote work context.

Did it blend the IT and HR policies?

Yes — it merged IT's BYOD rules with HR's remote work approval into a single answer that neither document supports on its own.

After your fix — what does your system return for this question?

[Source: policy_it_acceptable_use.txt] Section 3.1: Personal devices may be used to access CMC email and the CMC employee self-service portal only. Note: No other work files are listed as accessible via personal devices.

Did your system use any hedging phrases in any answer?

No — forbidden phrases list enforced in agents.md. No "typically", "generally understood", or "while not explicitly covered" in any output.

Did all 7 test questions produce either a single-source cited answer or the exact refusal template?

Yes — carry-forward (HR 2.6), Slack install (IT 2.3), home office allowance (Finance 3.1), personal phone (IT 3.1 only), flexible working culture (refusal template), DA + meals same day (Finance 2.6 — NO), LWP approval (HR 5.2 — Department Head AND HR Director both required).

Your git commit message for UC-X:

UC-X Fix cross-doc blending: no single-source rule → added routing table and exact refusal template preventing IT+HR blend

---

CRAFT Loop Reflection

Which CRAFT step was hardest across all UCs, and why?

The Analyze step was hardest — specifically naming the exact failure mode before writing the fix. For UC-X it was tempting to call the personal-phone answer "wrong" without identifying it precisely as cross-document blending. Naming it correctly led directly to the right enforcement rule.

What is the single most important thing you added manually to an agents.md that the AI did not generate on its own?

In UC-0B agents.md: "clause 5.2 requires Department Head AND HR Director — dropping either approver is a condition drop, not a softening." The AI generated a generic multi-condition rule but did not name clause 5.2 explicitly or explain the distinction between dropping and softening.

Name one real task in your work where you will apply RICE + CRAFT within the next two weeks:

Automating report generation from internal data — I will define enforcement rules upfront for aggregation scope and null handling before prompting the AI, instead of fixing failures after the fact.

[github-actions]

👋 Hi there, participant! Thanks for joining our Vibe Coding Session!

We're reviewing your PR for the 4 User Cases. Once your submission is validated and merged, you'll be awarded your completion badge! 🏆

Next Steps:

• Make sure all 4 UCs are finished.
• Ensure your commit messages match the required format.
• Good luck!