Decisions log

Newest first. One line per decision; the rule file holds the detail.

Date	Rule(s)	Decision	Decided by
2026-10-03	INC-005 (amended)	"don't keep emergency number mandatory then … keep it mandatory only for direct customers" (after the staff wizard's Confirm button stayed grey because the contact was checked on Review but asked for on Package) — the emergency contact is required for a direct customer's booking only, optional for a partner's; checked on the step where it is asked; a disabled Next/Confirm now says why.	Owner
2026-10-03	UX-023 (new)	The app's redesign (issue #559) is approved as mocked up: one set of colours, Manrope type and building blocks for every screen, skeletons instead of spinners, one error and offline pattern; the app runs on iPad, phones stay upright and tablets turn to any side. Built first: the foundation and staff Home; the other screens follow.	Owner
2026-10-03	TRV-022 (new), TRV-002 (amended)	"Travellers on domestic and international tours never see the Hajj, Umrah or Ziyarat guides." A traveller reads the steps for every trip and the guides of their own live bookings' trip types only — in the database (the table's read policy and trv_guide) and in the app (no trip picker for a traveller; with no trip yet, only the steps for every trip). A departure with no trip type is general (the steps for every trip), never Umrah as before. Staff with programme.manage, groups.view or guide.religious.approve and a group's tour leader still read theirs. Enforced by 20261008200000.	Owner (through Hamid)
2026-10-03	TRV-018, TRV-019, TRV-021 (amended)	From Hamid's review of #562, on the owner's rule that a traveller never reads the other tradition's text: the seeded rituals describe Sunni practice and are marked Sunni until Shia versions are written (a Shia traveller is told they are not available yet); every step in the rituals is religious text (guide.religious.approve, second person); an approved change to the English or Arabic marks the approved translations "needs review" — still read — until approved again; a save leaves out-of-payload fields and other people's waiting changes as they are.	Owner (through Hamid)
2026-10-03	TRV-018, TRV-019, TRV-021 (amended)	On the open points of the guide build: (1) keep the old approved text — when approved text (a step, a part or a translation; plain or religious) is changed, travellers keep reading the last approved version and the change waits beside it until approved; Approve puts it in place, and a change can be discarded. A change of a step's tradition waits the same way and, once approved, moves the step with its contents to the new tradition. (2) A second person for religious text — whoever wrote or last changed a verse, a dua, their transliteration or meaning, or anything marked Sunni or Shia cannot approve it; another holder of guide.religious.approve must (maker-checker). Plain text approval stays one-person. (3) Confirmed: anything marked Sunni-only or Shia-only is religious text. Enforced by 20261008200000.	Owner
2026-10-03	TRV-018, TRV-019, TRV-020, TRV-021 (new); TRV-002 (amended)	The travellers' guide in English (master), Urdu, Hindi, Kashmiri and Arabic; Urdu, Kashmiri and Arabic right to left. Each language has its own status; travellers read approved text only, otherwise the English marked "Not translated yet". Verses and duas are their own parts: Arabic exactly as staff entered it from a verified source (never machine-made or changed), transliteration, meaning per language, source. "Religious text — Quranic verses, duas, their transliteration and meaning — is approved only by holders of a new permission guide.religious.approve"; other guide text by programme.manage. "No AI drafting for now: staff write each language by hand." "If women and men have separate things to do, keep that in mind": steps and parts marked Everyone / Men / Women, from the traveller's record, with Show both. "Keep [Sunni and Shia] separate, default be Sunni, but add switch or dropdown to switch to Shia": marked Both / Sunni / Shia; the traveller's own choice, never inferred, never shown to staff; a missing version is said, never replaced by the other's. Bundled OFL fonts (Noto Nastaliq Urdu, Amiri). Enforced by 20261008200000.	Owner
2026-10-03	PTR-097 (new)	Staff with partners.create add a business partner from the phone with the desktop form's checks; it is pending, gets its code and ledgers, and sales@ is told. A PAN or GSTIN already on a partner needs "Add anyway" (proposed with the change). Enforced by 20261008230000.	Owner
2026-10-03	PTR-030 (amended), PTR-096 (amended)	A partner's credit limit and commission are set by finance and leadership only: agents.credit_limit.set and agents.commission.set for FINANCE_MANAGER, CEO, GM, SUPER_ADMIN (taken from ADMIN_HR and B2B_MANAGER), checked by the database on adding and editing a partner. The sales@ e-mail and the approvers' notice name the terms. Enforced by 20261008230000.	Owner
2026-10-03	PTR-097 (new)	Staff with partners.create add a business partner from the phone with the desktop form's checks; it is pending, gets its code and ledgers, and sales@ is told. A PAN or GSTIN already on a partner is allowed after "Add anyway" and always shown with a dim "Shares PAN with …" label; only someone who may read partners is told which partner holds it. Enforced by 20261008230000.	Owner
2026-10-02	PTR-023 (decided)	"Yes, sent-back only": a partner may send again its own booking the office sent back for correction; a rejected booking stays with the office; the price cannot change on a re-send (kept at send-back, sentBackPrice). Enforced by 20261008140000.	Owner (through Hamid)
2026-10-02	PLT-051 (bookings tiles)	"Cancelled" means fully cancelled only; partly cancelled and transferred bookings keep their own counts. Enforced by 20261008140000.	Owner (through Hamid)
2026-10-02	WRK-009 (decided), WRK-014 (decided), COMM-041 (new); WRK-018 (amended)	Job notifications must be reminders in the web and phone app, not only e-mail — the owner chose all four: (a) the new holder is told when a job is given to them (note, phone from the server, e-mail); (b) the person who gave a job is told when it is finished or cancelled, not when they closed it themself; (c) the holder is reminded about one working hour before the due time; (d) overdue, as recommended: at the due time the holder, at 1.5× the target the queue lead(s), at 2× the holders of work.assign, 24 working hours past due the holders of work.view.all. Measured on the business clock less waiting time; a waiting or closed job is skipped; each rung once per job and due time. A note the database keeps is now rung on the phone by the communications-dispatcher; the e-mail copies are the category work, on by default. The desktop header bell lists the person's own notes. Enforced by 20261008150000.	Owner
2026-10-02	EA-017, EA-018, EA-019 (new); EA-001, EA-002, EA-014, EA-015, EA-016 (amended)	"it gives HR rights to re-issue agreements without approval from higher authorities, what if HR puts different salary? also add salary and increment clause also. Also add points that we may change any clause any time according to laws" — asked: approver "CEO only"; increments "Yearly in April"; changes "Law: at once; others: 30 days"; existing "Withdraw unsigned, re-issue new". HR prepares; a CEO (hr.agreements.approve) approves or rejects with a reason before the employee sees it — never one they prepared or their own. Template v4 adds the salary clause (5.1, as approved by the CEO, payslip), salary review and increments (5.6, from 1 April by a CEO-approved increment letter, discretionary) and changes (24.3, law at once, others 30 days' notice, never fixed salary or legal rights without consent). The four unsigned v3 agreements were withdrawn. Enforced by 20261008125500.	Owner
2026-10-02	EA-014, EA-015, EA-016 (new)	"Balaghat HR issued one agreement to Showkat, but showkat didn't get it anywhere, everything should also trigger emails. Also update the system so that they get to see the agreement atleast once or whenever they want to" — every step of the employee agreement is e-mailed to whoever must act or should know (issued → employee; signed → countersigners and the issuing HR; countersigned → employee and HR; withdrawn → employee), a link and never the text or pay; reminders every 3 days (employee) and 2 days (countersigners) for 30 days; every ERP page and the app's home say so while an agreement waits. The signed copy and earlier versions stay under My agreement to open, print or save as PDF any time. Enforced by 20261008125000.	Owner
2026-10-02	PTR-001 (decided, amended), PTR-095, PTR-096, PTY-009, PTY-010 (new)	"system should inform us from now on that a new business partner has been added and is subject to approval also. Same goes for suppliers also. And they should be approved by either general managers, CEOs, or Admin only. And should trigger an email to sales@alhudatravels.in" — every new partner (self-registered or added by staff) and every new supplier is pending; only partners.approve / suppliers.approve (GM, CEO, IT_ADMIN, SUPER_ADMIN) approve or reject, with a reason; a pending or rejected supplier takes no hand-entered bill or payment; a new one e-mails sales@alhudatravels.in and notifies the approvers' inboxes; the decision e-mails sales@. "Admin" read as IT Admin and Super Admin, as for role changes (ACC-077). Enforced by 20261008120000.	Owner
2026-10-02	INV-009 (new), INV-008 (amended)	"Planner templates": staff with groups.edit save a departure's programme as a named template (optionally for a trip type), each activity kept by its day of the trip; cancelled ones are not saved. A departure starts from a template, or a template is added to an existing programme after a confirm. An activity whose day falls after the return date lands on the return date marked "(outside the trip — check)" rather than being dropped, and the planner lists these first. Applying a template twice adds nothing. No new permission: groups.view reads templates, groups.edit writes them. Enforced by 20261007130000.	Owner
2026-10-02	SAL-002, SAL-OPEN-2	Converting a website enquiry books every traveller the enquirer named (the enquirer first), with passport and date of birth when typed; staff check them before approval. Matching them to existing customers stays manual.	Owner
2026-10-01	LC-034 (new)	Decision (T): a confirmed traveller transferred to another booking or group lands confirmed, with no re-approval, when the price and channel are unchanged. A price change on a transfer still needs finance approval by someone other than the person transferring. Enforced by 20261008130000.	Owner
2026-10-01	LC-035 (new)	Decision (R): only live bookings count as "already in this group" — CANCELLED, REJECTED and TRANSFERRED don't — and transfers follow the same rule. Enforced by 20261008130000.	Owner
2026-10-01	PRC-003 (decided), ACC-020, LC-005, LC-020, LC-021, INV-002, PAX-005 (amended)	Once a booking leaves sales (PENDING_OPS, PENDING_FINANCE, ON_HOLD, APPROVED, PARTIALLY_CANCELLED…) its price and travellers change only by sending it back for correction, or through a cancellation or a transfer; contact details, notes and room choices stay editable. With it, from a logic audit of bookings: a cancellation request is written only by the database, which records who asked, and a request that names nobody cannot be approved; a traveller is moved only by transfer and a cancellation is never undone from the browser; a rejected booking going back for approval is checked for capacity as it will count, and refused if sales are stopped; finance re-checks readiness and capacity before approving; deleting a draft refuses one with carried money, a transferred-in traveller, a visa case or an issued ticket, and rejects or reverses its vouchers in the same step; an infant who grows into a seat is counted. Enforced by 20261007100000.	Owner (edit lock); engineering (the rest, on the standing rule that money and access rules live in the database)
2026-10-01	FIN-046 (new), FIN-034 (amended)	Exchange rates are kept by finance: a new permission finance.rates.manage for FINANCE_MANAGER, ACCOUNTANT, CEO, GM and SUPER_ADMIN; no other login can change a rate. A rate is dated (today in India by default, never after today); a past-dated rate is allowed with a reason and audited. A rate past its expiry date no longer counts. Enforced by 20261006100000.	Owner
2026-10-01	PTR-030 (decided), ACC-020, ACC-030 (amended)	A partner's credit limit binds staff too: a booking, edit or price change that takes the partner over its limit is refused unless a Finance Manager, CEO or GM (partners.credit.override) gives a reason, which is audited. A reversal is approved only by someone who made neither the original nor the reversal — enforced at approval, so the maker may still ask for one (break-glass: finance.journals.approve_own). The ₹25,000 journal limit applies to every voucher a person writes — journals, contras, on-account receipts, reversals on custom lines; above it CEO or GM approves. System postings keep their own rules. Enforced by 20261006120000.	Owner
2026-10-02	COMM-037, COMM-038, COMM-039 (new); COMM-012, COMM-020, COMM-023, LV-036, LV-038, LV-039 (amended)	One notification mechanism: every automatic e-mail the database sends is a CommunicationQueue row with a category (hr_leave, finance, booking, visa, general) and a key, queued once per category and key, sent by the dispatcher through the mailer; leave is the hr_leave category and its Leave admin switch is that category's switch; finance has its own switch in Admin → Reminders. The payment receipt e-mail moves from the browser to the database (an online or phone-verified payment now gets one), once per payment, to the booking's e-mail recipient (the partner on a partner booking); an allocation of an on-account receipt sends no e-mail and no WhatsApp; a rejected partner or customer claim e-mails the claimant Payment claim not accepted with finance's reason and stays on the partner's Payments page for 90 days. Enforced by 20261006130000.	Owner (finance staff guide review)
2026-10-02	FIN-032, FIN-033 (part), ACC-020; FIN-047 (renumbered)	Status records brought into line with what is built; no behaviour changes. FIN-032 and ACC-020 are marked DECIDED: both have been enforced in the database since 2026-09-18, under the owner's decisions logged below. FIN-033 is DECIDED for when a booking is owed (2026-10-01) and stays PROPOSED for the customer ledger worked out from ledger entries. "A group's cost report reconciles to its ledger" was numbered FIN-038, which "What a cancellation keeps is not a trip sold" also used; it is now FIN-047.	Finance staff guide review (records only)
2026-10-02	INV-008 (decided, amended), TRV-003 (amended), INV-003 (note)	"One day-by-day planner" for the group itinerary. A departure has one programme, kept in GroupActivity and edited on the web planner (the group's Itinerary tab) and on the phone; staff, the tour leader, travellers, Customer 360, the website poster, Copy and the printed report all read it. The activities typed in the Edit Group dialog were copied in once (an undated one on the departure date, "(date to confirm)"); that list is kept but no longer read. A clone copies the programme with its dates shifted. Enforced by 20261006160000.	Owner
2026-10-01	LV-036 … LV-039 (new), LV-034 (amended)	"leaves should also sent emails to reporting officer and upon accept, it should trigger another email" — a new application or reported absence is e-mailed to the applicant's reporting officer ("Your approval is needed" when it is routed to them, otherwise "For your information — HR approves") and to its approvers (HR; management for peak season, notice period, leave without pay), one e-mail each; the next approver is told when a stage is done. The final approval e-mails the applicant (with the balance left) and the reporting officer; a refusal, a cancellation and an absence HR records likewise. Once per application, step and recipient; company address of an active, unpaused login only; no certificate, contact number, Aadhaar or PAN; no-reply. On by default; HR switches it in Leave admin → Settings. Enforced by 20261005183000, the mailer template leave_notice.	Owner
2026-10-01	COMM-030 … COMM-036 (new)	"I wanted actually workflow, where we send message to Alhuda Travels on whatsapp and it shows options from there to choose" — a WhatsApp menu: Groups available, Booking enquiry, My booking status, Pay balance, Documents needed, Talk to the office; customers send passports and passport-size photos one by one. Booking = an enquiry to sales (a lead), never a booking or a payment in WhatsApp. Off until an administrator switches it on.	Owner
2026-10-01	TRV-017 (new), TRV-016 (amended), ACC-062 (note)	Asked how customers should sign up through WhatsApp — a code on the sign-up page or a sign-up inside the chat: "Both". The code (TRV-016) is live; now a customer who writes "sign up" (or "register", "account", "register karna" …) to +91 95419 10494 gets a form inside WhatsApp (a WhatsApp Flow: name, city, email, privacy consent). The filled form makes a login only for the number it came from (the customer record comes with the first booking, LC-006) and a one-time link to set the password comes back in the chat. A number that already has an account is told so in its own chat. Sign-up only — no orders or bookings over WhatsApp (standing rule). Set up once from Admin → Integrations → WhatsApp. Enforced by 20261005140000, whatsapp-webhook, auth-login set_password_with_token, whatsapp-flow-setup.	Owner
2026-10-01	LC-OPEN-5 (decided), TRV-007 (amended), LC-006 (note)	"Should the email sign-up also become login-only, like WhatsApp, with the customer record at first booking?" — "Yes". Every public sign-up (email or WhatsApp code) makes a login only — the User row and the CUSTOMER role, written on the server; the customer record is made by the first booking request, with a placeholder passport until the booking brings it. Until then the portal and the app say "Your details will be added with your first booking". Existing rows are not touched. Enforced by 20261005120000, customer-signup, customer-exchange.	Owner
2026-10-01	TRV-016 (new), LC-006, ACC-062, ACC-069 (notes), LC-OPEN-5 (decided for WhatsApp sign-up)	"lets create customer sign up through whatsapp" — both: a six-digit code on WhatsApp on the website's and the app's sign-up page now, a sign-up inside a WhatsApp chat (Flows) later. Customers only. Sign-up makes a login only (name, the verified mobile number, an optional unverified email); the customer record is made by the first booking request (LC-006). A number with an account gets no code and the same words; a shared number cannot sign up. The approved reset-code authentication template is reused. No orders over WhatsApp (standing rule). Enforced by 20261005110000, auth-login signup_code / signup_verify.	Owner
2026-10-01	FIN-033, COMM-034	"Allow online payment before approval, up to the booked amount." A booking awaiting finance approval shows Awaiting finance approval — ₹X will be due (never Fully paid) and can be paid online — app, partner portal, WhatsApp link — and claimed, up to its agreed due (price + GST − receipts − credit). The balance still waits for the voucher. Enforced by 20261006110000, razorpay-order.	Owner
2026-10-01	FIN-033, FIN-030	A booking's balance counts its price and GST only once its booking voucher is approved (replaces the GST-only decision of the same day, below). Payment, refund and cancellation limits, statements, emails and invoices stay on the booked amount.	Owner
2026-10-01	PRC-020	Days before departure are calendar days in India: the departure date less today's date in IST; the time of day does not matter.	Owner
2026-10-01	FIN-030	A booking's GST counts toward its balance only once the voucher that posts it is approved (to build: #509).	Owner
2026-10-01	PAX-034	When a booking's cost lines add up to more than its price, the invoice prints one Package line at the price.	Owner
2026-10-01	UX-022 (new)	In the app the keyboard never covers the box being typed in — on Android and iPhone, on full screens and in bottom sheets. "Wherever in the app if there is text field, and you want to write, it stays under the keyboard and hides that field."	Owner
2026-10-01	AUD-025, AUD-027 (amended), AUD-026 (note)	Nobody deletes their own account any more: a traveller (direct customer) or a business partner requests it in the app or on the website, and the office reviews it and approves (erases) or declines within 30 days — even when nothing is open. A partner's request says "Business partner — the office decides". Money either way stops the office's approval until settled: besides a balance owed, money the company holds for the person — an overpayment or a refund due (fin_refundable), a refund asked for and not yet approved, an overpaid group invoice, an unused on-account advance. Staff are still refused. Apple 5.1.1(v) and Google Play accept an in-app request the business completes. Owner: "we can't let customers delete accounts on their own especially B2b and Employees, and for customers, if there is a balance on their accounts, we can't let them delete accounts on their own"; "does banking apps offer account deletion? No, so why is mandatory for us, keep it only for direct customers and that too upon approval". Open: whether partners keep a request-only "Request account closure" or lose it with in-app partner sign-up. Enforced by 20261005090000.	Owner
2026-09-30	ACC-020, PRC-020	A passenger's cancellation is approved by the database, not the browser: a request by someone else, a refund within the passenger's price and the policy (an override needs a reason), the booking's refunds within what it bills. Direct writes of the approval are refused.	Owner
2026-09-30	FIN-032	A reversal or cancellation credit posts approved on its own only when its lines mirror the voucher it reverses (its accounts, sides swapped, no larger); anything else waits for a second person. The cancellation credit must reverse the passenger's own booking voucher.	Owner
2026-09-30	PRC-030 (decided)	A customer gets back only what they overpaid: paid − (price + GST − cancellation credits), less refunds awaiting approval. A cancellation credit reduces the bill and is not cash owed back; the charge is kept. "Only what they overpaid."	Owner
2026-09-30	AUD-025, AUD-026, AUD-027 (new), AUD-022 (note)	A traveller or a partner deletes their own account from the app or the website (Apple App Store 5.1.1(v); DPDP Act 2023 s.12): DELETE typed and the password; erased at once when nothing is in the way, otherwise a request the office settles first (an unfinished trip, a balance, a payment claim, an open request, an unpaid invoice, a departure led, a paused account) and then completes or declines with a note. Erased: the login and the personal details, identity numbers, saved family, documents (Drive trash), push tokens, sessions, location, WhatsApp number. Kept as the law requires: bookings, payments, receipts, invoices, tickets, the ledger, travellers' names on them, the customer code, PAN, GSTIN and place of supply; a partner's business record; the audit trail. Staff logins are closed by HR, not this way.	Owner
2026-09-30	COMM-020 … COMM-025, AUD-024 (amended)	Automatic WhatsApp notices: booking confirmed (finance approves; once per booking) and payment received (finance verifies, or an online payment is recorded; once per payment) with the receipt PDF attached privately (uploaded to Meta's media store, never a link). Only a Meta-approved template is sent — its name is a setting (defaults booking_confirmed, payment_receipt, text-only booking_confirmed_text, payment_receipt_text); no approved template → skipped and logged, never free text. A template with a Document header is usable for these notices (not in chat). Same recipients as the e-mails; a STOP reply is honoured. Both ship switched off. There is no booking confirmation or invoice PDF, so the confirmed notice goes text-only. Owner: "there should be auto whatsapp message for payments and booking confirmation, which if possible should send PDF invoices or receipts or other details also". Enforced by 20261003234500, edge function whatsapp-booking-notice.	Owner
2026-09-30	COMM-001, COMM-002, COMM-003, COMM-010 … COMM-014	Every e-mail about a booking names the booking number, the lead customer and all live travellers (subject: what — BK-… — Name & N others), the departure and — when it is about money — total, received and balance; never passport, Aadhaar, PAN, date of birth, phone or e-mail. Reminder e-mails by the system: payment due (7 days before the due date), overdue (weekly, at most 4), departure (7 and 1 days before), missing documents (45 and 21 days before) — to the partner on a partner booking, else the customer (the payer for payment); once each; stop when the reason goes; ship switched off until an administrator turns them on. Owner: "when an email is sent to anyone related to booking or any auto email which contains any details or any payments, it should include some other details also, for example Customer Name or Customer Names if there are multiple people in the booking, along with booking ID. reminder emails should also be there". Enforced by 20261003220000, 20261003220100.	Owner
2026-09-30	ACC-084 (new), EA-013, ACC-071, ACC-081 (amended)	HR edits the profile details of every staff login except an admin's: "except for admin, syed HR can edit profile details". Read as: whoever holds hr.profiles.edit (ADMIN_HR today) edits designation, department, reporting officer, joined on, father's / guardian's name, personal and emergency details, notes and the Aadhaar / PAN last four of any staff login that does not hold roles.apply or admin.permissions.edit (IT Admin, Super Admin today) — CEOs, the GM and managers included. Not the login's name or work phone, not the employee code, nothing about access. HR's agreement issue saves the appointment back on the same terms.	Owner
2026-09-30	ACC-083 (new), ACC-077, ACC-078	"Admin" for role changes is IT Admin or Super Admin only (roles.apply). Only an admin may ask to add or remove an administrative role — one whose permissions control users, access, settings or role changes (CEO, GM, HR Admin, IT Admin, Super Admin today) — or pick one when creating a login. HR, the GM and a CEO still ask for every other role. A CEO still approves and a different admin applies.	Owner
2026-09-30	ACC-077, ACC-078, ACC-079, ACC-080, ACC-082 (new)	A staff role changes only with two approvals: it is requested with a reason (HR, GM, CEO, IT), a CEO approves it, and an admin (IT) accepts it — only the admin's accept changes the role. Requester ≠ approver ≠ admin; nobody decides a change to their own roles; a CEO's own request goes to the other CEO (the super admin approves when both are away). The database refuses every other change of a staff role, from any session; maintenance needs a direct database session and a switch for that transaction. Customer, partner and tour-leader roles keep their own flows; a new login starts with no staff role. "HR, GM, or even CEOs or anyone else shouldn't have rights to change roles directly, it should first go to CEO for approval, if CEO approves, then it should become a task for an admin to accept it or reject it. Only admin can finally change the role, otherwise system is vulnerable."	Owner
2026-09-30	EA-012 (new), ACC-081 (new), EA-013 (new, PROPOSED)	The agreement's appointment is filled from the staff record ("These should be fetched and mapped from the staff, right? At least designation and Reporting to"): designation and department from the profile, else from the login's highest staff role (a plain title and its department), each marked from profile / from role / missing / typed; the reporting officer and the joining date are never guessed. A reporting officer is picked from the staff, never typed ("it should list it from the already listed staff"), never oneself or anyone below; the database refuses loops, except two CEOs, who report to each other ("There are two CEOs, keep them reporting officers of each other"). Proposed: issuing writes the appointment used back to the profile when the issuer may edit that profile.	Owner
2026-09-30	FIN-032, TRV-009, PTR-093 (amended)	Staff do not pay online: "there shouldn't be option to pay online (via Razorpay for example) for bookings for employees in the mobile app or on the web app, right?" Only the booking's customer or payer, or its business partner, starts a Razorpay payment; staff record the customer's payment (Take payment / Record payment), pending until verified. A staff member who is the booking's own customer or payer pays it like any traveller. The app's staff booking screen loses Pay online; online_payment_actor() no longer answers staff and razorpay-order refuses staff with 403.	Owner
2026-09-29	UX-030 (new)	Every list has one toolbar: search, filters, a date range on the list's own date (quick periods or DD/MM/YYYY from/to, both ends included, Indian days) and a sort, with sortable columns; the database applies all of it to the whole list and the page address keeps it. "Let's do paging and also add sorting options and dates from and to, and make all pages more professional." Sales lists first; operations, finance and administration follow.	Owner
2026-09-29	INV-031 (decided)	Hotel rooms are checked night by night against the allotment. A stay outside the allotment's nights is refused, and the lease's last date is the check-out day (01–30 Nov = 29 nights, as the purchase voucher counts).	Owner
2026-09-29	INV-032 (new), INV-003 (decided)	Every service stays inside its departure (hotel, meals, transfers, flights ±1 day). Moving a departure raises one operations job naming what it strands; a return before the departure is refused.	Owner
2026-09-29	LV-001, LV-002, LV-004, LV-005, LV-010 … LV-015, LV-020, LV-021, LV-030 … LV-035, LV-040 … LV-042, LV-050 … LV-052, LV-054, LV-055, LV-060 … LV-062 (new)	A leave portal and a holiday calendar built from the Employee Agreement v3 (Clause 6, 13, 20, Annexure B): leave year 1 April–31 March; CL/SL 12 a year pro rata, EL 1.25 a completed month usable after confirmation; Sunday the weekly off; 12 paid holidays kept by HR, moon dates tentative until confirmed; HR sanctions in advance (an HR applicant's reporting manager instead); management approves peak season, notice period and leave without pay; comp-off for a weekly off or holiday worked on instruction, used off-season within 90 days; an append-only leave ledger; year end closed by HR (EL carried up to 30, the rest lapses). No e-mail or push for leave; payroll not built. Open: LV-003, LV-006, LV-016, LV-053, the peak months (LV-032) and per-employee weekly offs (LV-004).	Owner
2026-09-29	EA-001 … EA-009 (new)	The employee agreement is a web page, signed and kept permanently ("put an employee agreement digital copy of it where they will sign it and will be permanently saved" — "No, it can be a simple web page, why pdf?"): HR issues the owner's v3 text filled from the record, its SHA-256 fixed at issue; the employee and then the Company's signatory sign with typed name, drawn signature and password; nothing is ever deleted or changed, a change is a new version; a simple electronic signature with an audit trail, no Aadhaar eSign, no PDF (the browser prints it). Open: EA-010 (the signatory), EA-011 (the Clause 25 wording and the starting values).	Owner
2026-09-29	PTR-093 (new), PTR-094 (new), PTR-081 (amended)	A business partner pays from the web portal as from the phone ("How can a business partner add money to his bookings on his web and phone application?"): a Payments page (owed against the credit limit, bookings and invoices with a balance, waiting and verified payments) and Pay online / I have paid on a booking, through the same partner_submit_payment and razorpay-order — a claim stays pending until finance verifies it. No receipt upload, payment date or note (the function takes none). The Flights page shows flights only ("Also the flights are showing some groups there"); a package is booked through New booking and a question about a departure is a request that can name it.	Owner
2026-09-28	ACC-076 (new)	A person's phone is one number ("if phone numbers are updated, it doesn't get updated properly"): a change on the login, the partner record or the customer record of the same person changes the other two, copied as typed. Numbers compare on the last ten digits, so a new spelling is not a change. A blank never overwrites a number; a staff login's number changes on the login only; a partner's contacts are other people and are not synced. Existing differences are listed for the office to fix by hand; only blank sides are filled.	Owner
2026-09-28	PTR-091, PTR-092 (new), PTR-083, PTR-090 (amended)	The partner record reads like a company profile ("best facebook profile like page for business partner"): a header with the verified mark (active, and every required document accepted and in date), New booking / Call / WhatsApp / Ledger / More, the numbers, and the Timeline first with the Intro beside it; the record's one read also carries the travellers. The Partners list names the primary contact, the owner or the contact person — never "New Agent" or an internal id — opens the profile on a click, keeps the other actions in one ⋯ menu, and shows cards or a table. No partner logo (not built).	Owner
2026-09-28	INV-007 (new)	The printed group report can include money: each booking's total, paid and due (the booking's own figures, once per booking, never per traveller) and the group's totals, filtered to all, fully paid or balance due. Off by default, offered only with bookings.view or finance.view, and the printout is marked "Includes payment details — internal". "In the print group report add an option of who has paid and how much is due or total amount."	Owner
2026-09-28	PAX-036 (new)	A family is recorded per departure and never assumed: its own record (name, head, members with a relationship from an editable list), which may span bookings and partners but not departures; one booking may hold several families and people in none; one family per traveller; each traveller is in a family, not family or not recorded. Suggestions only — a person confirms. Travellers who leave the departure leave their family; a head who leaves leaves the family needing a new head. Recorded before departure (readiness), not a condition of booking approval. A partner records families for their own travellers only.	Owner
2026-09-28	PAX-021 (PROPOSED → DECIDED)	Every child and infant names an adult guardian travelling on the same departure (any booking); when the guardian leaves, the minor shows "no guardian travelling" until someone names another. PAX-022 (mahram) stays open; the data it would need now exists.	Owner
2026-09-28	ACC-075 (new)	The office (admin.users.edit) changes a staff login's sign-in email, and moves every staff login on @alhuda.co.in to the same name at @alhudatravels.in ("can you change email of all employees to @alhudatravels.in domain?"). Customers and partners are never changed. Sign-in and profile change together; sessions, password and username stay; old address, new address and username all still sign in (ACC-061). A reason, an audit row and an email to the new address per person; a preview first; a second run changes nothing.	Owner
2026-09-28	PTR-084 … PTR-090 (new), PTR-083 (amended), PTR-080 (amended)	Every business partner has a full profile ("Create business partner profile system now"): business, split address, registrations (IATA, association, state tourism, Haj/Umrah licence with expiry) and the office relationship (relationship manager — an active staff login —, region, tier, onboarded on, source, internal notes); several contacts with Call/WhatsApp; append-only office notes; performance by financial year; the login's sessions and devices. The office edits with partners.edit, only changed fields, audited; the partner edits only its own address, website and contacts and never sees the office-only fields. Staff may now file and remove a partner's documents (the file stays on the drive). A business PAN is shown in full to agents.view. Bank details are not built.	Owner
2026-09-28	LC-031 (new), LC-032 (new), LC-033 (new), LC-030 (amended)	A transfer keeps its records. A booking whose last traveller is transferred out is closed as TRANSFERRED — shown as "Transferred → BK-…" on every list, never "Fully paid", and read-only in the database. The money received for a traveller is carried to the booking they land on (no payment row moved or split; a pending voucher when the party ledger changes). The new booking keeps the old one's customer, payer, partner and channel, sales owner and emergency contact; a traveller never lands on a booking of another channel. Open: the split rule for a part transfer, a manager override of the channel refusal, the sales owner and customer of the new booking.	Owner
2026-09-27	INV-006 (amended)	Stop selling stops selling: the database refuses any traveller joining a departure set by hand to Full, Departed, Completed or Cancelled (new booking or traveller, partner booking, transfer or booking moved in, restored cancellation); leaving and editing are never refused.	Owner
2026-09-27	UX-010, UX-011	The phone dashboard follows the web's role profiles: the same twelve profiles, detectors, suppression, priority and widgets (one shared definition), a tab per matched profile with the main one first, each tab the same one call (dashboard_screen). Anyone matching a profile gets the tab; the phone's own management dashboard (app_dashboard) is retired. Collected today and the customer / partner receivable split move into the web's Collections and Receivables widgets.	Owner
2026-09-27	UX-020 (new), UX-021 (new)	Every date a person reads is DD/MM/YYYY (with a time: DD/MM/YYYY HH:mm, 24-hour) — screens, app, printed documents and the text the database builds; people type dates as DD/MM/YYYY and a date that does not exist is refused by name. Every password, PIN and key box has a show/hide eye. "We use dates in DD/MM/YYYY format. Also password fields should have eye also."	Owner
2026-09-27	PRF-013 (new)	The phone app opens without waiting for the network: the last good profile and the screens' last answers (never passports, documents, manifests, bookings, customers or money records) are kept on the phone and refreshed behind the first screen; the profile is one call (app_bootstrap, was four requests in two waves). The database still checks every read and write.	Owner (goal), Engineering
2026-09-27	VISA-005, VISA-031, VISA-032	Staff work visa cases from the phone ("give staff more options to work from phone"). Whichever screen marks a visa issued or refused, the database e-mails the customer — never with the staff reason. The visa copy and papers are filed from the phone to the Shared Drive; the phone list finds a case by name, passport, booking or code.	Owner
2026-09-27	FIN-032 (amended), ACC-030	Finance staff write vouchers (journal, payment, receipt, contra) from the phone. Nothing changes about approval: every voucher waits for a second person, the maker never approves their own, the manual-journal limit applies to all four types, and no voucher is dated in the future or in a closed period. Foreign-currency vouchers stay on the website.	Owner
2026-09-27	WRK-018 (new), WRK-016 (amended)	Tasks are typed and handed out from the work inbox, on the desktop and the phone, and count in the staff scorecard like every other job: a task has a due time (or the internal target), a priority and an optional link to a booking, customer, group or partner; several tasks may point at one record; the new holder is told. Default target for a task with no due time is proposed.	Owner
2026-09-27	PRC-006 (new)	A departure's rate sheet can be copied from another departure — the whole sheet or its lines, custom lines or taxes — by staff with group_pricing.edit. Never onto itself, into a closed or departed departure, from one without a sheet, or across currencies (nothing is converted). Existing bookings keep their prices; every copy is audited.	Owner
2026-09-27	PRC-007 (new)	The rate sheet's inventory read no longer overwrites selling prices with cost: the cost and the margin (₹ and %) are shown beside each price, a price below cost is red, and prices take the cost only through an explicit, confirmed Use cost as price. No margin is shown across currencies.	Owner ("make groups more flexible … more professional"), Engineering (how)
2026-09-27	INV-006 (new)	The office stops and reopens sales, and marks a departure departed or completed, from its Overview tab — each with a reason, behind groups.edit, through the existing status override. Stop selling pins Full; it is a status, not a database lock (the seat limit stays the only hard stop), and the page says so.	Owner (goal), Engineering (how)
2026-09-27	FIN-039, FIN-036	The per-traveller service charge is edited in the group Edit dialog and shown on Overview; a group invoice's Post says Nothing to post when the bookings already posted their revenue instead of reporting a success.	Owner (goal), Engineering (how)
2026-09-27	PAX-035 (new), INV-040 (reading)	A group is managed per traveller: one row per person under their booking; the group leader is one traveller of the group, never a booking and never someone added without a booking ("do not add customer to database directly unless booking is created"); make leader, transfer and remove (a cancellation request approved by someone else, or a transfer — never a delete) are per traveller, on the desktop and the phone; bulk rooms, meals, transfers and visas go to the travellers picked. "Exclude group leader" on a meal plan still spares the leader's booking.	Owner
2026-09-26	ACC-074 (new), ACC-073 (amended)	Files live on the company Shared Drive, never in Supabase Storage ("we have only 1 gb"): every upload goes through an edge function to the drive, a website visitor's files only after the captcha; staff see every document inside the ERP through drive-file with the view permission of that record — no Google account needed; Shared Drive membership is only for administering the drive.	Owner
2026-09-26	ACC-073 (new)	A document on Drive is never public: files go to the company Shared Drive shared with nobody; staff open them as members, travellers and partners through the app's ten-minute link. Uploads had made every file readable by anyone with its link.	Owner
2026-09-27	PTY-001 … PTY-006 (new)	Reliability first: every party has a permanent code given by the database — customer CU-000123, business partner BP-0012, employee EM-0007, supplier SU-0005. Never changed, never reused, numbers grow past their width. Every staff login has an employee code; codes already typed by hand are kept. The finance ledger codes (CUS-/AGR-/AGP-/SUP- + 8 of the id) and postings stay exactly as they are; only a party ledger's name shows the code. The code is shown wherever the party is, a list finds a party by it, and the booking import takes a Partner code and a Customer code. Storing each party's ledger id on the party is a separate later change.	Owner
2026-09-26	PRF-010 (extended)	The operations screens are one call each too — the visa queue, a visa case and a visa group, operations approvals, airline blocks and a block, seat releases, inventory holds, hotels and a ticket — read as the caller under the same row security and permissions as before, never wider. Was up to 72 requests in 30 round trips (a block's page).	Owner (goal), Engineering (how)
2026-09-26	TRV-001 (amended)	A traveller who is only a passenger on someone else's booking sees that trip in their own app: the departure, programme, guide, flights and hotels, their own passenger row and passport scan, the others by name only, the emergency contact and their own location switch. No money, no other traveller's details, no quotations or requests on the booking, and they cannot change or pay on it.	Owner
2026-09-26	PRF-010 (extended)	The customers list, Customer 360, the leads list and the work inbox are one call each too (customers_list_page, customer_360_screen, leads_list_page, work_inbox_screen), read as the caller. Was 12, 12, 5 and 10 calls.	Owner
2026-09-26	PRF-002 (new)	The system is too slow: a screen loads in one call to the database, not one per box. PRF-010 — the bookings list and the booking page; PRF-002 — the first screen (the role dashboard and the phone home) loads every tile, the sidebar badges and the unread count in one call, each tile under its own permission; only the journey board goes out beside it.	Owner
2026-09-26	PRF-011, PRF-012 (new)	A screen's permission check costs at most one round trip (the session's permissions kept 30 s; the database still checks everything); finance refreshes after an action in one round trip (was 18 calls in 5); an open finance screen shows another person's change about a second after it is saved.	Owner (goal), Engineering
2026-09-26	FIN-044 (amended)	A payment to the airline, a refund from it and the deposit count as paid only once finance approves the voucher; until then the block shows Awaiting finance approval and the amount stays owed. A pending payment still counts against overpayment; a rejected one counts nowhere. The voucher memo and its approval name the block's PNR.	Owner
2026-09-26	AIR §37 (new)	A seat release filed with no penalty is FOC (the cancellation, the block's FOC count and the release type say so); with a penalty the refund is the fare less the penalty unless the airline refunded a different amount (the variance). An airline refund on Approvals names the release, PNR, block, route, date, seats, FOC or penalty, refund, airline reference and filer.	Owner
2026-09-26	PRF-010 (new)	A screen is one call: the bookings list and the booking page each get everything they show on first paint in one round trip (booking_list_page, booking_screen), read as the caller under the same row security and permission checks as before. Was 6 and 35 calls.	Owner
2026-09-26	PRF-005 (new)	Signing in and reaching the dashboard downloads only what those screens run, held under a 550 KB gzip budget that fails CI (was 741 KB). Other screens, Excel, charts and the error reporter load when needed; database answers are never cached by the service worker; only data with no personal, passport, document or money detail is kept on disk, and it is cleared at sign-out.	Owner (goal), Engineering (numbers)
2026-09-26	AIR §36 (new)	An airline block starts as a draft: saved, it posts nothing, is listed only among the drafts and cannot be linked, held, released or sold; the ticketing roles correct it freely; Submit runs every check and creates the block with its purchase voucher and deposit in one transaction, and a refusal leaves the draft with the reason.	Owner
2026-09-26	AIR §30, CXL-030	The ticketing roles record the airline filing of an approved seat release; finance still settles the refund.	Owner
2026-09-26	AIR §30, ACC-020	The ticketing roles create blocks and pick the deposit's account; the ticket manager may decide its own seat release (marked and audited; the seat limit still applies).	Owner
2026-09-26	ACC-072	A staff password-reset link is delivered to name@alhudatravels.in (Google Workspace), whichever company domain the account uses; partners and travellers unchanged.	Owner
2026-09-25	PTR-083 (new), ACC-071 (amended), PTR-080 (amended), AUD-004	One record per business partner and one per employee, read in one place, with everything linked: status and its history, the login and its access, the documents with the office's review (OK, or rejected with a note the person reads), bookings, money, requests, groups led and one activity timeline that links to the booking, group or record each row describes. Reading a record needs agents.view / admin.users.view; its audit rows show the action, field names and actor, never the values. Identity numbers are the last four only; no secret is ever part of a record. Staff do not upload documents on a partner's behalf.	Owner
2026-09-25	FLD-007 (new), FLD-001 (amended)	A tour leader is any login — an employee, a partner or a traveller — appointed on a departure by staff with groups.edit, in one step. The appointment grants the Tour leader role and nothing else; the dismissal takes it away when no other group is led; the person is told; both are audited. A leader sees their group and nothing else, whatever else they are.	Owner
2026-09-25	ACC-010, FIN-040	An allocation is read by its owner: what a receipt settles, and for how much, is read by staff who may see money (finance.view, bookings.view, agents.ledger.view), by the customer of the allocated booking and by the partner whose agency owns it — nobody else. It had been open to every signed-in login.	IT (security audit)
2026-09-25	FLD-001, ACC-012	A thin role is thin at the row level: the staff-wide read policies (the people directory, role grants, the ledger, chat, WhatsApp) admit staff who hold a permission outside field.*, so a tour leader — or a partner who leads — reads their own User row and takes every name on their screens from the field functions. Nothing changes for the office.	IT (security audit)
2026-09-25	FIN-044 (amended), INV-014	The ticketing roles also record the airline's refunds and the deposit at purchase, and file a third-party sale's cancellation from the phone; finance still approves every voucher and decides every cancellation, never the filer.	Owner
2026-09-25	FIN-044, AIR §30	The ticket manager and a new ticket executive record payments to the airline for their blocks; finance approves them. The executive is a thin role: no approvals. Both sell seats on to other agencies from the phone (INV-014).	Owner
2026-09-25	ACC-070, ACC-071 (new)	Any login can be paused: it signs in and reads as before and every write is refused ("This account is paused (read-only)") — enforced in user_has_permission, is_staff_user, the two portal doors and the edge guard, never in a screen; a pause needs a reason and the person is told. Every employee has a profile (designation, code, department, dates, contact, emergency contact, reports-to, documents on the drive) and a partner's profile is their agency and documents; only the last four of Aadhaar and PAN are ever kept.	Owner
2026-09-25	TRV-013 (new), TRV-011 (amended)	An e-ticket and a hotel voucher are files: the office issues, from the booking, the company's own e-ticket sheet (one per booking, refused by name until every traveller ticketed by Alhuda has an issued ticket number) and hotel voucher (one per stay) as PDFs in the private bucket, recorded in IssuedDocument; a re-issue supersedes, nothing is deleted. The traveller opens them under My documents, the partner under the booking, staff who may read the booking anywhere. Issuing needs tickets.view + bookings.view or hotels.view + bookings.view; no new permission. The sheets say on their face that they are Alhuda's, not the airline's or the hotel's own document.	Owner
2026-09-25	PTR-004 (new), FLD-001 (amended)	A business partner's login may also be a tour leader: staff give it TOUR_LEADER and assign it to a departure; it marks attendance for that group and stays a partner — a login with a portal role is never staff.	Owner
2026-09-25	PTR-080, PTR-081, PTR-082 (new)	The partner portal in the app: a partner registers from the phone (email confirmed first, account pending), files PAN, identity and proof of business (GST certificate with a GSTIN; address proof and cancelled cheque asked for) to the company drive under Partners/<agency>, and the office approves on the desktop as before. A partner books on account from the app with the rate-sheet price, and reports payments against a booking or invoice — pending until finance verifies. No wallet: funds on account are still recorded by finance.	Owner
2026-09-25	TRV-010 (new)	Every notification is kept: one AppNotification row per login, read by its owner only, written by push-send, ntf_notify and trv_post_notice (a group notice is in every recipient's inbox even when the push fails). The app and /m/notifications show the inbox with unread badges, mark read, and open the screen the notification is about. Read rows go after 90 days; unread ones stay. No new permission.	Owner
2026-09-25	TRV-012 (new)	Reminders and the offline copy live on the phone: local notifications planned from the programme (30 minutes before each timed item; 20:00 the evening before a travel day; at most the next 64; kept equal to the programme; a per-phone switch), and the trip, programme, guide and documents list saved on the phone per login and shown as "Last updated … · offline". No server part.	Owner
2026-09-25	TRV-011 (new)	A traveller sees their own documents in the app — the visa and its files, the e-ticket record (number and status, no PNR), the hotel stays (no price) and the papers under their own record — through one function that widens no row policy; a file opens through drive-file as a ten-minute signed link. The e-ticket PDF and the hotel voucher are not stored anywhere, and the app says so. Programme reminders and the offline copy are phone-side behaviour of the same screens.	Owner
2026-09-25	TRV-007 … TRV-009 (new)	The app is a travel planner for the customer: a traveller creates their own account (the website's sign-up, step for step — LC-OPEN-5 stays open), browses the departures on sale and books one by request: "Book this trip" is the same group_interest request the website sends, the office confirms it, sends a quotation the traveller accepts in the app, and the office creates the booking (LC-006). A payment the traveller reports is pending until the office verifies it (FIN-032). No new table, function or permission.	Owner
2026-09-25	TRV-001 … TRV-006 (new)	A native phone app (Expo, apps/mobile) with three stacks: the staff ERP, the tour leader's field app, and a portal for the traveller — their trip, a step-by-step guide per trip type, the departure's programme and notices, all live on the phone. A passport photographed in the app waits for a person with bookings.edit before it touches a passenger, and never creates a customer (LC-006). A partner is pointed to the web portal. New permission programme.manage.	Owner
2026-09-25	FLD-005 (amended), FLD-006 (new)	A traveller may switch on live sharing of their own position, from their own phone, for their tour leader and the office, only during the trip; revoked in one tap, one row per person, no history. Check-ins still take the leader's location only; FLD-005 no longer says "never continuous tracking" — it says who may switch it on (only the traveller) and when it is stored (only while travelling).	Owner
2026-09-25	PLT-060 (amended)	The Android app opens the phone layout of the ERP (/m): simple, professional, the same rules as the desktop. The company's name is written Alhuda, one word, everywhere.	Owner
2026-09-25	INC-005	Every booking names an emergency contact at booking; it is on the booking page and the tour leader's manifest.	Owner
2026-09-25	PLT-060 (new)	The Android app is a shell around the live site, built on demand and signed only with the company keystore.	Owner
2026-09-25	FLD-002, FLD-004, FLD-005	The tour-leader app: check-ins are optional but every one recorded is kept; the app works without signal and syncs later; travellers give location consent at booking, and presence is counted either way. TOUR_LEADER role built (FLD-001).	Owner
2026-09-25	ACC-069 (new)	Password reset for customers and partners: email first, a six-digit WhatsApp code as the backup. Staff reset by email only. The emailed link now signs the person in.	Owner
2026-09-25	INV-014, INV-015 (new)	A third-party seat is counted by its status: a cancelled sale holds no seats, and a sale is cancelled through the filing, not by typing a status. A manifest name belongs to one live sale, at most one per seat, and goes with it; the manual-passenger button is gone.	Operations
2026-09-25	ACC-053 (widened)	The anonymous key is a visitor: it can execute an allow-list of functions (the website's reads, the portal context, the RLS predicates) and nothing else; new functions are closed to it from birth; trigger functions are granted to nobody.	IT
2026-09-24	WRK-007 (amended)	Some jobs go to a set person or role automatically: a manager sets a routing rule per kind of job (a named person, or the least-busy holder of a role). Jobs with no rule wait in the pool. Whoever holds a job can hand it to anyone, with a reason.	Owner
2026-09-24	WRK-017 (new)	Email to info@alhudatravels.in becomes a lead, and so an enquiry in the work inbox. Leads only, never a booking. Captured by an Apps Script in a member's Gmail.	Owner
2026-09-24	PLT-033 (new)	A fallback the API layer takes is reported (Sentry and the console), never silent; a failure that would make a number wrong fails the request instead. Enforced by a build test over src/lib/api.ts.	IT (existing practice)
2026-09-24	PLT-051, INT-005	Every sidebar badge is counted by the database in one call, the way its list decides what to show, under the person's own row policies. Fixes the requests badge, which counted statuses that do not exist, and the leads, customers and visa badges, which stopped at the page size.	Engineering (V1)
2026-09-23	ACC-060, ACC-061	Staff sign in with a username or their work email. @alhudatravels.in and @alhuda.co.in are the same person and the same account.	Owner
2026-09-23	ACC-062 … ACC-068	Signing in moves to one server-side function: the captcha is verified, attempts are throttled, identifiers are resolved without revealing who has an account, and the database refuses a password-only session of anybody with an authenticator. The browser-checked email/WhatsApp code is retired (nobody used it); the authenticator app is the second factor. Deactivating an account also blocks its sign-in.	Engineering, on the owner's V1 instruction not to weaken security
2026-09-24	ACC-053 (new)	A database function is not public: every new function revokes PUBLIC and the anonymous key, grants signed-in staff only where a screen calls it, and grants nobody at all when only triggers call it. Made explicit after six inventory functions shipped without it.	IT (existing practice)
2026-09-24	INV-042 (new), INV-040	A catering contract is bought in meal-days (pilgrims × days), and a meal plan follows the departure's manifest: a pilgrim joining, cancelling, transferring or opting out moves the fed and billed counts, the stock and the cost voucher, automatically and in the same transaction. A typed head-count fixes the plan. Growth from the manifest is adopted and the contract named as over, not refused.	Owner
2026-09-23	FIN-043 (new)	A visa is billed by the agent who processed it. The agent is named per case, and a refused visa costs the same as an issued one — they charged for the application either way. Staff pick the finished cases, enter the charge per visa, and one bill is raised against that agent's account in their own currency. A case still with the embassy is not billed, and nothing is billed twice. Billing is finance.create, not visa.edit.	Owner
2026-09-23	LC-006	A customer is registered when a booking is created. Nobody is added to the customer list on their own "for later" — a customer record carries passport, date of birth and contact details, and holding that without a purpose is holding it without a reason. Not yet enforced: the standalone create-customer screen and the visa-enquiry conversion both still create a customer before any booking exists (LC-OPEN-4, LC-OPEN-5).	Owner
2026-09-23	AUD-022	The outbound message queue is readable and writable only by staff who may send. It was open to every member of staff, and each row carries the recipient's name, email address and phone number. Nobody may delete from it — a queued message is cancelled by its status.	Engineering, on the standing data-protection rule
2026-09-23	SAL-002 (new), AUD-021	An enquiry keeps the travellers it named: the website's passenger list is stored on the lead and shown on the leads screen, as unverified text, capped at 20 names. A passport scan uploaded on the website is reached only by a short-lived signed link — the public URL that used to be stored never resolved, because the bucket is private. Carrying the names into the booking on conversion is left open (SAL-OPEN-2).	Working default — owner to confirm
2026-09-23	WRK-001 to WRK-016	One work inbox for everything that arrives - website, WhatsApp, email, phone, counter, sub-agent. A job has one owner: work raised here is owned here, and work that already has an owner (booking correction, incident, customer request, visa enquiry, hold, group) is shown read-only rather than copied. Targets per channel (WhatsApp 30 min, phone 60, website 2 h, email 4 h), measured on working hours - Mon-Sat 10:00-19:00 IST with the Friday prayer break - and the clock stops while waiting on somebody else. A manager assigns, or staff claim from a pool.	Owner
2026-09-23	PERF-001 to PERF-013	Performance is measured on four things only: speed against targets, weighted throughput, enquiries converted and value booked, and quality (reopens, escalations, send-backs, corrections). It is for coaching and workload balancing only - never pay, never automatic discipline - and no single composite score is published. Staff see their own numbers, queue leads see their queue, leadership sees all. Presence time, keystrokes and screen activity are never measured.	Owner
2026-09-23	SAL-001	A lead that is lost or closed, and a quotation that is rejected or expired, must say why. The reason, who ended it and when are stored on the record, cleared if it is re-opened, and every status change is in the audit trail. Leads get a lost status; there was no word for going nowhere. A fixed list of loss reasons is left open (SAL-OPEN-1).	Owner
2026-09-22	INV-040	Catering is bought at a rate per pilgrim per day — you pay for the people who eat. "Exclude children" and "exclude group leader" mean those people are fed and do appear in the counts sent to the caterer, but are not charged for. A meal plan therefore carries two head-counts: travellers fed and travellers billed.	Owner
2026-09-19	PRC-020, PRC-023	Keep cancellation terms flexible for now: no single set of terms is fixed in the rules. Policies are configuration that managers create and edit; each band can charge a flat amount and/or a percentage and a policy can keep items once spent (e.g. the visa once applied for). The system ships starter policies to edit: Umrah — standard (matches the 29 Aug 2026 case), Full refund, Non-refundable.	Owner
2026-09-18	ACC-011, ACC-012	Leadership keeps its day-to-day rights: CEO and GM hold every permission except the super-admin-only set (approve/reverse own vouchers, ledger rebuild/reset, year and period close, delete a GL account, user or partner, edit roles and permissions). Above-limit approvals stay with leadership. Enforced by 20260921140000_leadership_operational_rights.sql.	Management
2026-09-18	ACC-021	Cashier records receipts only; finance.payments.verify removed from CASHIER. Standard segregation of duties; exceptions only as time-limited grants by the Super Admin.	Best practice, adopted on the owner's instruction to follow professional standards
2026-09-18	ACC-013	Data scope by ownership: executives see their own records by default with a recorded All toggle; managers see their function; finance, auditor and CA see everything in theirs. Branch scoping deferred until branches are records. Owner to confirm.	Working default
2026-09-18	ACC-030	Approval limits by amount adopted as working defaults (discount 5/10%, refund ₹50k/₹2L, supplier payment ₹2L/₹10L, journal ₹25k, fare ₹5L, release 10 seats, write-off CEO only), held as configuration with named owners. Owner to confirm the numbers.	Working default
2026-09-18	INC-003	Incident response times, escalation chain (duty owner → Operations Manager → CEO/GM) and "management" definition adopted as working defaults; internal alerts send automatically, anything leaving the company is sent by a person. Roster to be confirmed.	Working default
2026-09-18	INT-030	Signal thresholds adopted as working defaults and held as settings with named owners; season = Indian financial year, a group belongs to its departure season.	Working default
2026-09-17	ACC-011, ACC-012	Only the super admin has full rights by default: a new SUPER_ADMIN role holds every permission (including the break-glass journal overrides and destructive/system rights) and is the only role that does; everyone else — CEO and GM included — gets rights the super admin grants. CEO/GM keep a leadership bundle (all views and exports, business approvals, supplier-transaction correction); IT_ADMIN keeps system settings only.	Owner
2026-09-17	ACC-011	New CHARTERED_ACCOUNTANT role for the external CA: reads all finance, reports and the audit trail, prepares journals, adjusting entries and supplier-transaction corrections (always approved by someone else); no cash handling, configuration, period unlock or year close.	Owner
2026-09-17	ACC-021, FIN-031	Correcting a supplier transaction after its voucher has been reversed is allowed for Accountant, Chartered Accountant, CEO/GM and the super admin, through a dedicated permission (finance.supplier_transactions.correct) enforced in the database.	Owner
2026-09-17	UX-010, UX-011	Every employee has their own role-based dashboard (work queue, signals, KPIs, shortcuts); contents per role PROPOSED.	Management
2026-09-17	INT-001	Intelligence must be everywhere: every screen smart and logical with the larger picture in mind. Adopted as a cross-cutting principle (file 17); detailed INT rules PROPOSED. Heavy audit of the finance module and its connections commissioned.	Management
2026-09-17	JRN-004, C360-001, INC-020, FLD-001, UX-001	Wave 2 design direction approved as presented (burgundy/gold brand with AA-adjusted text colours, one status colour map with icon + label, three confirmation levels, Customer 360, universal journey, duty-of-care board, operations home, customer portal and tour-leader app layouts). Design canvas: https://claude.ai/artifact/4TzdYU9LHj4ycoQj9cAivZ	Management
2026-09-17	JRN-001, C360-001, INC-001, INC-010, FLD-001, FLD-003, PLT, CX	Owner confirmed the business model and all industry-grade capabilities: one universal customer journey; Customer 360 showing status, itinerary, location, hotel and emergencies; incident management including death abroad; tour-leader app with live check-ins; health & insurance records; platform reliability (paid plan, staging, monitoring, CI); after-trip feedback and returning pilgrims.	Management
2026-09-17	UX-001, PROGRAM	Every sensitive action must be confirmed Yes/No by all user types. Every page to be upgraded with role-based UI, better graphics and colours; customer and partner portals to industry grade. Seven area reviews commissioned; upgrade program adopted.	Management
2026-09-17	CXL-011, CXL-*	Cancelled passengers' seats return to the block/FIT they came from; airline cancellations must be recorded per passenger seat and adjust the ledger; the system must show which passenger was cancelled. Owner asked for the full chain to be fixed.	Management
2026-09-17	LC-030, INV-020	Passenger transfer: release old group's inventory, auto-assign equivalent inventory in the new group where capacity exists, flag anything unmatched for operations.	Management (in planning session)
2026-09-17	LC-040, LC-041	Tour status moves to In Travel / Returned automatically by date; operations completes a closeout checklist to mark Completed.	Management
2026-09-17	FIN-001	Package money received before travel is an advance (liability); it becomes revenue when the tour is completed. Accountant to confirm Ind AS vs AS and principal/agent split (FIN-002, FIN-003).	Management — pending CA confirmation
2026-09-17	AUD-010	Historic data drift is reported first; repairs are applied only after management approves them. No silent data fixes.	Management
2026-09-17	AIR-*	Airline group ticketing & block inventory specification adopted as the target (file 05).	Management
2026-09-17	ACC-*	Access control must reach industry grade; build it natively (not a separate IAM product such as INDIGO IAM).	Management
2026-09-23	VISA-011	A refused visa is refused: the case is not applied for again. The way forward is to cancel the traveller under the normal policy, which keeps the visa fee.	Owner
2026-09-23	REQ-001, REQ-002	A refused request tells the person who asked why. An internal reason is never emailed to a customer or a partner.	Owner
2026-09-23	LC-005 (settles LC-OPEN-2)	A rejected booking is not a dead end: sales corrects what finance objected to and sends it back to finance. A refused booking gives its seats back to the departure and takes them again when it goes back for approval.	Owner
2026-09-23	PUB-001, PUB-002	A departure is shown on the website as a poster: wording from a template per trip type, overridden per departure, every part optional. The site reads a purpose-built view, never the departure table.	Owner
2026-09-23	INV-040	Catering is bought at a rate per pilgrim per day. "Exclude children / group leader" means fed but not billed.	Owner
2026-09-23	—	The first approval is the sales manager's check (price, discount, customer), not operations'. Screen wording only.	Owner
2026-09-22	LC-004	Nothing that spends money is done for a booking finance has not confirmed: no visa application, hotel bed, meal plan, coach seat or ticket. A booking sent back for correction can still be corrected, and receipts can still be banked; payments out wait for confirmation.	Owner
2026-09-22	AIR §24	A ticket number may be entered once finance has confirmed the booking (APPROVED); an exception approved by a different person lets a pilgrim be ticketed earlier. No sync step, one sheet per departure, names from the passenger. Confirmation does not check payment while PRC-010 is open.	Owner