Sobre Genchin impact e outros

Main ideas / lessons conveyed

• Project scope control (don’t broaden scope): The team agrees to focus on “essential” functionality to deliver at least ~80% by the end of the month, rather than expanding features and risking delays.
• Prioritized feature list: They repeatedly emphasize building/finishing specific items first:
  • routes/home page
  • form handling
  • search
  • CRUD-like behavior
  • documentation
• Correct routing and data linking:
  • The homepage/route must work (prototype exists but is not fully functional).
  • There are branch-line/route relationships between entities (e.g., sector → extension → person contacts).
  • The “extension field inside sector” can be problematic if the data model assumes a single extension per sector.
  • A proposed fix/model is that sub-sectors within a larger sector should have distinct branch lines/routes, so different people/extensions under the same department/sub-department don’t conflict.
• Security best practice for authentication:
  • Do not manually store passwords in a form/field (considered a security flaw).
  • Use the project’s native authentication mechanism (referencing that it exists in “Jangle”/framework materials).
• Error handling and technical documentation:
  • Implement POST method + CSRF token correctly on forms.
  • Add exception handling for success/error messages.
  • Ensure Redm (project documentation/manual) and requirements (including libraries) are submitted.
  • Fix missing auto-documentation (if Redm wasn’t generated).
• Evaluation/presentation strategy (two-part defense):
  • Presentation will likely be remote and evaluated by different groups (IT team / CEPED team / possibly both).
  • Plan a two-part presentation:
    1. Front-end: slides showing screens and how the app works.
    2. Back-end/technical: technical aspects only if needed.
• Weekly progress reporting:
  • Provide weekly reports (with a sample template) including daily tool behavior and more technical details.
  • Weekly deliveries are explicitly requested.

Methodology / instructions (detailed checklist)

A) Immediate implementation & fixes (this week / near-term)

• Search functionality
  • Implement search using criteria such as:
    • name
    • department
    • extension
• Homepage routing
  • Create/fix the homepage route so the main screen is functional.
  • Ensure route wiring is correct (prototype showed an unconnected main index).
• Form correctness (front-end/back-end interaction)
  • Build/repair the form using:
    • POST method
    • CSRF token
  • Validate that submission works end-to-end.
• Error handling
  • Add proper UI messaging:
    • handle exceptions
    • show success/error outcomes
• CRUD-level behavior
  • Transform the “jungle structure” into a working mini-system that supports:
    • register
    • list
    • edit
    • delete
• Authentication/security
  • Remove the manual password field approach.
  • Use native authentication provided by the “Jangle” framework/mechanism.
  • Ensure the user must log in with the correct credentials flow.

B) Data modeling: “crude oil” (priority linking tables/relations)

Create “crude oil” entities/links in two ways (as priorities):

• crude oil for sectors
• crude oil for connections between people and sectors

Confirm/implement the correct hierarchy/model:

• If a sub-sector exists within a larger sector:
  • it should have a distinct branch/route (so it can map to different extensions/people correctly).
• Avoid a design where multiple different people/extensions in the same department/sub-tree collide due to an incorrectly shared extension field.

C) Routing & UI layout dependencies

• Ensure routes exist for each entity view and that the main screen displays required lists.
• Remember to create routes and verify them with working examples/screenshots.

D) Documentation deliverables

• Requirements submission
  • Prepare a requirements list so others can run the system, including:
    • libraries
    • Redm-related documentation
• Redm file
  • Ensure there is a Redm file that documents:
    • project structure
    • step-by-step instructions
  • If it wasn’t auto-generated, create it manually.
• Weekly report documentation
  • For each weekly report:
    • explain what the tool does day-to-day
    • include more technical information than earlier internship reports
    • include screenshots where possible (routes working, screens demonstrating changes)

E) Presentation/defense planning (two-part)

• Choose one or two people to present (not everyone needs to do it):
  • One person can handle front-end.
  • Another person can handle back-end/technical (or one person can do both).
• Build client-style slides:
  • “as if selling to a client”
  • include screens and walkthrough
• Use the defense form:
  • one person fills it out
  • include each person’s responsibilities and what has been completed
  • decide who covers front/back in the two-part presentation

Target deliverables by end of month (acceptable minimum ~80%)

• Home screen with:
  • list of extensions
• Department registration:
  • department raw information
• Person contact information:
  • person raw information
• Extension field:
  • support edit/delete
• Search:
  • by department name/department
  • by person name (flexible approach)
• Confirm bank/auth working and Redm installed/documented

Speakers / sources featured (identified from subtitles)

• Samuel (requested to be added to the meeting; later referenced as arriving)
• Ronat (mentioned regarding producing crude oil)
• Ivan (referenced multiple times: prototypes, user mod access, meeting presence)
• João (spoken of as having knowledge of routing/model structure; also IT-side discussions)
• Gabriel (called on to reply)
• Gerson (collaborator referenced re: making the deal online)
• Jess (mentioned in leader/presentation online context)
• Zé Roberto (vice-rector; head of the project at the institute)
• CEPED team (evaluators/participants)
• IT team (evaluators/participants)
• “Jangle” (framework/mechanism referenced for native authentication)
• Unnamed “boys” / group (team members who test/switch machines / perform tasks)