From Attendance Reliability to
Booknix Mobile Foundation

1. Introduction

Week 7 split across two mobile engineering tracks. HireRosterly moved deeper into attendance and employee self-service reliability, while Booknix moved from an empty Expo starter into a structured mobile foundation with an authentication shell. The emphasis was not on producing the largest number of screens; it was on making each layer explicit: UI behavior, shared types, API boundaries, navigation, role separation and runtime evidence.

The week also reinforced a practical rule from the previous reporting cycle: a TypeScript pass proves source-level consistency, but it does not prove that a workflow persists data, reaches the intended backend, or behaves correctly on a device. For that reason, implementation and verification were kept as separate checkpoints.

2. HireRosterly: Work From Home and Attendance UI

The main HireRosterly focus was the Work From Home and attendance experience for React Native Mobile. Attendance handling was normalized so the mobile layer can represent policy-driven attendance and remote-work behavior more consistently rather than relying on screen-specific assumptions.

• Attendance service and attendance types were refined to support the current attendance workflow.
• The Employee punch screen was substantially rebuilt for stronger parity with the available attendance behavior.
• Organization typing was extended with optional attendance-policy context so the UI can consume policy information when the backend provides it.
• HR attendance work remained part of the same mobile attendance surface, keeping employee and HR views aligned around shared attendance data.
• TypeScript validation passed after the attendance and related profile changes.

This work is being prepared for a dedicated Ticket 20 branch so the Work From Home and Attendance UI can be reviewed independently from unrelated mobile changes.

3. HireRosterly: Employee Profile Save Reliability

Employee profile editing received a targeted runtime fix. The Save action was already wired, but validation feedback could be effectively invisible in Expo Web because the flow depended on alert behavior. Network inspection showed that no profile request was being sent when validation returned early.

The screen was adjusted to surface validation errors inline. After the correction, the profile save flow was reported working. This is a useful example of why button wiring alone is not enough evidence: the request path must be observed, and validation failures must be visible where the user can act on them.

4. HireRosterly: Employee Self-Service Expansion

The Employee area continued to grow beyond punch and profile workflows. An Employee announcement screen and menu entry were added, while broader employee-facing work also included team, evaluation and communication-related surfaces under development. These additions support a more complete employee self-service experience without shifting HR or Admin responsibilities into the wrong role.

Designation work also remained substantial in the repository, including list, create and detail/edit flows. Because multiple feature tracks are present in the working tree, Git staging is being handled selectively rather than treating every local change as part of the attendance ticket.

5. HireRosterly: Chat and Calling Investigation

Realtime communication work continued with Chat and calling infrastructure. The mobile client uses Socket.IO and derives the realtime origin from the configured API base. During testing, the call modal remained in a reconnecting state and browser diagnostics showed the production WebSocket request receiving an HTTP redirect.

The important finding was configuration-related: the active Mobile environment was pointing at the production Vercel API during a local realtime test. The local API configuration is the appropriate target for local Socket.IO verification. No success claim is made here for the final call flow; the investigation isolated a concrete environment mismatch that must be retested after using the intended backend target.

6. Booknix: Project Foundation

Booknix Mobile began as a new Expo Router project using TypeScript and the SDK 57 project structure. The starter application was cleaned into a domain-oriented source tree with dedicated areas for routes, reusable components, constants, context, services, storage, types, utilities and validation.

• A shared color system and theme tokens were established for consistent spacing, typography, radii and semantic states.
• Reusable AppButton, AppInput, Screen, LoadingState, ErrorState and EmptyState components were created.
• Environment handling was prepared with a local .env and a committed .env.example; the real .env is ignored by Git.
• A generic API client and API URL helper were added without inventing backend endpoint contracts.
• The initial mobile foundation was committed and pushed to the Booknix Mobile GitHub repository.

A physical Expo Go connection issue was also resolved by treating the trusted Wi-Fi network as Private in Windows. This kept the development workflow on LAN without hard-coding a machine-specific IP into the project.

7. Booknix: Authentication UI and Role Architecture

Booknix then moved into its authentication delivery phase. Login and customer registration screens were implemented with reusable inputs, inline validation and navigation between the two screens. The UI deliberately avoids claiming a final backend registration contract because the supplied system design identifies authentication as a capability but does not define exact request payloads or password rules.

• Authentication role types were introduced for Customer, Employee, Driver, Organization Admin and Platform Super Admin.
• A centralized AuthContext now owns session, user and initialization state.
• Customer and Employee/Driver route areas were created and protected with role-aware layouts.
• A shared routing utility maps authenticated mobile roles to the correct application area.
• Authenticated users are prevented from remaining on auth routes, while unauthenticated users are redirected to Login.
• A reusable application loading screen is ready for future persisted-session restoration.

Expo Router typed-route errors were handled without bypassing type safety. The routing utility now uses Expo Router’s own Href type, and the final TypeScript check completed without errors. Runtime screenshots also confirmed that Login and Registration render and navigate correctly.

8. Architecture Decisions That Prevent Rework

Several deliberate constraints shaped the Booknix implementation. Mobile currently prepares Customer and Employee/Driver experiences rather than inventing mobile Admin dashboards. Backend DTOs and endpoint names are not fabricated while the backend contract is still being defined. Secure token persistence is also postponed until real authentication integration is ready.

The same discipline applies to HireRosterly. Attendance, profile and realtime behavior are separated from unrelated designation or chat changes when preparing a ticket branch. This makes pull requests easier to review and reduces the risk of shipping feature work under the wrong ticket.

9. Validation and Engineering Quality

The distinction between static and runtime evidence remains intentional. A clean compiler result is reported as a compiler result. Runtime behavior is only described as verified when it was actually observed.

10. Challenges and Resolutions

• Expo Router typed routes rejected custom route strings after regeneration. Resolution: use Expo Router’s Href type as the routing boundary instead of casting away type safety.
• Booknix Expo Go initially could not connect over LAN. Resolution: correct the trusted Windows network profile rather than hard-code a temporary network address.
• HireRosterly employee profile Save appeared silent. Resolution: expose validation errors inline and verify whether the request is actually sent.
• HireRosterly calling attempted the production realtime endpoint during local verification. Resolution: isolate the environment mismatch and use the intended local API target for the next test.
• HireRosterly contains multiple feature tracks in one working tree. Resolution: create a dedicated Ticket 20 branch and stage only attendance/WFH-related changes.

11. Next Development Plan

• Finish the HireRosterly Ticket 20 attendance/WFH checkpoint, selectively commit the relevant mobile files, push the branch and open a focused pull request.
• Retest HireRosterly realtime calling with the correct backend environment before making a functional-completion claim.
• Continue Booknix authentication only when the backend contract is available: real auth requests, secure token persistence, session restoration and logout.
• After Booknix D2 integration is stable, move into the next documented customer and employee/driver mobile milestones without inventing backend business logic.

12. Conclusion

Week 7 combined stabilization work on an established product with disciplined foundation work on a new one. HireRosterly advanced the Work From Home and attendance experience, improved employee profile feedback and isolated a realtime configuration problem. Booknix progressed from project setup to a reusable UI system, generic API boundary and role-aware authentication/navigation shell.

The strongest outcome was architectural clarity. Both projects now have clearer boundaries between what is implemented, what has been statically validated, what has been observed at runtime, and what still depends on backend or environment work. That separation keeps weekly progress measurable without overstating completion.

Week 7 Highlights