Development plans — redesign technical guide

Hybrid host, permissions and profile API

Verified in code: employee module_plan_dev_fo and manager plandev gates precede pane rendering. src/Service/V2/SmrDisplayService.php::isIdpDisplayable requires the hybrid flag plus SMR read-user-development. src/Twig/Company/CompanyNavigationExtension.php::getSmrIdpFeature resolves the allowed personal/admin IDP path; the personal journey prefers personal/idp without an ID; manager paths can use admin/idp/<id> or personal/idp/<id>. On failed eligibility, the host retains the legacy pane. A frame exposure is not evidence that every deployed participant screen matches local source.

Nextgen paths below are relative to smartmobility-nextgen-back. config/routes.yaml supplies /api/v2; src/Http/Api/Routing/V2/development.yaml supplies:

Method/path under /api/v2	Required right / behavior
GET /user/self/development	read-user-development; authenticated user's axes.
GET /user/self/development/{developmentId}	Same right; one axis.
POST /user/self/development/{developmentId}/status	update-user-development-status; updated axis, HTTP 200.
POST /user/self/development/{developmentId}/action/{actionId}/status	Same update right; updated task, HTTP 200.
Equivalent /user/{userId}/development... paths	Rights plus company and other-user visibility scope.

List filters cover title, status, origin, attachment type and position, with position ascending by default. UserGoalRepository::findDevelopments restricts company and owner and adds visibility filters for other users. Task lookups include parent goal and user. Actions and training requests are side-loaded separately to avoid multiplying paginated rows.

Sanitized axis status body:

{"status":"done"}

Axis status accepts in_progress or done; DevelopmentStatusDTO forbids todo even though the shared enum/response supports legacy rows with it. Task status accepts todo or done. Controllers validate the status payload, check configured rights, resolve the scoped resource and return a fresh DTO with HTTP 200. DevelopmentStatusManager returns without saving when unchanged. No axis CRUD or task text editing is exposed by these profile routes.

Rights migration src/Infrastructure/Migrations/Version20260909101500.php registers read and status rights as eligible for employee/manager/HR/admin presets. It does not prove current tenant grants, nor enforce the PRD's admin-read-only policy by itself.

Redesign campaign answers

In smartmobility-nextgen-front, the renderer is under src/modules/ModuleConfig/Campaigns/modules/Reviews/modules/FormRender/components/renderers/Development/. DevelopmentQuestion.vue uses its api/development.api.ts to send a complete answer tree on every edit:

{
  "type": "development",
  "question_id": 123,
  "user_review_id": 456,
  "goal_details": []
}

This is a structural example, not a safe update to an existing plan: an empty tree can remove content. Real updates must merge the complete current tree and preserve server identifiers.

Verified in code: POST /api/v2/user-review/{userReviewId}/answer/development/{questionId} creates; PUT to the same path plus /{answerId} updates. Goals nest actions, training requests and justifications. The client maintains submission/saved-answer state, synchronizes the review's update time, and rejects empty create/update responses rather than overwriting local state. Whole-tree writes are a concurrency consideration; conflict handling was not proven by this inspection.

Nextgen-back ReviewDevelopmentAnswerDTO applies cap, unique-training, opinion-scale, task-setting and role-field validators. DevelopmentGoalAnswerDetailDTO requires title (max 255), description max 2,000, and an in-progress/done status; attachment is nullable in the DTO despite being required in the PRD. DevelopmentAnswerManager handles nested answer persistence and source-goal links. Do not infer complete creator-only authorization from the presence of attribution fields or one role validator.

Signature synchronization and data lifecycle

Verified in code: Infrastructure/Persistence/Service/Review/Strategy/DevelopmentAnswerProcessor invokes Infrastructure/Service/User/UserGoalAnswerService. The finished-review gate checks non-aborted review/self review and an employee signature timestamp/flag.

The service collects development answers from the self review. Each detail updates its linked sourceGoal or creates a profile UserGoal, sets interview origin, title, description, status, attachment and position, then replaces task and training-request collections. It sets endDate from the review deadline or signature time despite the PRD's date-free axis behavior. Tasks depend on the action-type row with code OTHER; absent that row, task replacement exits after clearing the collection. Verify this reference data before rollout.

The cleanup selects all open interview-origin goals for the target user and removes those absent from the kept IDs. It is not limited to a demonstrated snapshot of axes carried into that campaign. Thus unrelated open interview goals may be removed, while completed goals are outside this predicate. This conflicts with the PRD's promise to preserve unrelated axes and warrants dedicated pre-rollout verification. No signature was executed here.

Model	Role
Development/UserGoal	Profile axis; compatible legacy fields, origin, date, status and ordering.
Development/UserGoalAction	Profile task, type, status and position.
Development/UserGoalTrainingRequest	Catalogue/free request, opinion, preference and related fields.
Review/Answer/Development/ReviewDevelopmentAnswer	Campaign answer root.
ReviewDevelopmentGoalAnswerDetail and nested details	Campaign snapshot, source profile association, tasks, requests and justifications.

Entity paths share src/Infrastructure/Persistence/Entity/. The inspected profile sync copies a subset of answer fields; it is not evidence of complete PRD comment/provenance preservation. Deletion recovery, historical migration and cross-generation write arbitration were not established.

AI and training dependencies

Verified in code: front-end development APIs request development suggestions and training suggestions by POST under /api/v2/user-review/{userReviewId}/, with training rationale fetched by GET at training-suggestions/{trainingId}/rationale. AI errors become empty suggestion arrays or null rationale in the client. Investigate the service boundary when a healthy empty UI conceals unavailable suggestions.

Infrastructure/Persistence/Service/Development/DevelopmentSuggestionProvider.php calls AIHub api/v1/development-objectives/suggestions using server-held credentials and tenant context. It sends reviewee, locale, limit, existing titles and optional training IDs, filters suggestions to requestable trainings and caches nonempty results for 86,400 seconds using review/context inputs. No credentials belong in browser documentation or examples.

In aihub, src/core/main_routes.py mounts src/matching/training/api/development_objectives_router.py; it delegates to development_objectives_workflow.py and development_objectives.py. The input carries user ID, locale, existing titles, limit and optional catalogue trainings. This service suggests content; it does not own profile CRUD or signature synchronization. The PRD excludes career targets as AI inputs in V1. Successful generation and runtime catalogue access were not exercised.

PRD, local source and deployed version differences

Topic	PRD v106 / observed settings	Checked local implementation
Unlimited requests	PRD and deployed label: 0. Existing form: cap 4.	Backend null or positive; front requires positive cap.
Admin controls	Deployed form shows comments, off-catalogue, optional fields and tasks.	BuildDevelopment.vue shows cap, opinion levels 1–10 and tasks.
Axis title / attachment	PRD max 80; attachment required.	Max 255; nullable attachment DTO.
Dates	PRD axes/tasks have no deadlines.	Profile DTO exposes end date; signature writes review-derived date.
Evaluation	PRD both evaluators may decide.	DevelopmentRoleFieldsRespectedValidator checks main evaluator for opinion changes and prevents that evaluator changing employee preference.
Duplicates	PRD warns without blocking, including imported duplicates.	Answer validator adds a violation for repeated catalogue training IDs; verify deployed behavior before relying on warning-only duplicates.
Signature preservation	PRD preserves unrelated and completed axes.	Cleanup covers open interview-origin goals absent from the kept set.

These differences are evidence gaps, not a migration specification. The deployed read-only settings are stronger evidence for PS Testing's visible fields; the local code is stronger evidence for the contracts it implements. Neither alone establishes the deployed participant implementation.

Failure modes, observability and extension points

Check profile eligibility before debugging a missing frame, scoped permissions before treating 403/404 as missing data, and review status/signature before expecting exported axes. For rejected answers inspect cap, duplicates, tasks and role/scale validators; use deployed contracts to resolve 0/null and field discrepancies. Check OTHER action reference data when tasks disappear during sync. Trace review completion, kept IDs and cleanup population before investigating lost profile content. Runtime logs, queues and latency were not inspected.

Runtime dependencies include Symfony/Doctrine and shared UserGoal storage, the SMR frame/auth bridge, the Vue campaign renderer/FormBuilder, catalogue access, scoped rights and server-side AIHub configuration. Extend the owning question DTO, nested persistence, signature sync, profile DTO and host gates together. Verify employee/manager/second-evaluator permissions and data preservation before rollout. No deployment or migration procedure is inferred.

Development data is user-linked HR information. Keep catalogue/AI credentials on the server, authorize every target user and nested ID, and avoid logging full answers or private comments. Client task instructions belong in the functional guide; code paths and discrepancies here support authorized implementation review.

Evidence and limitations

• Observed in application: legacy test create/status/action/completion after reload, manager space, redesigned existing read-only form. Screenshots are linked in the functional and configuration guides.
• Verified in code: the paths and symbols above across all four local repositories. No application repository was changed and no API mutation was issued directly.
• Specified in PRD: Individual Development Plan, version 106. Full redesign acceptance testing is still needed.
• Not verified: complete authorization chain, redesigned profile source component, participant flow, AI outputs, signature execution, nested preservation, deletion/reimport, PDF, mobile and deployed commit identity. No plan/campaign settings were changed; only the documented legacy test objective/action were created.

Functional-guide evidence

These implementation and product references support the functional guide. Local source behavior does not establish which revision or optional features are deployed. Application observations remain distinct from code and documentary evidence.

• Observed in application: PS Testing only, Jim Carter only, 23 October 2026. Legacy create, status change, typed action and completion persisted after reload; manager-space switch and redesigned read-only form settings. Three full-window screenshots show real screens. Test objective/action remain available.
• Verified in code: legacy Customer/ProfileBundle/Resources/views/Default/{index.html.twig,includes/dev-objs-tab.html.twig,includes/idp-tab.html.twig}, Company/AssessmentBundle/{Controller/Api/UserGoalController.php,DTO/UserGoalDTO.php} and Service/V2/SmrDisplayService.php under smartmobility-legacy/src; nextgen profile routes, status DTOs, FormBuilder and development-answer components detailed in the technical guide.
• Specified in PRD: Individual Development Plan, version 106. Requirements are distinguished from deployed observations and local implementation.
• Not verified: redesigned participant journey, AI outputs, second evaluator, deletion/reimport, signed-review propagation, PDF, mobile and production parity. Source/deployed differences prevent treating local code as the exact PS Testing version.